Zero Trust is a concept that was started by Google a few years back with their own internal initiative called Beyond Corp. This was a response to a hacking incident that happened where internal systems were compromised inside of their VPN infrastructure. Beyond Corp enabled secure work from any location without the need for a VPN and instead relied on attribute-based authorization. Beyond Corp was the first iteration of Zero Trust to provide user and device-based authentication and authorization for the organization's internal infrastructure and corporate resources.
Companies are moving to a Zero Trust security model to secure intellectual property and avoid operational compromise. Zero Trust security alters the security posture by assuming critical computing assets and data are untrusted until they are authenticated, thereby only granting access to resources that are required at the time they are used. Companies can accomplish Zero Trust by implementing attribute-based security controls.
Guidance from NIST:
Zero trust is not a single architecture but a set of guiding principles on how to architect systems where there is no implicit Trust.
NIST Definition:
Zero Trust (ZT) is the term for an evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources.
Zero Trust Architecture ZTA approach is primarily focused on data and service protection but can and should be expanded to include all enterprise assets (devices, infrastructure components, applications, virtual and cloud components) and subjects (end users, applications, and other non-human entities that request information from resources).
Zero Trust
Zero Trust has been mainly thought of as a network construct to protect internal resources, applications, and data. As Zero Trust evolves, a more holistic approach is needed besides just a network focus. The guidance from NIST around Zero Trust Architecture is not just to focus on data and service protection but should also expand to include enterprise assets and endpoints. These enterprise assets should receive the same level of scrutiny as the network portion of Zero Trust. All endpoints in a Zero Trust Architecture should be attestable down to the hardware that it is free of compromise and in a pristine state.
There is no point to implement Zero Trust architectures and systems if you are authenticating to a compromised system or platform. Nation-state attacks have moved beyond application exploits and look to take hold of compromised systems for as long as possible while avoiding detection from most security tools and scanners. They do this by targeting their attacks to lower-level systems such as hypervisors, firmware, and hardware. By compromising these systems they make detection very hard by security professionals.
Side-Channel Attacks
Hypervisors can be compromised by side-channel attacks where a malicious attacker can be co-located on the same physical server as a vulnerable workload and the attacker will be able to exfiltrate data from the victim with almost no indicators of compromise (IOC). Spectre and Meltdown are two famous side-channel attacks that happened in 2018 timeframe, but March of 2021 researchers found new variants[1] of these attacks. The only defense against these attacks is to apply patches. The most secure way to defend against side-channel attacks is to not share hardware with other VMs, something that would make most traditional virtualization impossible to do as it’s a fundamental architectural design to share hardware between VMs.
Firmware Attacks
Malware such as Trickboot is a pervasive threat against organizations where compromised machines firmware is exploited and rootkits are installed to maintain access and evade discovery even by anit-virus software. The malicious code executes before the operating system so it can hide outside of system drives.
Hardware & Supply Chain Attacks
Nation-state-style attacks are moving lower than software and firmware to actually attack hardware and insert rogue devices and implants anywhere they can during the manufacture of hardware. Threat actors are always looking for a weakness in the supply chain to insert rogue devices. These types of attacks are incredibly hard to detect and stop once an attacker has gotten a foothold.
Zero Trust must go beyond just network access and make the assumption that all remote endpoints including operating systems, hypervisors, firmware, and hardware are untrusted until it can be verified or attested that the entire stack is free from compromise and in a known good state. As DOD organizations deploy Computing assets to remote locations and realize the promise of edge computing, Zero Trust will need to be extended to these in points outside of the corporate infrastructure and public clouds.
Edge Computing
Edge Computing assets will need to be protected against compromise as they may be located and locations with varying degrees of physical security, increasing the likelihood of a threat actor gaining unauthorized access. NIST has guidance on how to secure endpoints through device application stand boxing, Micro-segmentation, Continuous monitoring, Enclave-base deployments, and PKI but more can be done to verify endpoint security.
Security at the Edge
Security is always a concern and gets even harder at the edge where you can lose physical control over devices as well as connectivity. Edge devices process sensitive data where if that data was to be exfiltrated or sometimes even worse - modified, the results can be catastrophic. Edge security takes new methods and controls to effectively secure sensitive data and workloads. Things become even harder when layering in Federal security controls & frameworks. Data protection increases exponentially when dealing with how to protect multiple levels of data classifications at the edge where there is a loss of visibility and oversight.
Workloads should not be able to run if an endpoint is compromised or fails a cryptographic attestation. Users should not interact with a compromised endpoint or application or one that fails cryptographic attestation. Systems should utilize hardware-based techniques to create an environment that provides a high level of assurance of data integrity & data confidentiality.
Trust Starts at the Silicon
Trust starts at the silicon in computing. This is the only way to verify endpoints are trusted, in a known good state, and free of compromise. Systems need defense-in-depth from the silicon up to the application. Endpoints need to be verified before your workload runs or access is granted to a remote user. Attribute-based access controls are needed to perform cryptographic verification and authentication of critical resources at the time required to execute. This is where strong virtualization isolation technologies prevent data spills across security boundaries defined by the cryptographically verified attributes.
Silicon Based Approach to Zero Trust
New techniques to secure workloads from the hardware up to the workloads will be able to apply security policies about how workloads operate and the security they have all the way down to the CPU level married with Confidentiality from in-line memory encryption, default-deny, continuous authentication, policies that are data and workload-specific, not system-specific help to create an edge platform that ensures platform integrity from the silicon up to the top of the stack. Platform security and verification is vital to make a complete Zero Trust Architecture where endpoints can be attested and work with network controls for data access and authorization.
Cryptographic Attestation
Traditional BIOS and UEFI can present a large attack surface that lacks integrity and relies on public/3rd party keys controlled by multiple, global companies. They are vulnerable during system start-up and reset. Edge systems need the capability to securely load verified OS & software versions from authorized OEMs/ISVs that are cryptographically-bound to a customer’s private key. Edge systems need protection from boot to start-up through launch using virtualized UEFI Secure Boot capability by enabling per instance independent customer provided UEFI Secure Boot Keys.
- Boot Protections: Boot protections and a chain of trust from power-on through the launching of your most critical applications at runtime. Verifies and maintains system integrity at boot.
- UEFI Virtual Secure Boot: Independent UEFI BIOS secure boot virtual machine environments supporting industry standard keys or customer generated x.509 keys for a secure chain of trust extending beyond just platform boot but also inclusive of an instance’s virtual environment. Protects customers from third party global industry accepted keys imported from power-on, prohibiting the changing of the platform without customer approval.
- Intel® Boot Guard: hardware-based boot-integrity protection that prevents unauthorized software and malware takeover of boot blocks critical to a system’s function, thus providing an added level of platform security based on hardware
- Firmware Descriptor Verification (FD0V): a server-node management firmware technology that verifies CPU configuration and protects the platform from fusing attacks, helping to ensure a secure boot process
By implementing these low level hardware based protection edge systems can take the first steps for providing hardware based attestation and zero trust principles for systems at the edge. However there are many more protections and controls that can be added which I will cover in my next post. Stay tuned.
References:
https://security.googleblog.com/2021/03/a-spectre-proof-of-concept-for-spectre.html 1
