Segmentation of assets in the data center is not a new concept and has been a common practice as the first step to securing the applications. However, modern applications are not only within a company’s physical data center but also deployed across a multi-cloud environment, creating operational challenges.
The applications are also getting complex, hyper-distributed and dependent on multiple shared services. At the same time, legacy applications, core to critical business processes may no longer receive maintenance releases or patch updates, creating a vulnerability.
How do we protect these applications – or rather the workloads that form these applications?
The solution seems rather simple – attach the security policy to the workload. This is commonly known as micro-segmentation. As the workload moves around, policy goes with it. Breaches keep happening and lateral movement of threats is sadly still common. It’s apparent that the complex modern data center requires more capabilities; segmentation purpose-built for securing the workload.
So, where do we go from here?
Begin at the beginning, and go on till you come to the end – Lewis Carroll, Alice in Wonderland
Step 1: Assess your application dependencies and current security policies
The applications you currently have in your data center or in the public cloud have been built and deployed over a long time, likely having vulnerabilities that can be exploited by a malicious adversary. The common issues are:
- Insufficient access control, open/exposed ports or traditional black-list policy model, i.e. only block known bad actors
- Vulnerable software packages, e.g. vulnerability to WannaCry, Spectre/Meltdown etc.
- Large attack surface or poor segmentation
Protecting the workloads, therefore, requires a holistic approach to understand everything running and installed on the workload, as well as communications between the workloads to establish a clean baseline. And this has to be done across thousands of workloads in an average data center. You have to discover each component of the application and map out the dependencies before making any changes to the security policy so applications don’t break.
Current solutions rely on manual approaches such as a system of record, e.g. CMDB, Service maps, and in some cases, yes, excel. Some vendors offer semi-automated approaches to attach a ‘tag’ to each workload so they can be grouped together, making application dependency mapping an easier process.
But imagine tagging 1,000 workloads! How about 10,000? Or, if you operate a mid to large operation, 100,000? Now, imagine what happens when new workloads are on-boarded, or some of these workloads change …
We can do better!
Cisco Tetration collects over one hundred attributes from thousands of workloads, infrastructure (Network, load balancers, AWS), orchestration systems, and other systems of record in real-time. This includes metadata about every process, every software package, and every flow/packet to name a few.
Based on these attributes, Tetration maps out all application components and dependencies in a zero-knowledge environment using unsupervised machine learning. Think of this as a fingerprint of your application, based on behavior such as what’s running on the workloads, who they talk to, how often, when and in what pattern.
Equally important, Tetration tracks all these attributes over several months to capture application seasonality and evolution. More on this in Step 3!
Step 2: Define your big ‘P’ policy
What you get from baseline will usually surprise you. You may have a simple policy that web traffic does not directly hit your database servers, and yet there you see it.
So, it’s time to harden your security policy. Tetration recommends a white-list or zero trust policy based on the observed behavior and allows you to make changes to the policy.
The policy is defined by using the attributes discovered by Tetration, and therefore is dynamic in nature. You can also call it ‘intent’ or the big ‘P’ policy. An example would be, “Block all workloads with known vulnerabilities from communicating with database servers that have sensitive data.” Tetration continuously translates the intent to concrete rules based on current attributes of the workloads.
You define policy once and let Tetration manage the rest.
Tetration also accounts for policy hierarchy and does automatic conflict resolution. If an app developer and database owner both agree to allow communication, but a higher order InfoSec rule denies it, Tetration will resolve in a deny action. The platform is role-based, access controlled and the roles can be mapped to administrative domains.
Step 3: Test your policy
How confident are you that the ‘intent’ you just defined will in fact not break a critical application, or would prevent a breach that occurred in the past?
Policy testing and simulation is a very critical and often overlooked step. It requires the ability to see the impact of change in real-time plus the ability to test for seasonality at critical junctures. If you’re a retailer, your policy needs to work today and at Thanksgiving.
Tetration stores several months of data on the platform, allowing you to test the impact of your policy changes in real-time, as well as run experiments with backdated traffic. All changes to the policy are tracked for auditing. If an experiment produces undesirable results, you can switch back to an older version of tested policy.
Step 4: Enforce the policy
There has been considerable debate on where to enforce the segmentation rules, and every vendor has a preference based on what they can deliver. Should you enforce the policy on the workload using native OS capabilities like IP Sets, use a distributed virtual firewall and stitch traffic through it, or enforce in the network fabric? And what about the perimeter firewall?
How about everywhere?
Tetration decouples the policy creation and translation from policy enforcement. It’s an open policy model that can be used to implement policy in any plane through a REST API or a Kafka stream. Tetration enforces policy on the workload natively, and also streams that same policy to other infrastructure elements such as firewall orchestration systems, load balancers and SDN controllers, and the public cloud. The same policy model is used for bare metal, virtual and containerized workloads, both on-premises and in the public cloud.
Step 5: Monitor, report and adapt to change in environment
Tetration monitors for workload attributes in real-time. It also ingests data from threat intelligence and analytics solutions, with the ability to generate policy compliance alerts. Tetration can compute and enforce the policy rules based on the change, in real-time. If a new software vulnerability is found, or a host gets compromised, the Tetration policy model can quarantine the culprit in seconds.
Tetration takes a holistic and full lifecycle approach to workload protection and application segmentation. Policy orchestration/enforcement alone is not segmentation; it’s about 20% of the whole problem. Moreover, the solution needs to be real-time and scale to thousands of workloads.
As part of the overall solution for workload protection, Cisco provides the most comprehensive solution as part of an architectural approach. Cisco Tetration works with Cisco’s security portfolio, including Cisco Firepower Next-Generation Firewall (NGFW), Next-Generation IPS (NGIPS), Advanced Malware Protection (AMP), and Stealthwatch, to deliver effective security that follows the workload everywhere.
To learn more, please visit www.cisco.com/go/tetration.
CONNECT WITH US