© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 1 of 21
White Paper
The Goldilocks Zone: Cloud Workload Protection
By Navindra Yadav, Cisco Fellow and Founder of Tetration
© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 2 of 21
Contents
Characteristics of the Goldilocks zone .................................................................................................................. 5
Essential building blocks of the cloud workload solution ................................................................................... 6
Tetration Analytics platform and vulnerability detection ..................................................................................... 9
Cisco Tetration platform and process, file system, and user visibility ............................................................. 12
Cisco Tetration platform and process hash analytics: cloud workload protection ......................................... 13
Cisco Tetration platform and application behavior whitelisting ........................................................................ 14
Use case: Cisco Tetration platform and Meltdown and Spectre detection ....................................................... 18
Final thoughts ........................................................................................................................................................ 20
© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 3 of 21
I’m sure many of you have heard terms such as segmentation, microsegmentation,
nanosegmentation, picosegmentation, and so on and all the marketing buzz about
how important they are. In my opinion, you shouldn’t buy a product just to check a box
off your list; you want to satisfy a business goal. Say, for the sake of this discussion,
the end goal is to materially improve your workload’s security posture from attacks.
Want to learn how?
First, step back and look at what the experts practicing cybersecurity defense say what you should do. These
people are cyberanalysts from nation-state actors and know a thing or two about security. More on the experts
later.
Before hearing what the experts say, a few small observations:
● Observation 1: A key thing to keep in mind is the fact that most successful attacks come from exploiting
vulnerabilities in the application and software stack and not from an attack in the network layer (TCP/IP).
Another way to put this is, even if an enterprise has generated and implemented a perfect whitelist network
microsegmentation policy, it is still vulnerable to many attacks.
Most attacks either are rooted in the attacker having the credentials and walking in through the front door or
are rooted in an application vulnerability (for example, SQL injection or acquiring a web shell on a front-end
server) or a combination of both. If the application is vulnerable, the attack or attacker might exploit the
vulnerability and then simply pivot through the allowed microsegmentation rules between the application
components (no amount of encryption or authentication will help). After all, the process running the
application might be compromised, and the microsegmentation rule doesn’t know that. The process might
be compromised because of any number of vulnerabilities such as (reflective) Dynamic-Link Library (DLL)
injection attack, shell code exploit, and so on.
Is network segmentation a useless idea? Absolutely not. Network segmentation is an essential tool, but you
need to understand its strengths and limitations and use it effectively. Segmentation is a
compartmentalization approach. If a breach happens, it tries to contain the attack and make the life of the
attacker a bit more difficult. However, if there are connections (doors) between the compartments, that’s
what the attack/attacker can then exploit.
● Observation 2: Enforcing the network segmentation policy is a simpler part of the microsegmentation story.
Generating an always up-to-date, correct network microsegmentation policy in a highly agile, cloud-scale
environment is a massive challenge.
Now add additional operational requirements such as merging an existing business security policy with the
auto generated application policy, providing right access through role-based access control, merging tribal
knowledge from different application groups, maintaining versioning and rollbacks, tracking usage analytics
around policies, identifying per-packet policy compliance deviations, threat modeling (because you don’t
want your microsegmentation to be used as a building block for ransomware because the vendor did a poor
threat analysis and protection of a solution), and so on.
Hopefully you’ll see that enforcement is essential, but is really just a small part of a broader workload
protection strategy.
© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 4 of 21
● Observation 3: Are there differences between the campus computers and data center (running public or
private) workloads? The answer is absolutely. Keeping this fact in mind when designing your security
strategy is crucial.
Data centers are a relatively easier challenge to address by using whitelisting. On my laptop, the software I
run differs from what other people in similar roles use, and the code that I run varies over time. Sometimes I
code using vi or an Integrated Development Environment (IDE); other times I do email, message using a
messaging app, browse the web using different browsers, have different browsing personas, run isolated
virtual machines to try out an exploit technique or a penetration test idea, and so on.
So, the applications I run vary over time on the same machine or are different from those of my coworkers
who might be running a different music app or use a different IDE to code. This situation evolved because
users like me and you using campus end devices are human, and we like our freedom to install software
packages we like and devices with which we are comfortable. This is why the bring-your-own-device
movement picked up.
Now contrast this to workloads running in the data center. Most workloads are homogeneous for a given
function. Think web front-end servers for one given application: they follow the same set of software.
Without a model that can be automated, you can’t build a large data center because the human operation
cost to run the data center will be immense.
It’s easier to whitelist applications and their communication patterns on data center workloads. For campus
machines, often the easier approach is to use a blacklist of what not to do or run, with highly coarse rather
than fine-grained whitelist policies. Our observation is that the data center is a much more tractable problem
for whitelisting and automation in general (with homogeneity and automation systems into which to plug).
● Observation 4: Whatever solution we consider must work for today’s technology trends and those on the
horizon. For example, mainframes (if you have them), bare metals, virtual machines, and containers all
must be natively supported; public and private data centers must be supported. The solution must integrate
with external orchestrators, load balancers, and external enforcement points (there is value in defense in
depth) and pull metadata/context from the Configuration Management Database (CMDB) systems. This
integration is absolutely essential because the application knowledge and context are distributed among all
of these systems.
Back to the nation-state cyberdefense experts. The Australian Signals Directorate (ASD) came out with a great set
of white papers (https://www.asd.gov.au/infosec/mitigationstrategies.htm) in which the ASD looked at the attacks it
saw and how to mitigate or prevent them. I’m a big fan of this analysis. It’s pretty comprehensive and, most
importantly, is data driven. The cyberanalyst team started from the attacks it saw across a wide set of workloads
and mapped those attacks back to what would have prevented them. The study is vendor neutral, with no one
selling any gear. I have seen similar recommendations from the NSA’s TAO group
(https://www.wired.com/2016/01/nsa-hacker-chief-explains-how-to-keep-him-out-of-your-system/).
© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 5 of 21
The primary takeaways from the ASD analysis are:
● The threat is real, but there are things every organization can do to significantly reduce the risk of a
cyberintrusion.
● In 2009, based on our analysis of these intrusions, the ASD produced strategies to mitigate targeted
cyberintrusions. At least 85 percent of the intrusions to which ASD responded in 2011 involved adversaries
using unsophisticated techniques that would have been mitigated by implementing the top four mitigation
strategies as a package.
● The top four mitigations are application whitelisting, patching applications and operating systems, using the
latest versions, and minimizing administrative privileges.
Why doesn’t everyone just follow the four steps, if it is that simple?
Whitelisting applications—their allowed system calls and interactions—and application communication patterns is a
nontrivial problem (see the observations earlier, especially 2 and 4). In this paper, we will study the problem and
then look at the solutions. There is hope.
What’s the deal with the Goldilocks zone?
Life evolved on planet Earth because there were multiple factors that had to come together. NASA
(https://science.nasa.gov/science-news/science-at-nasa/2003/02oct_goldilocks) coined the term Goldilocks zone,
which must be present to support life.
In computer security for workload protection, multiple things have to come together to produce an effective security
solution for cloud workloads.
Characteristics of the Goldilocks zone
A good cloud workload protection solution must have all of the following characteristics.
Characteristic 1: independence of how the workload is instantiated
The solution must be able to span containers at one end of the spectrum and to mainframes at the other. There
must be a common policy enforcement and workload protection framework. Example: A Programmable Data
Processor (PDP) mainframe and a container have processes. The same concepts apply to both. The solution must
cover mainframes, bare metal workloads, virtual machines, containers, and so on. And it must work across a
plethora of operating systems.
This makes the life of you as an end user really simple. You should only have to worry about how to apply a policy
to isolate workloads with a highly exploitable vulnerable software package from high-risk workloads. You shouldn’t
have to worry about where that workload resides (in the cloud or an on-premises data center), what operating
system it’s running, whether it is a container or a virtual machine, and so on. The solution should be extensible to
handle function as a service: something that’s on the horizon, but not in the mainstream yet.
Characteristic 2: workload location independence from public or private clouds to data centers
The solution must be able to handle workloads running both in on-premises data centers and in any public cloud.
Like characteristic 1, this characteristic enables the customer to simply push policies and actions without having to
worry about where the workload resides.
© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 6 of 21
Characteristic 3: federation and scale
Every system has scale limits. A highly desirable solution, which could even be argued to be a mandatory
requirement at scale, is to federate with other systems. Federation enables the customer to have multiple workload
protection zones for availability and robustness reasons and still want the zones to share information with each
other.
Characteristic 4: encourage and integrate with an ecosystem
The solution must be able to talk to other external systems, including:
● Security Event and Incident Management (SEIM) or high-level log correlation systems in the northbound
interface
● Enforcement products from other vendors on the southbound interface
● Ability to talk horizontally to the campus network security controllers to enrich its own knowledge and share
its insights with them
● Ability to talk to compute orchestration systems such as AWS, Azure, GCP, VMware vSphere, Kubernetes
API server, and so on
● Ability to talk to CMDB systems to get inventory metadata
● Ability to talk to application delivery controllers
● Ability to talk in threat feeds and nonthreat feeds (for example, geo data)
Characteristic 5: encourage multiple points of enforcement
Security is always best with layers of defense. Having just one enforcement point is risky. The more points of
enforcement, the harder the target is to attack.
Characteristic 6: visibility across multiple planes and domain boundaries
The solution must have visibility and an enforcement reach across multiple planes. The solution must be able to
watch the network plane, storage plane, compute plane, and user plane. It must be able to view things inside the
workload (virtual machine/container/bare metal) and also be able to see outside the workload to correlate things
across these boundaries and make sense.
Here’s an example of how watching multiple domains helps when there is a kernel rootkit and the only presence of
visibility is inside the virtual machine. Chances are if the rootkit is well written, it will hide its signatures such as the
Command and Control (C&C) channel from the agent watching the workload. However, if the infrastructure sees
the flows and attributes them to the workload, the differential analysis clearly triggers suspicion.
Now let’s look at the building blocks of a robust cloud workload protection solution.
Essential building blocks of the cloud workload solution
Building block 1: visibility
You want a solution that magically captures high-granularity interaction data between the workloads and inside the
workload. This data store forms the foundational basis of all the layers above it. As they say, “If you can’t measure
it, you can’t improve it.” Another version applicable to security is “If you can’t see it, you can’t secure it.”
© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 7 of 21
What should a system ideally collect?
● Packet-by-packet network activity
● Process metadata (command line, process hash, libraries loaded, dynamic or static, forks, exits, process
I/O, File Descriptors (FD), and so on)
● Storage or file system activity: files accessed, hash of the content of the file, and so on
● User activity: who logged in, how the login was done (remote, local, tty, console, and so on), time of login,
time of logout, and so on
In addition to collection, the system should be able to aggregate and uplevel the data.
Why is this so important?
To generate high-quality policies in a brownfield environment, you need to access high-resolution data. Also, this
data helps in testing policy changes on past data before pushing it into enforcement and can be used to search for
Indicators Of Compromise (IOC) in the environment on past data. This data also helps with forensic analysis of an
incident.
Building block 2: vulnerability detection
All installed software that runs in the user space or in the kernel on the workload must be scanned for
vulnerabilities. Vulnerability analysis can be done using static analysis of the coder or by comparing the code
against a known set of vulnerabilities. Vulnerability analysis also helps to identify unused network services and
packages and help the user to uninstall them.
One approach is to use an outside in vulnerability scanner: one that checks the workloads using an external
scanning tool. The other approach, also known as the inside out approach, uses an agent running on the workload
that does an internal analysis of the workload. Of the two approaches, inside out is more reliable and produces
superior results compared to an external scanner limited to discovering the packages based on the network
fingerprint. Cloud operators often provide image analysis service before the workload is launched, assuming
nothing is installed at runtime.
Building block 3: full policy lifecycle of workload segmentation
Workload segmentation is a very important building block of the protection solution. It provides protection by
isolating the workload from the part of the universe in which it doesn’t have to communicate. Another contribution
of workload segmentation is containing any system breach to as small a blast radius as possible. Workload
segmentation often makes use of firewalling in the workload (for example, iptables/ipsets, Windows advance
firewall, or Windows filtering platform). Policies inserted inside the workload move with the workload if it is migrated
elsewhere.
The primary stumbling block of workload segmentation is definition and discovery of the whitelist policy at scale.
Doing this is an impossible task without an analytics engine. The other challenge with workload segmentation is to
build a policy that supports elastic workloads, testability of the policy without enforcing it, providing real-time
compliance reports, version tracking, and policy rollback.
Segmentation policy sometimes covers traffic encryption or authentication protection between workloads, thereby
protecting the communication between the workloads on a shared segment.
© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 8 of 21
Building block 4: application behavior whitelisting
Application behavior whitelisting observes the behavior of the application running on the workload and optionally
builds a behavior baseline model for the process. This function observes network communication, system call
activity of each process, and the relationship between processes and examines CPU counters and files opened by
the process, the user associated with the process, memory analysis, memory cache spills, and more of every
application.
To do application behavior whitelisting, the agent must have presence inside the workload or must be able to look
into the workload’s name space.
Well-known bad behavior is often preloaded with the agent or the solution, and in case that behavior is picked up,
mitigation action is taken. Also, if the application deviates from its known behavior model with some added
tolerance, mitigation action is taken.
Enabling application behavior whitelisting with very few false positives or false negatives is a notoriously hard
problem to implement in production systems at scale.
Process hash analysis across a fleet of workloads looking for known bad hashes is often considered by some as
application behavior whitelisting; for this to be effective, the process hash must check on physical storage and the
process hash running in memory.
Mitigation action on detection of bad behavior often involves using built-in operating system application control
capabilities such as software restriction policies and AppLocker in Windows or SELinux (CentOS/Red Hat/Oracle
Linux) or AppArmor with Ubuntu Linux.
Building block 5: application whitelisting
Application whitelisting involves allowing only a known set of processes to be started; everything else is banned.
The use of whitelisting to control what executables are running on a server provides a powerful security protection
strategy. All malware that manifests itself as a file to be executed is blocked by default. The philosophy here is that
if there is an SQL server, it’s much easier to lock down the SQL server application than to tell the server thousands
of things it shouldn't be doing.
The difference between building blocks 4 and 5 is that 4 makes a behavioral model, and 5 allows a known set of
executables and libraries to be loaded. The whitelist-only model does not block bad behavior from a whitelisted
application because it doesn’t have the visibility into the behavior of the workload.
Building block 6: file integrity and memory monitoring
File integrity monitoring tracks the sanctity of the file system, bootloaders, startup folders, registry on Windows,
drivers, and so on. The bootup process then becomes a secure boot. Part of the solution must include memory
scans for memory-resident malware or malware probing the cache lines or setting the read, write, and execute
settings of the page tables. The latter is a specific form of memory monitoring, in which the control system of the
memory is watched rather than the contents of the memory.
© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 9 of 21
Building block 7: deception and decoys
Deception and decoys try to turn the tables on the attacker. Security protection capability creates fake
vulnerabilities, systems, shares, cookies, and so on, often called honey tokens. If an attacker tries to exploit these
fake resources, it’s a strong indicator that an attack is in progress. A legitimate user should not see or try to access
these resources.
Another technique is to tunnel traffic sent by the attacker to unbound network ports on the machine under attack to
another decoy machine with the same operating system. This binds on all ports. The promiscuous decoy machine
allows the attacker to play and explore itself, while continuously logging the attacker’s actions. The monitoring
system watching the decoy learns from the decoy system logs. The key in this model is to deceive the attacker
from noticing that it is not attacking a real system but rather attacking a decoy system. A sophisticated decoy, when
clubbed with an artificial intelligence, results in the attacker educating the defending AI system of the attack trade
craft and techniques. The defense system can now use those techniques to look for patterns in the real workload
fleet.
Now that we’ve gone over the characteristics and essential building blocks of a solution, let’s see which
components the Cisco® Tetration Analytics
™ platform already addresses and how it’s done.
Tetration Analytics platform and vulnerability detection
To track vulnerabilities in the operating system or in the user space software in the workload, the Cisco Tetration
Analytics™
platform first establishes a baseline inventory in the data center, whether public or private. The Tetration
Analytics platform tags every piece of workload inventory with an arbitrary set of user-defined tags or tags it
discovers from the orchestration systems (for example, AWS, VMware, Kubernetes). And it scales to multimillions
of workloads it tracks. Information is kept up to date in real time. Any changes in the environment (orchestrators) or
on the workload are picked up. This information is then curated or indexed and readily available for fast search and
further processing, say, for segmentation policy enforcement.
In addition to the context of the workload, the Cisco Tetration platform gathers the full software inventory (installed
software packages) from all monitored workloads in the data center, whether public or private. Just like the context
of the workload, the Cisco Tetration curates the software package inventory per workload. Any changes made to
the software inventory triggers the platform to reevaluate policy and check for vulnerabilities.
Cisco Tetration platform also bundles the vulnerabilities reported over the last 19 years. It uses Common
Vulnerabilities and Exposures (CVE) like ones available from NIST (https://nvd.nist.gov/) or MITRE. If enabled by
the customer, platform will also be keep the CVE databases on the cluster up to date with periodic updates. Cisco
Tetration platform also cross-checks every software package against the full CVE database looking for vulnerable
packages, taking into account the version of the software package, the impact scores, and so on.
© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 10 of 21
Figure 1 shows a query across workloads that belong to a specific tenant on the set of machines with a vulnerable
version of wget installed.
Figure 1. Inventory search to quickly identify all servers running the wget application and has a known CVE
Figure 2 shows that the Cisco Tetration platform enables the user to glean information about what each software
vulnerability is and give it a vulnerability score or ranking. It also deep links the CVE to NIST’s site for more details,
as shown in Figure 3.
Figure 2. Software package inventory on a server and details on the known CVEs
© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 11 of 21
Figure 3. Vulnerability details from NIST website
The Cisco Tetration platform also enables the users or machines to drive policy updates (over the Tetration
Analytics open RestAPI interface) based on the presence of a package, vulnerability or vulnerability scores, and so
on.
It tracks both versions of vulnerability scores. Users can also acknowledge and disregard vulnerabilities, assuming
they are deemed to be unexploitable by the user because of some other mitigating factor (for example, an air-
gapped system might be considered to be a sufficient barrier).
This system enables Cisco Tetration customers to:
● Search for any package in real time across their infrastructure without affecting the CPU load on their
workloads.
● Deploy sophisticated policies across their workloads, which can track a vulnerability and automatically
trigger a time-delayed policy, isolating the workload for remediation.
● Enable info security to mandate policies such as isolating all web-facing workloads with a CVE vulnerability
score greater than 9.0 after giving the workload owner a five-day fix notice.
A picture says a thousand words. Figure 4 shows a system with a vulnerable version of zookeeper installed.
© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 12 of 21
Figure 4. Information about software packages and vulnerability details
Cisco Tetration is a flexible metadata system and therefore can enforce policies based on inventory metadata. It
reevaluates the policy associated with each inventory if the metadata changes. (See Figure 5.)
Figure 5. Policy definition using metadata
Figure 6 shows the sample enforced policy.
Figure 6. Policy enforcement using metadata
Cisco Tetration platform and process, file system, and user visibility
Cisco Tetration software agents track all activity on the workload, including the process, server user, interactions
with changing the memory or page table permissions and cache behavior, and many other system calls on the
workload. It also tracks actions done on the file system. All of this information is gathered with minimal load
(under 3 percent of CPU for all its monitoring functions) on workloads. Cisco Tetration software agent enforces a
strict SLA on itself. Cisco Tetration platform curates all workload activity in a time-series database and associates
the activity stream to the workload in its data lake.
The user can ask Cisco Tetration platform to show the entire process lineage on any workload in the fleet of
machines since the workload was started. In fact, it tracks the full process lineage tree. The user can step forward
or backward and play the sequence. The roots in Figure 7 show the lineage for the kernel threads and for the user
space processes.
© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 13 of 21
Figure 7. Process lineage on a server host
Cisco Tetration platform and process hash analytics: cloud workload protection
Cisco Tetration platform tracks process hashes for those that are running. It calculates an SHA256 hash of each
process it observes. The process hashes are stored in its corpus. It then cross-checks the hashes’ with open-
source hash databases such as the VirusTotal.
Process hash analytics are used by many security practitioners to identify good software from bad by cross-
checking the hash against databases. By automating that process, Cisco Tetration platform makes it simple for the
user to apply this across the data center for scale.
In Figure 8, you can see the process hashes on the workload. Anvil’s process hash is cross-checked by following
the process hash link leading to VirusTotals. The screen shot from virus totals in Figure 9 shows the verdict from
the other partners in VirusTotals regarding the anvil process hash.
Figure 8. Process hash information from servers
© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 14 of 21
Figure 9. Verdict provided for the process hash by VirusTotal
In the future, the Tetration Analytics platform will programmatically integrate with VirusTotals: pull data and push
data to it. It will exchange its verdict on the process hash and programmatically consume verdicts from other
security companies. This information could then be used in Tetration Analytics enforcement policies. In addition, it
will cross-check the process hashes it sees against the National Software Reference Library RDS datasets of
known binaries and applications.
Cisco Tetration platform and application behavior whitelisting
Cisco Tetration platform studies the behavior of the various processes and applications in the workload, measuring
them against known bad behavior sequences. It also factors in the process hashes it collects. By studying various
sets of malwares, the Tetration Analytics engineering team deconstructed it back into its basic building blocks.
Therefore, the platform understands clear and crisp definitions of these building blocks and watches for them.
The various suspicious patterns for which the Cisco Tetration platform looks in the current release are:
● Shell code execution: Looks for the patterns used by shell code.
● Privilege escalation: Watches for privilege changes from a lower privilege to a higher privilege in the
process lineage tree.
● Side channel attacks: Cisco Tetration platform watches for cache-timing attacks and page table fault
bursts. Using these, it can detect Meltdown, Spectre, and other cache-timing attacks.
● Raw socket creation: Creation of a raw socket by a nonstandard process (for example, ping).
© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 15 of 21
● User login suspicious behavior: Cisco Tetration platform watches user login failures and user login
methods.
● Interesting file access: Cisco Tetration platform can be armed to look at sensitive files.
● File access from a different user: Cisco Tetration platform learns the normal behavior of which file is
accessed by which user.
● Unseen command: Cisco Tetration platform learns the behavior and set of commands as well as the
lineage of each command over time. Any new command or command with a different lineage triggers the
interest of the Tetration Analytics platform. (See Figure 10.)
Figure 10. Process related events that can the tracked and setup alerts
In the following examples, Cisco Tetration platform did not have any malware signatures. It simply looked for the
building blocks of bad behavior, cross-checked them with the process history and baseline, and alerted only if it
was confident that the incident was worth noting and alerting: application behavior whitelisting. Cisco Tetration
platform has longer retention for events as compared to the full process tree.
Let’s take an example and see Cisco Tetration platform detecting a shell code execution. Figure 11 shows how
Cisco Tetration platform detects shell code execution, triggers an alert, and tracks all the actions done by the
malicious process.
© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 16 of 21
Figure 11. Detecting shell-code execution and providing forensics
The user can then drill down into the malicious process and study it further. Cisco Tetration platform tracks all 25
descendent jobs forked by the malicious bash shell script. (See Figure 12.)
Figure 12. View of all the process forked by malicious shell script
© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 17 of 21
Figure 13 shows a large process tree where stage one of the malware, which is the shell code, is loading or
installing the second stage of the malware. In the process, 176 child processes are created and executed by the
malware.
Figure 13. Tree view of all processes spawned by a malware
Custom rule engine
Cisco Tetration platform also enables users to define their own set of rules based on the building blocks it built to
find custom malware. Users can define the desired action and severity level they want, as shown in Figure 14 and
Figure 15.
© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 18 of 21
Figure 14. Forensics alert definition window
Figure 15. Forensics alert definition window
Use case: Cisco Tetration platform and Meltdown and Spectre detection
When Meltdown and Spectre (https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-
side.html) were announced, our team tried the exploits in the lab and checked what the Tetration Analytics platform
did with them. It detected anomalies in kernel page table fault behavior and also observed cache timing attacks
without any extensions. We have since added the strings “Meltdown” and “Spectre” to the reports; other than that,
the engine built by the engineering team stood the test.
Cisco Tetration platform detected both the attacks Proof-Of-Concept (POC) exploits and the vulnerabilities. This
was possible because it has a side channel attack detection and page table operations engine. This picks up
bursts in kernel page table faults (used to detect Meltdown) and cache timing attack patterns (used to detect
Spectre and other side channel attacks).
With Spectre attacks, the attacker needs to access the cache side channel to obtain the data. This behavior is the
same as for the Meltdown attack. There are a variety of cache side channel attacks, including flush plus reload,
prime plus probe, and other variants. A primary behavior of these attacks is the large amount of last level cache
misses generated during the attack.
© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 19 of 21
With Meltdown, if an attacker accesses the memory location, which is inaccessible to the attacker, a page fault will
be triggered. In the case of a user attacking kernel memory space, a kernel page fault will be triggered. To dump
the kernel contents, the attacker needs to trigger a large amount of kernel page faults to reduce the noise in the
cache side channel. This is what Meltdown does. The attacker can get stealthier and trigger only a small number of
kernel page faults periodically, but then the attacker’s cache becomes polluted because the attacker has no control
over the execution of other processes. In the real world, the kernel rarely has page faults because the kernel loads
its pages. Therefore, a small number of faults in a short period (for example, one second) becomes an interesting
signal for the platform.
Figures 16 through 19 are some interesting snapshots of Meltdown and Spectre detection in action.
Figure 16. View of a Meltdown event
Figure 17. Meltdown event details
© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 20 of 21
Figure 18. View of a Spectre event
Figure 19. Spectre event details
Final thoughts
Now you have an in-depth knowledge of the new cloud workload protection capabilities added to the Cisco
Tetration Analytics platform. The must have cloud workload protection characteristics limit viable solutions to a
Goldilocks zone. The Goldilocks zone covers the edge of infrastructure and goes deep into the workload.
You learned about software vulnerability detection, application behavior whitelisting, and how Cisco Tetration
platform ties in these capabilities using enforcement, enabling the building blocks of a robust workload protection
solution. You can learn more about currently available features of the Tetration Analytics platform, including high-
resolution network visibility and operationalizing microsegmentation enforcement for cloud workload protection at
scale, by visiting the Cisco Tetration Analytics website: https://www.cisco.com/go/tetration.
© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 21 of 21
Printed in USA C11-740380-00 04/18