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.
It is a never-ending task of security architects to keep up-to-date with how their applications behave on the network. As new development styles emerge that demand faster release cycles, more features, and new capabilities it can be difficult to both retain knowledge of your deployments as well as keep them safe on your network.
Network security for traditional VMs
The problem of securing these more rapid deployments led us to introduce Twistlock Cloud Native Network Firewall (CNNF) in Twistlock 2.2. This feature, along with our Radar view, provides excellent protection and awareness of your containerized workloads, helping you identify how your applications behave on the network as well as give you immediate visibility into anomalies that operate outside of the norm. With Twistlock 19.03 we look to expand beyond this with CNNF for hosts as well as a new Radar view for hosts to help you add additional protection to your workloads that are running on traditional VMs.
Radar for hosts
Now, when on the Radar view in 19.03, you are presented with a simple toggle that lets you view all of your host-based services. While containers typically have one main process that represents their primary function, traditional hosts do not necessarily function this way. For this reason, we represent the Radar view based upon various services running on your hosts without focusing on the underlying host details and map out how each of these services communicates with each other. This topology means that even if your hosts change IP addresses, or you periodically need to rebuild your environment, you can still ensure you have a clear picture into how the services work separate from the specific IP addresses that may be involved.
These services may not all connect over the network or communicate to other services in your environment, so we present an easy toggle to be able to show only connected apps versus a full view of all of the services in your environment.
Similar to our container-based radar, we still show you the number of instances of these services that are running regardless of what hosts they are running on to give you a more cloud-native oriented view of how your services are behaving.
For this example, we are using a simple client service that pulls down a webpage from our server service over a specified port. We can get a clearer picture of how this app typically communicates by taking a look at our Radar view once again, this time only looking at the connected services.
CNNF for hosts
Once you have a good idea of how your services are behaving, you can move toward ensuring you are adequately protecting your services as well. Now with our Cloud Native Network Firewall (CNNF) having expanded capabilities including host protection, you can ensure that you have full protection for your services on your traditional hosts in a multitude of ways. By navigating to Defend > Firewall > CNNF for Hosts we can add some additional rules that help us protect our service.
When we first create a new rule by clicking the add rule button, we are presented with multiple options of how we would like to protect our services, we can either do this by specifying an IP address or by specifying a particular application service we would like to be the basis of our rule. The only requirement is that at least one of the source or destination entries must be a Twistlock protected service.
In this case, we are specifying two Twistlock detected services or apps. We add the client that is making the web requests as the source, and the server endpoint as the destination. We can then specify that we want any requests from this app to the server to be alerted upon as an incident. Of course we could be more granular by specifying a particular port or range as well instead of all ports. This is completely configurable based upon your needs. After saving my rule, and waiting for my service to initiate communication I can detect that anomalous traffic has occurred and an event is created under Monitor > Events > CNNF for Hosts as seen in the screenshot below.
In addition, we should now be able to see the event represented on our Radar view in orange indicating that there was an incident between these two services.
The greatest feature of all for this new capability, is that even without me setting rules, the same automatic learning that is within our CNNF for containers is still available for hosts. As I continue to add more of my hosts to Twistlock protection, models of how my services behave and communicate becomes more rich and over time, alerts for anomalous traffic will be produced without me even statically setting rules within CNNF. This can help ensure that even your most complex services can be protected automatically just due to learned traffic patterns and you can have quick alerts for anomalous behavior where we may not have predefined rules to protect all of our services from threats in your network.
The Cloud Native Network Firewall and Radar updates for hosts are a key update in our pursuit of comprehensive protection for all of your workloads. Now, even if you have not migrated your workloads to containers or serverless, you can expect the same network protection on your traditional hosts as we offer on our container based platforms. Automated learning capabilities as well as our radar view, should help simplify the complexity of securing traditional host environments, without having to worry about spending all of your time following rigid firewall rule sets across your environment.
- 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