The usual fun facts from GitHub: Twistlock 19.07 is the 17th time we’ve shipped a major release, we’ve worked on 15,300 issues, pushed 7,400 commits, built Twistlock more than 1,200 times, and shipped over 390 customer requested features to 400 customers over more than 4 years! Twistlock protects most of the Fortune 10, more than 35% 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:

  • Deploy and manage Defender DaemonSets directly from the UI
  • Automatic selection and load balancing of registry and serverless scanners
  • Vulnerability risk scoring based on whether components are actively running within a host or container
  • Improvements to searching and filtering in container and host Radar
  • Timestamping of vulnerability discovery dates to enable compliance reporting
  • Separate, dedicated compliance policy for functions
  • Improvements to cloud discovery alerting

CNNF v3

Automation Visibility Prevention

Cloud native environments can be especially complex to microsegment. Not only do these environments change rapidly, they also typically have many more endpoints and they rely on software defined networking to virtualize the underlying connectivity, making them opaque to existing east – west firewalls.

We introduced the Cloud Native Network Firewall in Twistlock 2.2 to provide microsegmentation optimized for these environments. CNNF has always emphasized automatic learning as a key capability to help organizations manage the high number of entities and rate of change. Combined with Radar, it not only helps users conceptualize connectivity, but also automatically microsegments traffic, compartmentalizing attacks and limiting their blast radius.

In 19.07, we’re building on these existing capabilities and providing enhanced enterprise manageability on top of them. Specifically, CNNF now adds:

  • Complete Radar visualization of both learned and admin configured connectivity
  • Combined policy view of all connection rules, both learned and admin configured
  • Ability to import and export rules
  • Create, name, and re-use external network objects across rules

These capabilities take CNNF to a new level of enterprise manageability and configurability, while still leveraging automation and learning for the vast majority of discovery and protection scenarios.

Forensics v2

Automation Visibility Prevention

In Twistlock 2.5, we introduced the notion of container forensics – a distributed flight data recorder running alongside all the containers across your environment. Twistlock continuously collects detailed runtime information to help incident response teams understand precisely what happened before, during, and after a breach (assuming you’re not using prevent mode to stop it automatically!). Our unique distributed design is highly performant and only sends forensics packages over the wire when an incident occurs or when an admin triggers it, eliminating the need for costly central data warehouses. In 19.03, we added this capability for hosts as well.

In 19.07, we’ve significantly expanded the scope of monitored data, while continuing to focus on actionability. Rather than simply collecting generic monitoring data, only some of which has a security investigative purpose, we’re intentionally focused on collecting the kinds of data used for actual incident response. We leveraged the skills and experiences of our accomplished Twistlock Labs research team (who’ve discovered more than 15 CVEs in Linux, Kubernetes, and OpenShift) as well as veterans of the Microsoft Enterprise Cybersecurity Group, to optimize the forensic package to be comprehensive, yet lightweight. Improvements include:

  • Collecting detailed information about the host hardware (or virtual hardware), operating system, and configuration
  • Collecting detailed information about the container runtime environment
  • Collecting detailed information about the container itself (for container incidents), including the image running and its runtime model
  • Comprehensive network connection tree
  • Timeline based view of data, making it easy to jump specifically to relevant events within the package

Serverless Radar

Automation Visibility Prevention

Serverless provides a different component interconnectivity pattern than containers. Serverless apps are often highly decomposed and interact via provider specific gateways and services, rather than through the direct or service mesh patterns typically seen with containers (and VMs). At the same time, it can be difficult for security teams to conceptualize these interactions and understand what functions are talking to what high value service assets and thus where their risk lies. While the providers have a strong track record of protecting the underlying FaaS platforms and isolating functions from each other, it’s easy for DevOps teams to deploy functions with vulnerabilities, insecure configurations, and overly broad permissions. Thus, while the underlying platform maybe secure, it’s of little comfort if sensitive data is lost because an insecure function with read access to an S3 bucket is compromised.

In 19.07, we add a fourth Radar specifically built for serverless. Serverless Radar uses existing provider APIs to discover the invocation methods for each function and the services they communicate with and draws them in a three pane view. The leftmost pane contains the invocation methods, like API Gateway. In the middle pane are the functions themselves, color coded by vulnerability, compliance, or runtime state. On the right pane are the backend services the functions communicate with, such as S3. Between the panes are lines connecting methods to functions to services, allowing security teams to visualize the entire connectivity flow and access rights. Selecting individual entities will emphasize their interconnects on the Radar and the entire view is searchable and filterable to enable data slicing.

Trusted Images v2

Automation Visibility Prevention

One of the most loved aspects of cloud native development is the easy reuse of external, often open source, software. Pulling an image from a registry on the internet, like Docker Hub, is simple and fast and removes common friction points in traditional operations. However, this ease of use can be contrary to organizations’ security policies requiring that only software from approved providers and distribution points be used. Twistlock has long had a feature called Trusted Images that allows organizations to specify registries and repositories that should considered trustworthy and then to alert on (or block) the use of images from any other location. While effective, it practically requires that organizations have centrally curated software distribution practices and good integration between the teams responsible for them and the security function.

In 19.07, we’re making Trusted Images far easier to use and more manageable by introducing automatic learning and a flexible, rule based, policy. When the feature is initially enabled, Twistlock will automatically learn the origin of all the images in use across your environment, summarize them (such that future versions of the same app will be included), and suggest a policy that only allows these images to run. Critically, the sources themselves could be numerous and diverse – from internal registries to public sources. The new rule based policy makes it easy to override and supplement this learned list to explicitly allow or deny additional entries and control how they’re applied across different nodes in your clusters.

Deeper and Broader Windows Support

Automation Visibility Prevention

With more than a century of Microsoft experience at Twistlock, we’ve long supported Windows for both host and container Defender. Recently, we’ve seen an increase in the number of customers using Windows in cloud native scenarios and so in 19.07 we’ve invested in adding to our existing Windows feature set.

Improvements include:

  • Production version of CNNF for Windows
  • Compliance checks for Windows covering Automatic Updates, Windows Firewall, and Windows Defender configuration
  • Augmentation of MSRC (Microsoft Security Response Center) vulnerability feed data with NVD CVSS scoring to provide per-CVE scoring for CVEs fixed in Microsoft rollup packages
  • Support for Jenkins on Windows
  • Enhanced risk scoring for Windows vulnerabilities
  • Windows Server 2019 support

Cloud Platform Radar

Automation Visibility Prevention

In 2018, we introduced the Cloud Discovery open source project to provide a simple toolset for discovering all the cloud native services across all the various providers, accounts, and regions an organization uses. Many of our customers have an intentionally multi-cloud strategy and given the growth of providers’ regional locations and their portfolio of cloud native services, you can quickly end up with hundreds or thousands of potential individual deployments. You can’t secure what you don’t know about, so Twistlock includes enterprise capabilities for cloud discovery to make it easy to integrate with IAM, alerting, and to provide single click protection to newly discovered entities.

Once organizations have just a few tens of deployments, though, it can become difficult to understand them from purely textual data. Cloud Radar is designed to make it easy to visualize all these services, across all the different providers and accounts an organization uses, by projecting them on a physical map of the earth, aligned with the actual locations of datacenters. Users can glance at the map and instantly understand where services are running, which are protected by Twistlock, and what their security posture is. Powerful filtering and search makes it easy to slice this data, for example “show me only serverless functions used by development team accounts in Azure”. Like other Radar views, there are multiple data overlays, enabling you to drill down and view vulnerability and compliance for entities in these services without leaving the visual canvas.

← Back to All Posts Next Post →