by Robert Buccigrossi

The Cybersecurity and Infrastructure Security Agency and National Security Agency released an advisory that warned of a “widespread cyber campaign involving the malicious use of legitimate remote monitoring and management (RMM) software.” Targeting RMM software (through cracking passwords) is one of many ways that systems on local secure networks can be infiltrated. Other ways include:

• Someone within a secure network opens a malicious attachment (e.g. DNC Hack)
• An outward-facing service has an unpatched exploit (e.g. flaws in 30 WordPress plugins)
• An internal system has a malicious patch applied (e.g. the Solar Winds Attack)

The fact is, even with firewalls and security scanning software, systems within private networks are vulnerable to attack. The Philosophy of Zero Trust is intended to prevent these types of attacks. The term “Zero Trust” does not mean “batten down the hatches, we can’t trust anyone outside the network.” In fact, it means the opposite: “We can’t trust any request coming from within our network.”

“Zero Trust” (originally coined by Forrester Research in 2010) is the philosophy that systems should not provide any special authority or trust to systems within local networks. A simple example is the relationship between web servers and databases. When setting up a web application, it is tempting to configure a database to automatically authorize sessions from a specific IP address (assumed to be the web server). But then, if the web server is infiltrated, the hacker could then “piggy back” from the web server and obtain whatever data the database permits.

If you assume that you can’t trust local network systems, then services must authenticate and authorize requests for each request session based upon user-based or service-based credentials, not based upon network topology. This logically leads to some key rules:

• Services must authenticate and authorize service users (requests can originate from bad actors)
• In turn, service users must be able to authenticate services (man-in-the-middle attacks could present fake services to service users)
• Services must encrypt data in transit and at rest (hacked systems on a network can snoop on shared network and file system resources)

NIST’s Recommendations on Zero Trust Architecture - In NIST SP 800–207, NIST defines its recommended architecture to attain the goal of Zero Trust. The architecture has 3 main logical components. These components do not have to be independent (in other words, you could have a single service that implements all of these components), but the components’ roles need to be present:

• Policy enforcement point (PEP): This logical component allows, monitors, and ends connections between a user and a service. A key punchline is that there isn’t a “back door” – all requests need to go through the PEP.

• Policy engine (PE): This logical component makes the decision to grant access to a service by a user.

• Policy administrator (PA): This component generates session-specific authentication and authorization tokens or credentials used by a service.

In addition, there are optional data sources that inform the policy components:

• Continuous diagnostics and mitigation (CDM): This data source gathers information about the session user (such as if the request is coming from an appropriately patched operating system and the presence of known vulnerabilities)

• Industry compliance system: Ensures policy rules required by FISMA, healthcare, or other security requirements

• Threat intelligence feed: provides data from external sources of known vulnerabilities or reported attacks

• Network and system activity logs: provides near-real-time feedback on the state of information systems.

• Data access policies: rules and policies about access to resources, which should be used by the policy engine

• Public key infrastructure (PKI): This contains the certificates used by systems and users to aid in authentication

• ID management: Responsible for user accounts and identity records

• Security information and event management (SIEM): collects security-related information for later analysis (to refine policies and warn of possible attacks)

NIST combines these components into the following architecture:

 

NIST’s Core Zero Trust Logical Component Diagram from SP 800–207

 

Cloud Freedom — The NIST Zero Trust Architecture (ZTA) provides an approach to create a trusted resource anywhere, including the cloud. By using the NIST ZTA, cloud services can demonstrate:

• How do cloud services authenticate users? 
  • Appropriate policy enforcement and administration (IAM, LDAP, PKI)
• How do users authenticate cloud services? 
  • PKI infrastructure
• How do we adjust to shifting threats? 
  • CDM systems such as Amazon Guard Duty or native automation through CloudWatch
• How do we gather network logs, activity logs, and security information? 
  • Data gathering services such as CloudWatch and monitoring tools such as Kinesis Data Firehose
• How do we protect data from local network threats? 
  • Encryption in transit and at rest

Of course, the FISMA risk management framework and NIST controls still apply, so our cloud services need to be on trusted infrastructures such as Azure for Government and AWS GovCloud. But if a customer asks, “How does Zero Trust impact cloud services?”, we can answer, “The NIST ZTA teaches us how to create cloud services as trustworthy as local services.”