This technical deep dive highlights key capabilities released as part of Twistlock 19.07. To learn more about what’s included with Twistlock 19.07, check out our full release blog post.
Last August, Twistlock released the first cloud-native forensics platform aimed at delivering forensic information about your containers to help your security and incident response teams understand the activity taking place in your environment. Then, in version 19.03, we expanded this feature set to include host level forensic information to give even more forensic coverage across your workloads. This primarily covered process-related information on your containers and hosts.
In Twistlock 19.07, we have expanded the scope of forensic data we collect to help your incident response team ingest and act upon incidents when they occur in your environment. We’ve worked with our customers and security experts to ensure that our forensic data focuses on the items that are most critical to your security personnel and incident response teams. As part of this, we have completely redesigned the UI around forensics to make this information easier to understand and act upon.
Why forensics is important in a cloud native world
When a container or host runs in an environment protected by Twistlock, you’ll use a defense-in-depth strategy to deter and detect attacks in your environment. Even if you’re patching all your vulnerabilities and running in a compliant manner, from time to time you will still detect incidents in your resources. When these incidents are generated, they could signal anything from an operator interacting with a host to an official security breach. You will quickly want to assess the situation to understand which category you’re dealing with and decide how you want to handle your next steps. Even if you are using Runtime Defense to prevent anomalous behavior from executing or to block your containers when behavioral drift is detected, understanding how and why this activity is taking place is vitally important.
Forensic data provides context
The goal of forensic data is to provide context to your security personnel or incident response teams to understand what happened on the resource, and, ideally, how it was able to happen in the first place. Forensic information collected around an incident will show not only what happened during and immediately after the attack, but what happened leading up to the incident to provide the much-needed context to help respond to the incident and to remediate your system to prevent these events from happening again.
Deep Dive: Cloud Native Forensics
In 19.07, Twistlock features a completely revamped user experience around forensics. First, you’ll notice a detailed timeline view showing you clusters of when events happened on your container or host. This helps you quickly spot patterns or even anomalies at-a-glance. Each event type can be toggled on or off and the grid below responds, letting you filter down to only the most relevant event types.
Users can inspect each individual event to see even more details than we provided before. Depending on the forensic event type, you can see the message generated, along with the attack type, the timestamp, user, command, port number, and more. You can even filter the events by a date range or search the audit messages to quickly locate the information you deem most important.
New forensic types
In 19.07, Twistlock collects more forensic events for your workloads and correlates that in one view with existing information collected in your environment. In the screenshot below, you can see the forensic information around an event detected in a struts2 container. We are not only showing information about when your container started and when processes are spawned, but we are now collecting what ports are opened as listening ports and a timestamp of when the listening begins.
We also show more information than ever before about the behaviors being learned as part of your runtime modeling. In Twistlock, our Runtime Defense uses machine learning to construct models of good behavior for your images and allows you to alert or prevent on anomalous behavior, or even block the container in the case of behavioral drift. Now, as the models are built, you can see forensic information showing when each activity was added to your runtime models. Then, when anything violates your runtime policies, you can see the runtime audit in your timeline view to better understand how the deviation was able to happen and what actions followed the incident in order to understand the breadth and scope of the incident.
Forensic package export
All of this information can be exported as a forensic package so this can be retained in the case of auditing or data retention needs. The forensic package can be opened as a spreadsheet so you can pull out any relevant information and leverage the data to facilitate planning or to develop playbooks for your red team to test your environment in the same way in the future to make sure your remediation efforts were successful.
Our forensic architecture is primarily distributed, so the Defenders running in your environment collect your Forensic information and that is only fetched when a user views this data in your Console. However, many times you may research an incident where the host has been scaled down or replaced in your environment.
Forensic Snapshots allow you to retain the forensic information collected during an incident in your Console, allowing you to deep dive into your events even if a node has been destroyed. The number of snapshots stored defaults to 100, but you can customize this to fit the needs of your environment. Plus, as always, you can use our API to download your incidents to enable further automation of your incident response workflows.
Forensic research is a key tool in understanding incidents when they occur in your environment, but they are not a panacea for all your problems. Instead, consider forensics as one of the tools in your arsenal and you deploy and enact layers of security throughout your environment by leveraging the many defenses provided by Twistlock. In your Twistlock Console, be sure to define your vulnerability policies, enforce your compliance posture, enable and monitor the runtime of your containers through Twistlock Runtime Defense, and to use your Cloud Native Firewalls to prevent lateral movement in your environment. Even with these, know that, in the case that an incident is still triggered, you’ll have the tools to research and identify the breadth and scope of the attack by using your cloud forensics through Twistlock.
- Twistlock Platform
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
How to Lock Down the Kernel to Secure the Container HostRead the Blog
One Chapter Ends, Another BeginsRead the Blog
The Greatest Security Risks Lurking in Your CI/CD PipelineRead the Blog
Cloud Platform Radar: Powerful Cloud Asset IdentificationRead the Blog
Securing Serverless Functions: Visibility with Serverless RadarRead the Blog