KEN ARORA at F5 explains why the healthy paranoia in many Hollywood films holds lessons for security professionals.
If ever—in some alternate reality or fantasy future—I have the opportunity to design Starfleet’s computer systems, one thing I would most certainly ensure is that the weapons systems were not connected to life support subroutines.
Or, were I to be the commander of an alien invasion force tasked to take over the earth, I would insist on biometric authentication, rather than a passcode or token.
And, if any of my officers or spacecraft were to escape their captors, I’d check to make sure they weren’t carrying any Trojan horses.
So, what does this have to do with zero trust? Hollywood loves storylines that play out the epic consequences that result from forgoing a few ounces of healthy up-front paranoia. And, as a cyber security practitioner, that same mindset is at the heart of what zero trust is about.
At the core of zero trust is the moral of Hollywood storylines: If you forgo a few ounces of thoughtful cyber-prevention in the design and operation of critical systems, you will be rewarded later with pounds of compromise and pain.
In the same way, at the central “why” level of any security framework, zero trust can be articulated as the following set of beliefs:
Always explicitly verify ‘who’: Always establish the identity of the actor attempting to interact with your system
Default to the least privilege required:Once identity is established, allow that actor only as much privilege as they need to interact with the system for the specific business transaction they are performing, with the requisite privileges enumerated by the design
Continuously monitor and (re)assess:The identity verification and privilege rights should not be a static, one-time thing; instead, those decisions must be continuously reassessed
And, still, assume you’ve been compromised: Finally, despite doing the above three items, presume that a sophisticated adversary has got past the defenses. Therefore, the system must also consider how to identify and isolate any compromised elements or identities, and a strategy for containment and/or remediation of their impact on the system.
Of course, ‘why’ is only part of the story. The ‘how’—that is, the techniques and tools used to embody the mindset that ‘why’ engenders—is another lens that’s relevant to the practitioner.
Phrased within the context of the current set of tools that today’s cyber security practitioners have available these techniques include:
Authentication: Any actor interacting with the protected system must attest to having some identity, or in some cases multiple identities—such as an identity for the human or automated system, an identity for the device or platform the human/system is on, and perhaps even an identity for the browser or tool used to facilitate the access. The zero trust mindset implies that any such attestation must be verified, or authenticated, by one or more means: a shared secret, a token or certificate, and, in more modern systems, by also observing and verifying the pattern of behavior of that actor.
Access control: Once identity is established, it should be assigned a level of trust, embodied by the access-control rights granted to it. The access-control policy should follow the principle of least privilege, where the only rights granted are the minimal set required for the actor to perform its role within the system. A best practice to note is that complex access-control scenarios targeting application resources should be abstracted behind APIs, rather than granting direct access to objects, files, and network resources.
Visibility: Moving on to the “monitor” part of the mindset—a prerequisite for continuous reassessment—the system must be capable of ongoing, real-time visibility into each actor’s system behaviors. In addition, not only must the collected telemetry be visible, but also it must exist within a framework that enables the sharing and contextualization of what is reported. This allows data from multiple sources to be meaningfully combined and correlated, enabling more robust, higher efficacy risk assessment.
Contextual analysis, ML-assisted: The motivation for visibility is to be able to execute on the continuously reassess principle. In implementation, this precept requires not only visibility, but also analysis—typically, across multiple data sources in near real time. To do so, the continuous assessment will often require assistance by AI machine-learning systems to detect actors that are acting anomalously, to identify any possible system compromise. And a robust analytics engine should be capable of providing a more nuanced answer than a simple binary yes/no—ideally, a risk assessment along with an associated confidence score.
Automated risk-aware remediation: The system must be able to act, and when needed contain and/or block actions or actors. The system’s response—ranging from mere logging to deeper inspection to blocking the attempted action, or even toward deceiving the suspected bad actor—must be considered in the higher-level business context. The likelihood and impact of false positives or negatives, and the business risk of the action are part of those considerations. Because of the sophistication and speed of modern cyberattacks, the operational remediation action must be automatable, with the human specified policy being described in terms of intent-driven goals.
The final aspect of the “why, how, what” framework is the “what”— the goals that can be achieved, and the attacks that can be prevented or mitigated, using these tools and techniques.
Specifically, the application of the principle of least privilege, embodied in the access-control policy, should limit file read/write permissions to those actors that require that privilege, preventing the encryption of file resources.
Further, should some actor attempt high-rate data encryption on many files, continuous reassessment and analysis should detect the anomalous behavior.
So, going back to Hollywood… If all of Starfleet’s computer subsystems operated on the principal of least privilege, the API that launches photon torpedoes should not be invokable by the gravity control subsystem.
And the alien mother ship’s controls would not only perform biometric-based MFA, but the mother ship’s security controls would assume that breaches will occur and be continuously monitoring and reassessing, detecting the anomaly of a fighter drone that flies through the ship, and mitigating the threat if it heads toward the engine core.
This would avoid a great deal of consequent drama. It would be bad for Hollywood, but good for cyber security practitioners.
- Arora is Distinguished Engineer, Security Products & Strategy, Office of the CTO at F5
