3 ms·
Attacker owns my service, spawns a shell. OSQuery will tell me that a new process is running. Fargate will not tell me anything, to my knowledge. OSQuery as a
by staticassertion 7y ago
Attacker owns my service, spawns a shell. OSQuery will tell me that a new process is running. Fargate will not tell me anything, to my knowledge.
OSQuery as a sidecar might work, if you stuff it in the container, but I doubt it can access the audit subsystem and I'm unsure if it's really been tested in that sort of environment.
I'm not concerned about container escapes or the underlying host being owned.
- tptacek 7y agoMy take: you can run osquery in a container, but people don't, because osquery does a lot of stuff that doesn't make sense in a container environment, where you start from minimized, fine-grained control over the environment (honestly, I see a lot more productionized osquery in endpoint security than I do in serverside security). Anything you're trying to accomplish with osquery in a Fargate container, you can presumably accomplish with it or something else.
- staticassertion 7y agoOSQuery was merely a strawman, I also mentioned the audit subsystem, but these are just implementation details. I can not easily, in a supported fashion, track things like process executions or file interactions in a Fargate container. Maybe OSQuery could run as a sidecar, maybe auditd is actually exposed to the container, I honestly don't know. The end result is that companies leveraging things like aws lambda or fargate are also likely giving up instrumentation that they would consider standard on EC2. I don't think this is really controversial to say. You can absolutely justify to me that instrumentation is not worth 3rd party patch management and a nice ACL system etc.