Twistlock’s runtime defense system compares the state of a running container to the predictive model created for it during its learning period. When abnormal activity is detected, such as executing an unknown process, Twistlock can:
Raise an alert by generating an audit. Audits are shown under Monitor > Events > Container Audits. If you have an alert channel configured, such as email or Slack, audits are forwarded there too. Alert is the default action.
Block the container by stopping it altogether. To enable blocking, create a new runtime rule.
Prevent just the discrete process or file system write (not the entire container). To enable prevent, create a new runtime rule.
Blocking stops potentially compromised containers from running in your environment.
Twistlock blocks containers under the following conditions:
A container violates its runtime model, and you’ve installed a runtime rule with the action set to block. For example, if an attacker infiltrates a container and tries to run a port scan using nc, then the container would be blocked if nc weren’t a known, whitelisted process.
A newly started container violates a vulnerability or compliance rule, and those rules have the action set to block. Twistlock scans all images before they run, to enforce policies about what’s allowed to execute in your environment. For example, you policy might call for blocking any container with critical severity vulnerabilities.
Runtime rules can be created under Defend > Runtime > Container Policy. Vulnerability rules can be created under Defend > Vulnerabilities > Policy, and compliance rules can be created under Defend > Compliance > Policy.
Blocking immediately stops a container, taking it out of service. Blocked containers are never restarted. To see a list of blocked containers, go to the container audits page under Monitor > Events > Container Audits.
When a container is stopped, Twistlock takes no further action to keep it stopped. Orchestrators, such as Kubernetes and Docker Swarm, start a fresh container in the blocked container’s place. Orchestrators have their own mechanism for maintaining a set point, so they ignore the restart policy defined in the image’s Dockerfile.
There is an exception when you run containers in a Docker-only environment (no orchestrator) and Twistlock blocks a container. In this case, Twistlock must take additional action to keep the container blocked. To prevent the container from automatically restarting, Twistlock modifies the container’s restart policy to always unless stopped. If you want to unblock a container, connect to the node with the blocked container, and manually modify the container’s Docker configuration.
Forensic investigators can inspect a blocked container’s artifacts to determine why it was stopped. You can capture all of the container’s contents, including its file system data, with the docker export command. Go to the node with the blocked container and run:
$docker export [container_id] > /path/filename.tar