Two of the most relevant, if trendy, topics in cybersecurity today relate to the starting point — the “ground zero” of attacks — from both the attacker’s and the defender’s perspective. The most useful weapons in the attacker’s arsenal are Zero Day attacks; that is, previously unknown or unseen attacks. Such attacks are especially pernicious because there is no bespoke, pre-existing defender countermeasure. There is no snort signature, no specifically predefined pattern of behavior to look for, no TCP port to lock down. In that sense, these are “foundational” attacks. However, the defender need not take a predominantly reactive approach.
Instead, we assert that — because Zero Trust defines a set of key security principles that can be applied independent of any particular attack — consistent application of a foundational “Zero Trust” approach to defending against attacks is a better strategy against Zero Day attacks.
First, a quick recap of the Zero Trust mindset is in order. At its core, Zero Trust is a set of foundational principles as described in earlier ONUG Security blogs in this series and Conference presentation sessions, but in summary, they are:
These principles transcend any specific threat surface or threat class, though they are operationalized using existing technology stacks, such as authentication and authorization infrastructure, telemetry and analysis tooling, and include remediative technologies such as sandboxing and microsegmentation. When we also add automation into the solution stack, these technologies can work collectively in order to respond in a highly adaptive manner to any detected threats, independent of whether those attacks use novel or pre-existing vulnerabilities.
Next, consider the properties of Zero Day attacks. While it is true that the specific exploits or vulnerabilities that are the target of Zero Day attacks will be novel, the core methods used by attackers remain constant. There are many frameworks that categorize these methods and classes of tactics; for this article, we will use one of the more popular ones – the MITRE ATT&CK framework1. MITRE defines 14 distinct steps that attackers employ, starting with reconnaissance and ending with the attack impact. However, for simplicity, we can categorize these steps into 3 broad buckets:
Now, if we consider these “phases” of an attack, and compare them against the safeguards that are put in place by a mature Zero Trust mindset, we find that the principles of Zero Trust exactly address the attack strategy foundations used by adversaries.
The attacker’s first step is to get some sort of foothold into the system. This foothold may be via a vulnerability in an application’s user-facing interfaces, or may take the form of a compromised update of an application component, perhaps using a supply chain attack such as the infamous log4j event2 of 2021. In either case, however, consistent application of the principle of least privilege is quite likely to prevent exploitation of a potential vulnerability, since the API or component will be unable to execute malicious activities that it is not authorized to do. For example, an attempt to hijack a logging utility like log4j to do remote execution would be stopped in its tracks if that workload did not have permissions to read from the internet.
The next barrier an attacker would encounter in an environment practicing Zero Trust would be the result of the continuous observation and assessment tenet. Specifically, even if the compromised user, API, or workload were to have been granted sufficient privileges to execute potentially malicious behavior, such behaviors would almost certainly be deviations from that entity’s normal behavior. Thus, if said user, API, or workload were continuously monitored and analyzed – using telemetry combined with AI-assisted behavioral analysis – the anomalous behavior would quickly be recognized. Of course, the Zero Trust concept of pervasive identity, applied to both users and workloads, is an implicit foundational requirement allowing the compromised entity to be monitored, tracked, and reported on. Going back to our logging example, if that logging workload entity is given an identity, and that entity is monitored and tracked, then, were its behavior to change (e.g., connections now opened to suspicious external sites, files modified outside of the logging directory, new processes spawned, whereas this was previously disallowed), such behavior would be easily detected.
It is also worth noting that, even for less sophisticated Zero Trust environments that do not monitor workload behavior, a subset of potential attacks can be detected via perimeter security, via external probes and egress monitors. Specifically, attacks that attempt to exfiltrate data can be detected by applying outgoing traffic anomaly detection solutions; similarly, attacks that attempt to make key services unavailable, can be detected via external SLA monitors1.
Finally, the Zero Trust principle of assume breach plays a key role in the mindset required against all attacks, including Zero Days. One important implication of embracing assume breach is that some attacks will succeed, and therefore forethought must be given to how to remediate any detected attack.
A common ploy employed by bad actors is to use “trojan malware” that masquerades as legitimate software but also contains an ancillary malware payload. An example is the “Bad Rabbit” ransomware that masquerades as an Adobe Flash update3. In this case, a clever adversary has managed to defeat defenses based on identity verification and least privilege by tricking a legitimate privileged user into installing malware, which now must be remediated. The remediation can take different forms, ranging from a very blunt response such as terminating the compromised workload if practical, to finer-grain actions such as sandboxing and/or reducing authorized actions when termination is not practical. One possibility is to allow a potentially compromised workload or user to continue to exist, but with reduced privileges, enabling the overall system to continue to operate nominally with only minimal disruption. So, while an entirely new malware workload such as BadRabbit might be terminated, other scenarios, such as the aforementioned anomalously behaving logging workload, might be remediated by disallowing that workload’s network access privileges to external systems, using either the authorization subsystem or network microsegmentation. Or the workload’s access to the local filesystem might be limited to only a specific set of directories. And certainly, the option to simply terminate the logging process could be applied in a less sophisticated Zero Trust environment, albeit with larger secondary consequences.
Readers who are already practicing Zero Trust may already be aware of and may have even implemented many of the ideas described here. Indeed, there may be additional strategies beyond those enumerated here that mature security practices have discovered and implemented. However, the key point to remember is that Zero Trust tenets were created as foundational, attack-agnostic principles to prevent, identify, and contain attacks generally – they were not created as a response to a single attack or class of attack. As such, consistent application of Zero Trust principles is the most effective defensive strategy against not just existing vulnerabilities, but especially against previously unknown Zero Day attacks.
1 Note that some attacks that do not attempt to exfiltrate data, such as ransomware, are difficult to detect purely at the perimeter, which is why we advocate applying Zero Trust principles to the application’s internal workloads, rather than only at the application’s perimeter.