Security Across the Continuum

Last year, we wrote about the Continuum of Cloud Native Topologies, the notion that cloud native isn’t just about containers but comprises a range of compute technologies that bring different advantages and tradeoffs around compatibility, control, and agility. Building on this vision, Twistlock became the only platform to provide comprehensive security for both containers and serverless. As we’ve talked with customers since then, we’ve often been asked to expand further and cover the entire continuum to help secure their VMs as well. While many security providers already offer products that can run in VMs, they’re often just rehashed legacy endpoint protection and are not optimized for the kind of automation and statelessness that defines cloud native.

In Twistlock 19.03, we’re proud to announce the world’s first truly comprehensive cloud native security platform – protecting across hosts, containers, and serverless in a singular product, cloud native and API enabled itself, covering all your workloads regardless of what underlying compute technology powers them. Gartner tracks a market they call Cloud Workload Protection Platforms, which are designed to protect server workloads across public and private clouds. However, even users of these platforms often tell us that the solutions are incomplete (often focusing on just a single aspect of security) and archaic (requiring heavy agents and without API enablement). Our approach is different because we’re not repacking legacy technologies or focusing on only a single aspect of host defense. Instead, Twistlock provides vulnerability management, compliance, runtime defense, and firewalling across all your VMs in all your clouds. We’re able to do this because we started on the harder problem first – containers, where you have many more entities, they’re all ephemeral, and they’re changing all the time.

VMs have been around for long time and are used in many different scenarios. We’re explicitly not trying to address all of them. Instead, we’re focused on modern, cloud focused deployments that assume automation and statelessness. We’re focusing on securing your cattle, not your pets. If you’re using tools like Ansible or Terraform to create and manage your infrastructure as code, Twistlock is the security solution you’ve been looking for.

This isn’t a shift in strategy, but an expansion of it. As you’ll see below, we continue to heavily invest in container and serverless features but adding VMs provides truly comprehensive and consistent protection across all your workloads regardless of where on the continuum they’re run.

The usual fun facts from GitHub: Twistlock 19.03 is the 16th time we’ve shipped a major release, we’ve worked on 12,700 issues, pushed 6,300 commits, built Twistlock more than 1,000 times, and shipped over 300 customer requested features to several hundred customers over the past 4 years! Twistlock now protects most of the Fortune 10, a third of the Fortune 100, and most Cabinet level agencies in the US Government, including all Department of Defense branches.

In addition to the major new features below, this release includes dozens of other smaller improvements including:

  • Native Helm support – generate ready to run charts for both Console and Defender directly from twistcli
  • Directly download twistcli, the Jenkins plugin, the Defender image, and Daemon Set YAML directly from the Console web UI
  • Upload debug data to our solution engineering team directly from the Console web UI
  • Real time log ingestion, analytics, and alerting for the Kubernetes AuditSink
  • Drag, drop, and disable rules within policies
  • Simplified vulnerability management policy
  • Separate host and container policies for compliance and vulnerability management
  • Enterprise proxy compatibility – integrate with ingress and egress proxies that require authentication and/or perform TLS intercept
  • IBM Security Advisor integration for alerting
  • Updated support for Google Cloud Security Command Center

— the Twistlock R&D and product teams
Herzliya and Baton Rouge

Cloud Native Network Firewall and Radar for Hosts

As VMs move to clouds, one of the key challenges is maintaining a least privilege networking model for the apps they run. VPCs and security groups are effective perimeter controls, but they provide a coarsely grained capability for segmenting traffic on a per-workload basis. While host firewalls provide additional ability to limit traffic, they’re isolated and require manual rule creation and management. Cloud VMs are typically running a single app workload, though, and so the same kind of connectivity learning, modeling, and enforcement Twistlock does for containers can be extended to protect hosts as well.

Cloud Native Network Firewall for hosts is a distributed layer 3 / 4 firewall that stresses automated learning and workload awareness to effectively isolate apps in a least privilege connectivity mesh. CNNF eliminates the need to manually define rules and rely on low level primitives like IP addresses and host names, instead taking an app centric view of connectivity. CNNF for hosts builds on the host runtime defense capabilities in Twistlock to create a connectivity model for each app in your environment – the ports it listens on, the protocols used, and it’s inbound and outbound traffic flows. Critically, these models are app centric, not host centric, meaning that as you scale workloads across many VMs, the models are automatically applied, regardless of the cloud provider, region, or VPC the VMs run in.

In addition to showing network topology, Radar for host displays vulnerability, compliance, and runtime state in a familiar, immersive ‘Google Maps’ UI. Easily identify apps impacted by CVEs, insecure configurations, or where attacks have been detected and prevented, all from a consistent visual interface.

Read more about CNNF and Radar for hosts

Host File Integrity Monitoring

File Integrity Monitoring is a central control in many organizations’ security and compliance policy. FIM enables monitoring of host file systems for specific changes to directories and files by specific users. For example, your security policy may require that only certain users are able to access /var/customer-data and that you will be alerted on any unauthorized access attempts. With Twistlock, you can set a policy to monitor for any access to this path and get alerts any time an unauthorized user attempts to access it.

Read more about file integrity monitoring

Host Forensics

