Earlier this year, DISA released the zero trust reference architecture for the DoD. Per President Biden’s Executive Order on Improving the Nation’s Cybersecurity released this year, “the Federal Government must advance toward Zero Trust Architecture.” With motivations within the Federal Government and DoD to adopt zero trust, several of our clients have asked how zero trust might impact their product portfolios and future certification efforts on the DoDIN Approved Product List (APL).
Zero trust is a drastic shift in strategic network defense where previous assumptions of inherent security based on traditional physical and network security measures, such as secured datacenter installations, and trusted internal networks behind firewalls, are no longer considered adequate or trusted. Devices and applications operating on internal networks, and the internal organization personnel who operate and maintain them have long been a soft targets for intrusion given their inherent trust and often widely granted privileged access. Zero trusts look to re-address the issues associated with flawed implied trust models leveraged broadly throughout the any IT enterprise, datacenter, or campus network. While many of the concepts supporting zero trust are not new to security practitioners – they are a definitive change to the standard IT management practices on traditionally “trusted” networks. Zero trust guiding principals serve as the foundation of an overall strategy to rethink how access to IT resources is managed:
- Never trust, always verify – All users, devices, applications, workloads and data flow should be treated untrusted. Assumed trust should never be granted – instead require authentication and explicit authorization for each of these categories as they operate. Least privilege, a concept that is not new to the U.S. Government, should be enforced through use of dynamic security policies that take into account not only identity and Role-based Access Control (RBAC), but also consider trend and expected behavioral analytics as part of rights management.
- Assume breach – Treat the environment as if it has been compromised already, and implement security practices that limit lateral attack vectors. Implement default deny policies on access control lists, both within the network and on end points. Perform logging and inspection of all activities within the architecture, to include user and device actions, data flow both across the network and within a system, and all use of resources or requests to access resources – and implement methods to continually monitor the activities for any suspicious or unexpected behaviors.
- Verify explicitly – Perform access management to all resources using secure methods that are consistent, and use multiple decision points to determine both the context and need for requested access.
Here are some practical examples where zero trust relates to traditional thinking.
| Traditional Thinking | Zero Trust Thinking | What Developers Can Do To Align Products |
| Sysadmins all have security clearance and have gone through a background check. They are trusted to have full, unfettered access to my network systems. | Sysadmins could present as an insider threat either inadvertently or with malicious intent, so even though they have been vetted for risk factors to national security, they should not be explicitly trusted to operate freely within the network. Instead, their access should always be tied to strong authentication, with explicit authorization for the least amount of access required to perform their duties. Each attempt to access resources should be validated uniquely and based on the context of the access request. Further, their access should be continually monitored and evaluated for unexpected behaviors that may indicate unauthorized activities. |
|
| Systems behind my firewall are on a trusted DoD network, so I don’t need to be concerned with my devices communicating between one another on the internal LAN. | Even internal networks are subject to compromise, and should not be considered explicitly trusted. Instead, communications across any network plane regardless of logical location within a security boundary should be protected with encryption and strong multi-factor authentication wherever technically feasible. Access controls should be enforced even for internal communication, providing a least privilege access model by enforcing specific endpoint, port and protocol based network access controls. Internal networks should not be left as a soft target for easy access to an insider threat, or breach of an internal device. |
|
| The application is installed on a STIG compliant server within my secure datacenter, on an internal network, and doesn’t have any active CVEs showing up in Nessus based ACAS scans. Its safe to assume the application is secure and not a threat. | Both physical and network security are subject to compromise. In addition, IP vulnerability scanners such as Nessus based ACAS are only able to inspect for known CVEs and vulnerabilities. There is a persistent risk of unknown vulnerabilities in applications that can be introduced both unintended by developers, or by malicious actors who have compromised the vendors supply chain. As such, it should be assumed that even with no active indicators of open vulnerabilities, software may have unknown vulnerabilities or compromises that have yet to be discovered by security researchers – but are known to adversaries. Applications should always be configured to operate with a least privilege model using a range of both discretionary and mandatory access controls to enforce access restrictions. Applications that interoperate with other components of the system architecture should always use encryption and strong multi-factor authentication wherever technically feasible – and their associated system and service accounts should also be tied to a least privilege model. The application should be continually monitored and evaluated for unexpected behaviors that may indicate unauthorized activities. |
|
| The service account sometimes needs privileged access to a resource, so that privileged access should be always enabled for the service account. | Identifying the specific workflows requiring resource access, and then tailoring dynamic security policies with multiple attributes that combine into a confidence driven policy for access management to resources on a case by case, conditional basis provides access only when explicitly required, and prevents arbitrary use of resources that may fall outside of intentional workflow. By using a confidence metric, it provides an additional method to detect and prevent abnormal attempts to access resources. |
|
Additional Reading:
- DoD Zero Trust Reference Architecture
- NSA Embracing a Zero Trust Security Model
- Executive Order on Improving the Nation’s Cybersecurity
Are you a product vendor or DoD agency confused on where to get started? Get in touch with us today, we can help!