Building Cyber-Resilience

Building Cyber-Resilience

What a year we’ve seen! In addition to the continued ‘Mega Breaches’ we’ve seen increasing evidence that software complexity means there is no such thing as ‘Secure Code’. We’ve seen huge holes in common protocol implementations (with base protocol exploits  weaponized by nation states - for example, Eternal Blue - falling into the hands of third party Hacker groups) and major deficiencies in CPU instruction sets leaving major vectors for privilege elevation and data theft (Meltdown and Spectre), particularly in multi-tenant environments. The Mirai Botnet infected insecure IoT devices to attack the very workings of the internet through DNS. Diving into the ‘Mega Breaches’, many were caused by a combination of software vulnerabilities and imperfect process, such as incomplete patch cycles or mismanagement of data.

These significant events have an alarming diversity of root causes including everything from Layer 1 chipset and faulty protocol implementations, to critical services and Layer 8 (human laughing) deficiencies. The stack we rely on has proven to be complex, brittle, and subject to bugs at every layer. Unfortunately, a weakness at a single layer can have disastrous consequences in terms of data or service loss. 

There once was a meme for ‘secure software, not security software’ which could be found on the wall of many CISO’s office. That’s a noble principle and a cavalier theory but in our world of immense interdependency and complexity, there is no such thing as totally secure software. Perhaps the new meme should be, ‘we need better security architecture, not more security products’.

This brings us to the concept of Cyber-Resilience.  Cyber-resilience is not a new term but we think that acknowledging it from the perspective of reducing the impact of the next inevitable bug, rather than completely eliminating all vulnerabilities, is a more pragmatic and realistic approach. We like to think of cyber-resilience in the context of the old, “It takes a licking and keeps on ticking" Timex watch slogan or in a boxing metaphor, being able to take a punch and keep on fighting.

Cyber-resilience allows us to recognize vulnerabilities and attacks, quickly assess the risk, reduce the scope of potential impact, and employ risk-based mitigations as part of the normal course of business. So, from our experience over the past 12 months, what does ‘Cyber Resilience’ mean?

Environmental visibility

One of the most significant lessons of the Eternal Blue/WannaCry ransomware event was that the ability to quickly identify the behavioral signature for the secondary stage of malware propagation was critical in preventing proliferation. In a cloud environment, that doesn’t just mean at the perimeter, but that all the east-west interactions across the cloud are significant. For many security events, the ability to quickly visualize what actually changed can be the differentiator in outmaneuvering and circumventing a catastrophe. Regardless, truly understanding your applications and their normal behavior, relationships, and dependencies is of paramount importance in mitigating a security event without causing coincident, or collateral, damage.

Knowing Your Environment - The Critical Stuff

There’s a reason why having an accurate and reliable record of your critical assets and their dependencies is always a key factor in understanding environmental risk - without it it’s almost impossible to prioritize the response to significant technology events such as the current x86 Meltdown and Spectre vulnerabilities. The precision of asset information can mean the difference between patching your entire environment or simply prioritizing the databases containing your most critical and sensitive customer data. Inventory systems are often incorrect, outdated, or perhaps do not even exist, which makes having a system that produces telemetry for identifying, classifying and protecting critical assets truly invaluable.

Reducing the Attack Surface - Network Segmentation

So your entire environment is based upon modern compute architectures, and therefore exposes a pretty broad attack surface to the Meltdown/Spectre vulnerabilitys. A troubling aspect of this current event involves the exposure of credentials, passwords and keys which can allow unchecked attacker access across your multicloud. If you have segmented your environment, only allowing access required by your business and applications then those credentials are useless for gaining access to systems within a disconnected compartment. Network segmentation is one of the most fundamental of all security practices for providing cyber-resilience in a cloud environment. 

Reducing the Attack Surface - Best Practices and the Principles of Least Privilege

Less technically complex than implementing ‘hard’ network segmentation but no less critical to efficient security, is consistent enforcement of best practices. For example, if you can identify your databases and enforce best practices preventing OUTBOUND data movement, you have significantly restricted an attacker’s options for data theft. Additionally, restricting and minimizing the access of users and processes can restrict attacker access. Implementing best practice policies and reducing access is not trivial. In fact, it can be incredibly complex and time-consuming so selecting products such as policy computation engines and user behavioral analytics systems that automate this work is a key component of cyber-resilience. 

Reducing the Attack Surface - Stack Simplification

One recurring theme over the past year has been how complexity and diversity of dependencies have exposed a huge attack surface. Microservices architectures are designed to simplify application stacks, provide isolation and resilience, and decrease fragility. Most notably, microservices architectures simplify each component down to a single function which greatly decreases attack surfaces. For example, you won’t find an overabundance of protocols (such as SMB which is the vector for Eternal Blue propagation) running in a microservice environment unless they are necessary to provide a service. Designing microservices architectures is a strategic effort (and won’t change the world overnight for many organizations) but when designed correctly, will have a dramatic impact on overall cyber resilience by building tangible security into the new stack and its associated operational processes.


People aren’t officially part of the 7 Layer OSI technology stack but human error continues to be an elemental component of almost every critical vulnerability and security incident, whether through the introduction of software bugs in SDLC or through unsecure practices (naïve or malicious) such as clicking on a phishing link or handling data improperly. Regular and focused discussions of security events and periodic team-based threat modeling exercises help encourage the right mindset and security culture. If you want to develop software securely then an Appsec program is vital.


In light of the sidechannel chipset vulnerabilities, this is an interesting area. Most encryption solutions are focused on encrypting data on disk (at rest) or during transit (in flight). However, the vulnerabilities associated with Meltdown and Spectre don’t prevent an attacker from reading unencrypted data from the kernel page table (or that associated with another Guest VM in virtualized environments). Memory has long been considered insecure between process, ring, and even virtual boundaries for many advanced attackers. Meltdown and Spectre now provide a mainstream example available to all. 

Innovative security companies such as Enveil are focused on encryption of data across its entire processing lifecycle which ensures it is encrypted in memory.  If, however, you adopt a position that memory is insecure and accessible within your threat model, then you have to consider that your keys and certificates can be accessed, which means you can probably defeat cyber defenses based solely upon cryptography. At this point you might argue that we’re pushing the mental threat model to the extreme and we might agree. However, it also illustrates how over-reliance on a single ‘silver bullet’ control is the antithesis of cyber-resilience. Cyber resilience cannot be achieved through a single measure.

So, how might you mitigate the theft of keys from insecure memory? Funnily enough, we end up back at……….  


Looking holistically at Cyber resilience, segmentation and reduction of access become critical for mitigating the vulnerabilities we will undoubtedly continue to see in software and upon compute platforms. Microsegmentation, if its provided independent of the workloads, provides a barrier against attempted exploits.

Taking the Meltdown/Spectre example, if you can’t access the decryption key on a reader of data (because they have been segmented) then it becomes very hard to decrypt that data yourself.

So where does this leave us?

As we continue to be presented with evidence that completely ‘secure software’ does not exist and that bugs and vulnerabilities are inevitable then the concept of Cyber resilience, of thinking holistically and putting proactive compensating measures in place, will become increasingly important. The question we need to ask ourselves is not ‘how can we mitigate that last event?’ but 'how can we be more resilient in future?' At vArmour, our customers have shown us that tools to help them understand their applications and implement proactive techniques such as application modeling and segmentation are a critical component of that resilience.