Growing up in Britain, a fair share of our history lessons covered the black death. It was a truly horrible plague that affected all without prejudice, ravaging the young and old throughout towns, cities, countries and the continent with seemingly no end.
Surprisingly, it’s hard to remember everything from that class (hey, it was quite a while ago!), but one thing that does stick is how simple the path was to eliminating the disease: practising simple hygiene. Hygiene doesn’t necessarily kill every single pathogen, but it dramatically reduces the attack surface.
Today, hygiene is something we take for granted. We expect people to take reasonable care of themselves, whether at home, in a fast food restaurant, or on a plane. Hygiene is a good thing.
The Recent Plague: WannaCry
Security researchers are clear: WannaCry was not a particularly smart or advanced threat; it simply took advantage of an incredibly widespread exploit. It thrived because of a complete lack of data centre hygiene, allowing it to spread widely. The Cisco Talos team wrote an excellent and widely shared blog on WannaCry.
So, what’s data centre hygiene, you ask?
Much like human hygiene, it relates to two easily understood practices to protect yourself and others:
- Stay clean, and keep your immunisations up to date.
In the data centre world, this is equivalent to keeping all (yes all!) of your servers up to date with every security patch.
- Limit interaction with others to only what is necessary.
Limit interaction with others to only what is necessary.
It’s a simple statement. And a simple idea. But it’s hard to do.
Whitelisting is the data centre version of ‘limiting interaction with others to only what is necessary.’
The Australian Signals Directorate (the counterpart to the USA’s NSA) posted a field notice in April 2012 specifically instructing government entities to begin moving towards whitelisting.
In fact, they list it as their number one strategy for mitigating cyber threats – above patching machines. Yes, above. Let that sink in.
Taken from ASD “Strategies to Mitigate Cyber Security Incidents Notice“
In technical terms, it means that all communication is blocked by default and you must specifically enable communication to only those who are deemed necessary.
It is the data centre equivalent to your mum’s advice of ‘don’t talk to strangers.’
For many years, unfortunately, this advice has gone unheeded; a dangerous majority of data centres simply do not whitelist traffic. Usually network segmentation consists of a few boundaries, heroically guarded by firewalls, checking all whom enter or exit, but once inside the trusted zones, lateral movement is not controlled, save the limited isolation that VLANs and subnets provide (hint: it’s not much).
Perimeter security is traditionally given the lion’s share of attention. It’s effective, and easier than whitelisting. But it doesn’t solve every problem, leaving the inner data centre open for attack.
Whitelisting doesn’t replace your VLANs, subnets, and firewalls. We found the Cisco NGFWs were particularly effective at blocking WannaCry traffic. Bolstering one line of defence must not come at the expense of lowering your guard on another.
But whitelisting is hard…
It’s no secret – whitelisting can (and often will) break production applications if not performed with thorough care and attention. It’s the same reason why, even though Microsoft released a patch for WannaCry an entire month prior (the day of which the Cisco Talos team released detection signatures), so many were left unprotected: organisational inertia.
When presented with the very real choice of breaking business critical applications at the cost of improving security, the decision is often taken to continue operating as is, with the hope that we won’t be targeted and it will all just simply blow over.
Conventional wisdom. But what happens when the attack is indiscriminate and you end up as collateral damage?
So, back to why is it hard? First, what’s not hard: implementing whitelisting. There are many solutions on the market that promise to implement your whitelist for you, sold under many guises, the most common term being “micro-segmentation”.
Most solutions will do what you are looking for, save one incredibly important and oft overlooked point: they won’t help you derive what your whitelist should look like – that’s the really hard part. Without that knowledge, you are doomed from the start when implementing whitelisting.
Even the most advanced organisations simply cannot manually manage the complicated, interwoven set of dependencies that any real-world data centre application is a part of. Without that knowledge, you risk implementing incomplete or incorrect whitelists, which has the net effect of breaking the applications you intend to protect.
Analytics are here to save the day
By consuming huge amounts of detailed network and application telemetry, analytical tools can help you build that whitelist policy you so desperately need.
But what if you had access to an analytics platform that not only could understand and recommend your whitelisting, but could actually implement the whitelisting? By applying micro-segmentation in both the network and on your workloads, the platform constantly watches your network and applications, alerting you to out of policy behaviour. And it keeps track of every single conversation across your data centre 24/7, 365 days a year, for those times when you must know exactly what happened in the past.
The Cisco Tetration Analytics Platform
Cisco Tetration Analytics was built by a team of engineers dedicated to improving the hygiene of our customers’ data centres. We understand the real-world pressures and difficulties you face, and strive to provide you the knowledge and tools to transform and secure your data centre.
We don’t claim to hold a panacea for every threat you may face, but we do provide you with a simple and clear execution path to an infrastructure-agnostic, behavioural analytics-driven whitelist data centre, with the intent to help you rest well at night.
Sound interesting? Read on to find out how we can help you run an analytics-driven, secure data centre.
Before the attack – discover, enforce, harden
Whitelisting is not a reactive tool. You must begin the whitelisting on a sunny day, in preparation for the rainy day.
Tetration uses a combination of software agents and/or hardware sensors embedded in Nexus switches.
The software agent, a small lightweight piece of code installed on your workloads (e.g. bare metal servers, virtual machines, EC2 instances), uses no more than 3% CPU to gather detailed information about every single network packet exchanged by that workload, alongside related application context and behaviour as seen through the operating system. This data is streamed to your Tetration cluster over an encrypted link.
The hardware sensor captures meta-data from every packet passing through your switches to provide additional points that gather even more rich data, all of which the Tetration cluster artfully deduplicates, processes, compresses, and stores for your later retrieval via sub-second queries.
Different agent types help us monitor any type of data centre, on premises or in the cloud.
The goal: to capture a detailed record of every conversation in your data centre. Tetration is pervasive and always on, which is critical to application mapping and forensic analysis, and includes both traffic in and out of the data centre, and traffic between internal workloads at multi-terabit scale.
Based on the detailed conversation records and application information that tracks processes, arguments, and users, Tetration utilises behaviour driven, machine learning algorithms that automatically create a map of the applications in your data centre, how they connect together, and who should be talking to whom – even inside an application tier. It is, in essence, your whitelist.
Conversation diagrams show which tiers are talking and how much.
Application views help you understand how tiers are connected and what policies have been discovered
You can read more about the Application Insight capabilities of Tetration in this whitepaper.
Enforce across your data centre
After discovering your whitelist, the next step is to enforce it across your data centre. While the whitelist is exportable from Tetration in open formats, ready for use in Cisco ACI or other network devices, one of my favourite features is the ability to push the whitelist into the firewall of every workload in your environment, Linux or Windows, on premises or in the cloud using our agent.
This hardens your data centre to the point where only necessary interactions are carried out. Nothing more.
Click the green button.
After automatically analysing your applications, you can overlay extra security policies that capture your intent, automatically translating that into the necessary firewall rules on workloads. Simple expressions like DENY communication from “All Hosts” to “WannaCry C&C Servers” can be captured and enforced across the entire data centre.
Or, for example ensuring that SMBv1 ports are blocked to all hosts that are not specifically designated as file servers.
The Tetration platform can be easily taught new information about workloads, which in turn can be used to enhance whitelist policy, in the form of annotations for both internal and external entities via our Open API. External tools can be used to generate feeds streamed into Tetration as annotations, for example the Cisco Talos industry-respected security feed.
Annotations allow you to associate up to 32 custom key-value pairs to every workload.
During the attack – detect, block, defend
Well implemented whitelisting should help block the majority of incidents where malicious code spreads from machine to machine like wildfire, as the network traffic will simply not be allowed. If using Tetration enforcement, non-compliant traffic will be automatically blocked by the workload before it has the chance to touch the network.
Whitelisting is not the end-all for the gamut of attack types, and during an incident, it is vital to move swiftly with accurate information. Tetration monitors every single packet as it traverses your data centre network. If that packet is not in compliance with your whitelist, it is recorded, and alerts are generated alarming you to take action. Alerts can be streamed out to an Apache Kafka broker, allowing you to integrate Tetration with your SIEM, ticketing systems, or wider security toolset.
Tetration policy analysis can help you instantly track down who is generating non-compliant traffic, correlate it to your intent, and with a simple stroke of policy, compromised endpoints can be instantly isolated.
This conversation was marked as “escaped” because it was in direct violation of the client side policy
For more information on Tetration Policy Analysis please read this white paper
After the attack – scope, contain, remediate
Post-incident, Tetration can quickly help you determine how far and wide the attack reached through the detailed record of each and every conversation. This entirely eliminates the need for guessing; the data is there, processed and ready for your analysis. Because of the always-on nature of Tetration, there is no rush to scramble to deploy network TAPs or SPANs to capture traffic.
Complex queries that straddle both network and application attributes can be expressed and returned in sub-second time. For example, searching for SMBv1 traffic over the WannaCry period shows a significant spike in traffic volume.
Detailed analysis can be performed using Tetration Apps. A full featured Python and Scala environment accessed via Jupyter notebooks executed with access to the entire data lake, combined with the processing power of the Tetration cluster, allows for crawling through terabytes of data in minutes, and with forensic-grade resolution.
In short, no single solution on its own would detect and prevent WannaCry, but Tetration, along with other security products would dramatically reduce the risk by limiting the attack surface, as well as by dynamically updating the data centre security policies based on attributes and events.