This technical deep dive highlights key capabilities released as part of Twistlock 19.03. To learn more about what’s included with Twistlock 19.03, check out our full release blog post.

Runtime defense is the set of features that provide both predictive and threat-based active protection for running containers and hosts. For example, predictive protection includes capabilities like determining when a container runs a process not included in the origin image or creates an unexpected network socket. Threat based protection includes capabilities like detecting when malware is added to a container or when a container connects to a botnet.

Expanding runtime defense

Twistlock introduced runtime defense all the way back in our 1.1 release. In releases since then, we’ve continuously added to the feature set. The latest release of Twistlock 19.03 now supports an open-ended, simple policy language with an integrated development environment (IDE) into the Console UI. It enables fine grained and discrete control of runtime actions for hosts and containers.

Custom runtime rules define specific, precise runtime defense actions for containers, hosts and Kubernetes audits. The following types of runtime rules can be specified:

  • Processes (using process name, process path, process parent name, process user, process service, process command line, process interactive)
  • Filesystem (using filesystem path, filesystem directory and file system type)
  • Network (using network outgoing IP address, networking outgoing port, network private subnet)
  • Kubernetes Audits Events

How to use it for containers and hosts

You can start to specify your own Custom Rules inside the Console at Defend > Runtime > Custom Rules. You can export and import rules or add a new rule. For each rule you have to define a Name, a optional Description, a Message for Audits or Incidents, the type of policy and the runtime policy itself.

For example let’s start to define a new rule that will check if a process with the name nmap was spawned and it was done by a non-root user or the process was spawned interactively. A rule specification would look like this:

proc.name = "nmap" and (proc.interactive or proc.user != "root")

Another example for a filesystem specific custom runtime rule type could be to check if a non-root user modifies a sensitive file under the system folder /etc. A rule specification would look like this:

proc.user != "root" and file.dir = "/etc"

You can also define policies based on network specific events. For example you could check if someone is connecting to some suspicious ports that are typically used for crypto miners. A rule specification would look like this:

net.outgoing_port in (8545, 8332, 51235, 22555)

When you define a custom rule policy you can also use the Ctrl+Space for autocomplete of net. proc. or file. sub categories, which is quite helpful if you are defining custom runtime rules for the first time. The following sub categories are available for autocomplete:

Processes:

  • proc.name
  • proc.path
  • proc.pname
  • proc.user
  • proc.service
  • proc.cmdline
  • proc.interactive

Filesystem:

  • file.path
  • file.dir
  • file.type

Network:

  • net.outgoing_ip
  • net.outgoing_port
  • net.private_subnet

The Process, file system and network-outgoing specific rules can now be added to a Container or Host runtime defense policy via the Select Rules button:

Container Policy: Defend > Container Policy> New/or Existing Policy > Custom Rules > Select Rules

Custom rules are processed like other rules in Twistlock: the policy is evaluated from top to bottom until a matching condition is found. After the action specified is performed, rule processing stops for the event.

For each container custom rules policy you can define the following Effects:

  • Allow: It will allow the custom runtime rule event and will not log any audits or incidents.
  • Alert: The Defender will raise an alert when it detects the specified runtime rule.
  • Prevent: The Defender will Prevent the process or filesystem activity. You can’t specify a prevent for network-outgoing events.
  • Block: The Defender stops the entire container if a process, file system or network outgoing event rule occurred.

You can also specify if an Alert, a Prevent or a Block will be logged as an audit or incident:

Host Policy: Defend > Host Policy > New or Existing Policy > Custom Rules > Select Rules.

For each host custom rules policy you can define the following Effects:

  • Allow: It will allow the custom runtime rule event and will not log any audits or incidents.
  • Alert: The Defender will raise an alert when it detects the specified runtime rule.
  • Prevent: The Defender will Prevent the process or filesystem activity. You can’t specify a prevent for network-outgoing events.

You can also specify if an Alert, a Prevent, or a Block action will be logged as an audit or incident:

How to use it for Kubernetes Audits

The latest release of Twistlock 19.03 also supports the custom runtime rules for Kubernetes Audits. For this, it’s important to enable the Defend > Access > Kubernetes auditing > Enabled:

Please make sure your Kubernetes Version (>=1.13) supports Kubernetes Auditing and it’s enabled within your Kubernetes Cluster https://kubernetes.io/docs/tasks/debug-application-cluster/audit/.

You can easily add the Kubernetes auditing by using the Go To Settings configuration:

You only need to specify if it is a Default Kubernetes or Google Kubernetes specific deployment.

Right after that you can start to specify your first kubernetes-audit type of runtime rule. For example you can create an alert if there are any authorization failures with the Authorization framework of Kubernetes. A rule specification would look like this:

jpath("annotations") contains "authorization.k8s.io/decision:forbid"

Another example would be to check for any exec or attach to any pod. A rule specification would look like this:

jpath("stage") = "ResponseStarted" and jpath("objectRef.resource") = "pods" and jpath("objectRef.subresource") in ("exec","attach") and jpath("verb") = "create"

The current Kubernetes audits will be shown at the Monitor > Events > Kubernetes Audits. You can use the default Twistlock Alert mechanism to trigger specific actions. For example you could trigger a custom webhook that will execute some actions based on the Kubernetes audits.

Twistlock policy library

In addition to the policies you create, Twistlock maintains a policy library that’s dynamically updated via the Intelligence Stream to respond to new threat scenarios.

Summary

The new Custom Runtime Rule Language is a great extension of the runtime defense capabilities and the Kubernetes Audit logging. In combination with the alert, prevent, and block mechanism of Twistlock, you get a powerful toolset for reporting and also automating actions based on these events.

← Back to All Posts Next Post →