In Twistlock 2.5, we released a first of its kind continuous forensics capability for containers. We often refer to it as a ‘flight data recorder’ because it’s keeping a rolling log of process and network forensic data for each container. Critically, though, because it keeps this spool locally and manages it in a first in, first out manner, this forensic capability can be provided with low performance and operational impact. Only when an incident occurs is the data automatically pushed to the Console for analysis (though it’s available to be pulled on demand), so there’s no need for huge data warehouses nor planning for additional bandwidth consumption.

In 19.03, we’re bringing this capability to hosts as well. Host forensics works in a very similar manner to container forensics, keeping a self-managed, high performance local log of forensic activity and selectively forwarding this data to Console only in case of incidents. Host forensic data is available to view and export directly from the Console web UI and can also be pulled on demand from any host.

Read more about host forensics

Custom Runtime Rule Language

Machine learning driven modeling continues to be at the core of how we scale runtime defense without requiring manual rule creation and maintenance. Rules continue to be a way to declaratively supplement those models with predefined behaviors in a simple visual UI. In 19.03, we’re adding a new advanced capability to provide even more control over discrete runtime behaviors for both containers and hosts.

Our custom runtime rule language is a simple, intuitive, expression based approach to define discrete runtime behaviors at a level of precision beyond what’s possible with existing rules. For example, a custom rule could express logic like “if user jake runs netcat with a listener, log an alert”. These custom rules enable you to specify exact conditions to watch for and exact actions to take when they’re encountered.

All individual custom rules are stored in a central policy library within Twistlock such that they can be reused across multiple environments and policies. The library is updated via the Intelligence Stream with new rules curated by Twistlock Labs and available for you to optionally reuse within your own environment.

Read more about custom runtime rules

Cloud Compliance v2

Last November, we released the open source Cloud Discovery tool that makes it easy to identify all the cloud native services used across all your cloud providers, accounts, and regions. In the main Twistlock product, we build on this foundation with central credential management, graphical configuration, continuous assurance, and reporting. In 19.03, we’ve expanded the scope of coverage to cover all cloud native services on Azure and Google Cloud Platform and show rich metadata about each service directly in the Console web UI.

19.03 also adds a deeper compliance capability for AWS, by providing the CIS AWS Foundations Benchmark checks. These checks are managed like just another type of compliance check within Twistlock and you can customize the checks to your own organization’s individual needs. The CIS Benchmark covers areas including IAM, logging, monitoring, and networking from the perspective of the AWS platform itself. They complement our existing sets of CIS checks for Docker, Linux, and Kubernetes and most organizations would use them together, each focused on compliance for a different layer of the stack.

Read more about cloud compliance

Assigned Collections

Projects are Twistlock’s built in solution for multi-tenancy and scale. Introduced in Twistlock 2.4, Projects enable you to have multiple completely independent environments federated behind a single Console URL, interface, and API. Groups are provisioned with access to specific Projects and only have access to those they’re explicitly entitled to. Projects provide a true security boundary but can be a ‘heavier’ solution than the ideal for simple scenarios like only allowing a development team to see images related to their own apps.

In 19.03, we’re introducing assigned Collections to make it easier to provide least privilege access to data within any given Twistlock Project or environment. Collections are simple view filters that can be created based on regexes and labels associated with images, containers, functions, and hosts.

In 19.03, you can assign Collections to specific users and groups and thus limit their ability to only see data that matches those Collections. These are many:many relationships and a given user or group can be assigned many Collections simultaneously and multi-select amongst them directly in the Console web UI. For example, you may define Collections like front-end and back-end, assign the SAML group “Front End Devs” only to the front-end Collection, assign “Back End Devs” only to the back-end Collection, and assign the “Dev Managers” group to both Collections.

Read more about assigned Collections

RASP Defender

As Docker has become a near universal app package standard, we’ve seen a proliferation of services that, while they run Docker images, do not actually use Docker or OCI runtimes. For example, Pivotal Cloud Foundry PAS can run Docker images, but uses a non-Docker and OCI runtime. Other services, like AWS Fargate and Azure Container Instances, use a Docker runtime but in a highly constrained environment where Defender can’t run with the elevated access required. To solve both of these scenarios, we’re introducing the new RASP Defender.

RASP (Runtime Application Self Protection) is an industry term for embedding security within an app, rather than relying on an external tool. RASP Defender is a simple binary that runs as part of an app (even a non-containerized app) and provides automatic process and network based runtime defense, such as preventing anomalous processes from starting and blocking access to undesired DNS namespaces. RASP Defender starts before the protected app and then immediately invokes it, giving it a para-administrative capability over the app itself, regardless of the underlying runtime and without requiring privilege within the host OS.

RASP Defender builds on the simple, automated integration we introduced with our initial Fargate support by taking a Dockerfile and returning a ready to build bundle with an updated Dockerfile and all the required Twistlock components to embed. This eliminates the need to manually modify your images or intermingle app and security tools. The entire process can be automated via an API to enable making it a core part of the CI process. Additionally, for apps not packaged in Docker images, RASP Defender provides a manual option in which users are provided the binary, environment variables, and simple instructions for protecting any app, regardless of how and where it’s run.

Read more about RASP Defender

← Back to All Posts Next Post →