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.
When adopting a cloud native approach to IT, security teams have a much larger surface area to cover from a security perspective. Security needs to think about where and how they deploy security in new ways. There are tools out there that cover small slices of the total security need and they are generally good at what they do, but you’re left with many disconnected dashboards and potentially integration nightmares. This has to do with the fact that you are now securing hosts, containers, clusters and serverless functions. Thankfully, Twistlock has taken a cloud native approach to developing complete security and provides best-in-class protection for each of these entities under a single platform.
Expanding host security capabilities
Twistlock started as primarily a container based security company but our customers continually asked if we could provide the type of protection we do for containers at the host level. Twistlock 19.03 takes our host-based protection to version 3 adding in a whole host of features. In this blog I will walk you through one of our new features: File Integrity Monitoring (FIM). Twistlock already offers FIM for inside containers, but now extends this capability to the host. This is a key functionality for compliance and security of your systems.
File integrity monitoring: Deep dive
File integrity monitoring ensures that if the contents of a file changes you are notified. Twistlock accomplishes this by monitoring the read and write attempts to a specific path or file system hierarchy. This functionality is important to ensuring that your most critical resources are not modified, such as private certificate chains, configuration files or static content. The modification or attempt to modify a file path can signal that a potential attack is in progress. In addition to potential attacks FIM can also be used to monitor against unintended changes (such as a new deployment script) or unauthorized changes (a new developer attempts to deploy his configuration). Not every attempt to modify a file is malicious but it is important nonetheless to ensure your files have the expected content.
An attack scenario
For example, let’s assume someone wanted to read the data in your database. You have security in place that encrypts all data-at-rest and tight control over your passwords. The attacker is having trouble breaking in directly. So, an alternate plan is hatched. The attacker notices that you are exporting the data nightly to an encrypted file that is uploaded to the cloud. Without the encryption keys they are not able to decrypt that data it remains secure from the attack. As they continue to explore the system they realize that (through an exploit or maybe bad file permissions) they are able to overwrite your private key. By overwriting the private key, the next time automation kicks in to export the database you encrypt the export with their key instead of yours. Now by simply downloading and decrypting that file they have access to your data. In this case, file integrity monitoring would have stopped them by disallowing the write operation to overwrite your key and alerting you to an attack in progress.
File integrity monitoring is also a requirement for some compliance standards. PCI compliance for example requires:
PCI 10.5.5: Use file integrity monitoring or change detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert).v File integrity monitoring or change detection systems check for changes to critical files, and notify when such changes are noted. For file integrity monitoring purposes, an entity usually monitors files that don’t regularly change, but when changed indicate a possible compromise. Reference
PCI 11.5: Deploy file integrity monitoring software to alert personnel to unauthorized modification of critical system files, configuration files or content files. Configure the software to perform critical file comparisons at least weekly. Reference
Enabling FIM within Twistlock
Enabling file integrity monitoring in Twistlock is pretty straightforward. To protect against changes to files, we can simply add a new file integrity monitoring rule to Twistlock through the UI or APIs!
In this example, I will attempt to change the application configuration file I’m using for my web application.
- Create the new FIM rule by navigating to Defend > Runtime > Host Policy:
- Modify the rule to protect our application configuration under the File Integrity tab and save the rule:
- Make a modification to the file. In the example below I used various tools to read and write to the application.cfg generating alerts.
- When we examine the alerts we see the path that was modified, a description, the action (read or write) as well as the host where the modification occurred:
File integrity monitoring is a key feature in modern cloud security architecture. It helps prevent attacks on critical data that can lead to data loss or application downtime. Twistlock provides file integrity monitoring for both your containers as well as your host so regardless of your application’s architecture you are covered. With the many advancements in our host based protection customers are now able to consolidate the tools they use and take a cloud native approach to security using 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