Security Architecture

Dr. Greg Bernstein

November 9th, 2021

Architectures For Security

References

Traditional Security Architecture

Modern Security Architecture

Traditional Network Security Architecture

From Zero Trust Networks.

Security Architecture History

From NIST Special Publication 800-207 Zero Trust Architecture

A typical enterprise’s infrastructure has grown increasingly complex. A single enterprise may operate several internal networks, remote offices with their own local infrastructure, remote and/or mobile individuals, and cloud services. This complexity has outstripped legacy methods of perimeter-based network security as there is no single, easily identified perimeter for the enterprise. Perimeter-based network security has also been shown to be insufficient since once attackers breach the perimeter, further lateral movement is unhindered.

Typical Modern Enterprise

From NIST Special Publication 800-207 Zero Trust Architecture

Zero Trust Premise

From NIST Special Publication 800-207 Zero Trust Architecture

Zero trust security models assume that an attacker is present in the environment and that an enterprise-owned environment is no different—or no more trustworthy—than any non enterprise-owned environment.

Lateral Movement

From Mitre ATT&CK Tactic: Lateral Movemet

Goal and Model

“the goal to prevent unauthorized access to data and services coupled with making the access control enforcement as granular as possible.”

Question 1

Does this look familiar?

Zero Trust Basic Tenets I

From NIST Special Publication 800-207 Zero Trust Architecture

  1. All data sources and computing services are considered resources. A network may be composed of multiple classes of devices.
  2. All communication is secured regardless of network location. Network location alone does not imply trust. Access requests from assets located on enterprise-owned network infrastructure (e.g., inside a legacy network perimeter) must meet the same security requirements as access requests and communication from any other non enterprise-owned network.

Zero Trust Basic Tenets II

From NIST Special Publication 800-207 Zero Trust Architecture

  1. Access to individual enterprise resources is granted on a per-session basis. Trust in the requester is evaluated before the access is granted. Access should also be granted with the least privileges needed to complete the task.

Zero Trust Basic Tenets III

From NIST Special Publication 800-207 Zero Trust Architecture

  1. Access to resources is determined by dynamic policy—including the observable state of client identity, application/service, and the requesting asset—and may include other behavioral and environmental attributes. An organization protects resources by defining what resources it has, who its members are (or ability to authenticate users from a federated community), and what access to resources those members need.

Zero Trust Basic Tenets IV

From NIST Special Publication 800-207 Zero Trust Architecture

  1. The enterprise monitors and measures the integrity and security posture of all owned and associated assets. No asset is inherently trusted. The enterprise evaluates the security posture of the asset when evaluating a resource request.
  2. All resource authentication and authorization are dynamic and strictly enforced before access is allowed. This is a constant cycle of obtaining access, scanning and assessing threats, adapting, and continually reevaluating trust in ongoing communication.

Zero Trust Basic Tenets V

From NIST Special Publication 800-207 Zero Trust Architecture

  1. The enterprise collects as much information as possible about the current state of assets, network infrastructure and communications and uses it to improve its security posture. An enterprise should collect data about asset security posture, network traffic and access requests, process that data, and use any insight gained to improve policy creation and enforcement.

Network View of ZT I

From NIST Special Publication 800-207 Zero Trust Architecture

  1. The entire enterprise private network is not considered an implicit trust zone. Assets should always act as if an attacker is present on the enterprise network, and communication should be done in the most secure manner available.
  2. Devices on the network may not be owned or configurable by the enterprise. Visitors and/or contracted services may include nonenterprise-owned assets that need network access to perform their role.

Network View of ZT II

From NIST Special Publication 800-207 Zero Trust Architecture

  1. No resource is inherently trusted. Every asset must have its security posture evaluated via a PEP before a request is granted to an enterprise-owned resource.
  2. Not all enterprise resources are on enterprise-owned infrastructure. Resources include remote enterprise subjects as well as cloud services.

Network View of ZT III

From NIST Special Publication 800-207 Zero Trust Architecture

  1. Remote enterprise subjects and assets cannot fully trust their local network connection. Remote subjects should assume that the local (i.e., non enterprise-owned) network is hostile.
  2. Assets and workflows moving between enterprise and nonenterprise infrastructure should have a consistent security policy and posture. Assets and workloads should retain their security posture when moving to or from enterprise-owned infrastructure. This includes devices that move from enterprise networks to non enterprise networks.

Zero Trust Architecture

ZT Logical Components

From NIST Special Publication 800-207 Zero Trust Architecture

Logical Components

Policy Components I

From NIST Special Publication 800-207 Zero Trust Architecture

  1. Policy engine (PE): This component is responsible for the ultimate decision to grant access to a resource for a given subject. The PE uses enterprise policy as well as input from external sources as input to a trust algorithm to grant, deny, or revoke access to the resource.
  2. Policy administrator (PA): This component is responsible for establishing and/or shutting down the communication path between a subject and a resource (via commands to relevant PEPs).

Policy Components II

From NIST Special Publication 800-207 Zero Trust Architecture

  1. Policy enforcement point (PEP): This system is responsible for enabling, monitoring, and eventually terminating connections between a subject and an enterprise resource.

Additional Data Sources I

From NIST Special Publication 800-207 Zero Trust Architecture

  • Continuous diagnostics and mitigation (CDM) system: This gathers information about the enterprise asset’s current state and applies updates to configuration and software components.
  • Industry compliance system: This ensures that the enterprise remains compliant with any regulatory regime that it may fall under (e.g., FISMA, healthcare or financial industry information security requirements).

Additional Data Sources II

From NIST Special Publication 800-207 Zero Trust Architecture

  • Threat intelligence feed(s): This provides information from internal or external sources that help the policy engine make access decisions. These could be multiple services that take data from internal and/or multiple external sources and provide information about newly discovered attacks or vulnerabilities.
  • Network and system activity logs: This enterprise system aggregates asset logs, network traffic, resource access actions, and other events that provide real-time (or near-real-time) feedback on the security posture of enterprise information systems.

Additional Data Sources III

From NIST Special Publication 800-207 Zero Trust Architecture

  • Data access policies: These are the attributes, rules, and policies about access to enterprise resources. This set of rules could be encoded in (via management interface) or dynamically generated by the policy engine. These policies are the starting point for authorizing access to a resource as they provide the basic access privileges for accounts and applications/services in the enterprise.

Additional Data Sources IV

From NIST Special Publication 800-207 Zero Trust Architecture

  • Enterprise public key infrastructure (PKI): This system is responsible for generating and logging certificates issued by the enterprise to resources, subjects, services and applications.

Additional Data Sources V

From NIST Special Publication 800-207 Zero Trust Architecture

  • ID management system: This is responsible for creating, storing, and managing enterprise user accounts and identity records (e.g., lightweight directory access protocol (LDAP) server). This system contains the necessary subject information (e.g., name, email address, certificates) and other enterprise characteristics such as role, access attributes, and assigned assets. This system often utilizes other systems (such as a PKI) for artifacts associated with user accounts.

Additional Data Sources VI

From NIST Special Publication 800-207 Zero Trust Architecture

  • Security information and event management (SIEM) system: This collects security-centric information for later analysis. This data is then used to refine policies and warn of possible attacks against enterprise assets.

Trust Algorithm and Network Requirements

Trust Algorithm Diagram

From NIST Special Publication 800-207 Zero Trust Architecture

Trust Algorithm Inputs I

From NIST Special Publication 800-207 Zero Trust Architecture

  • Access request: This is the actual request from the subject. The resource requested is the primary information used, but information about the requester is also used.
  • Subject database: This is the “who” that is requesting access to a resource [SP800-63]. This is the set of subjects (human and processes) of the enterprise or collaborators and a collection of subject attributes/privileges assigned.

Trust Algorithm Inputs II

From NIST Special Publication 800-207 Zero Trust Architecture

  • Asset database (and observable status): This is the database that contains the known status of each enterprise-owned (and possibly known nonenterprise/BYOD) asset (physical and virtual, to some extent).
  • Resource requirements: This set of policies complements the user ID and attributes database and defines the minimal requirements for access to the resource.
  • Threat intelligence: This is an information feed or feeds about general threats and active malware operating on the internet.

Network Requirements for ZT I

From NIST Special Publication 800-207 Zero Trust Architecture

  1. Enterprise assets have basic network connectivity. The local area network (LAN), enterprise controlled or not, provides basic routing and infrastructure (e.g., DNS).
  2. The enterprise must be able to distinguish between what assets are owned or managed by the enterprise and the devices’ current security posture. This is determined by enterprise-issued credentials and not using information that cannot be authenticated (e.g., network MAC addresses that can be spoofed).

Network Requirements for ZT II

From NIST Special Publication 800-207 Zero Trust Architecture

  1. The enterprise can observe all network traffic. The enterprise records packets seen on the data plane, even if it is not be able to perform application layer inspection (i.e., OSI layer 7) on all packets. The enterprise filters out metadata about the connection (e.g., destination, time, device identity) to dynamically update policies and inform the PE as it evaluates access requests.

Network Requirements for ZT III

From NIST Special Publication 800-207 Zero Trust Architecture

  1. Enterprise resources should not be reachable without accessing a PEP. Enterprise resources do not accept arbitrary incoming connections from the internet. Resources accept custom-configured connections only after a client has been authenticated and authorized. These communication paths are set up by the PEP. Resources may not even be discoverable without accessing a PEP. This prevents attackers from identifying targets via scanning and/or launching DoS attacks against resources located behind PEPs.

Network Requirements for ZT IV

From NIST Special Publication 800-207 Zero Trust Architecture

  1. The data plane and control plane are logically separate. The policy engine, policy administrator, and PEPs communicate on a network that is logically separate and not directly accessible by enterprise assets and resources. The data plane is used for application/service data traffic. The policy engine, policy administrator, and PEPs use the control plane to communicate and manage communication paths between assets. The PEPs must be able to send and receive messages from both the data and control planes.

Network Requirements for ZT V

From NIST Special Publication 800-207 Zero Trust Architecture

  1. Enterprise assets can reach the PEP component. Enterprise subjects must be able to access the PEP component to gain access to resources. This could take the form of a web portal, network device, or software agent on the enterprise asset that enables the connection.
  2. The PEP is the only component that accesses the policy administrator as part of a business flow. Each PEP operating on the enterprise network has a connection to the policy administrator to establish communication paths from clients to resources. All enterprise business process traffic passes through one or more PEPs.

Network Requirements for ZT VI

From NIST Special Publication 800-207 Zero Trust Architecture

  1. Remote enterprise assets should be able to access enterprise resources without needing to traverse enterprise network infrastructure first. For example, a remote subject should not be required to use a link back to the enterprise network (i.e., virtual private network [VPN]) to access services utilized by the enterprise and hosted by a public cloud provider (e.g., email).
  2. The infrastructure used to support the ZTA access decision process should be made scalable to account for changes in process load. The PE(s), PA(s), and PEPs used in a ZTA become the key components in any business process. Delay or inability to reach a PEP (or inability of the PEPs to reach the PA/PE) negatively impacts the ability to perform the workflow.

Network Requirements for ZT VII

From NIST Special Publication 800-207 Zero Trust Architecture 10. Enterprise assets may not be able to reach certain PEPs due to policy or observable factors. For example, there may be a policy stating that mobile assets may not be able to reach certain resources if the requesting asset is located outside of the enterprise’s home country. These factors could be based on location (geolocation or network location), device type, or other criteria.

Zero Trust Applied

Zero Trust Upgrade

From Zero Trust Networks.

ZT Control Plane

From Zero Trust Networks.

The supporting system is known as the control plane, while most everything else is referred to as the data plane, which the control plane coordinates and configures. Requests for access to protected resources are first made through the control plane, where both the device and user must be authenticated and authorized.

Example Vendors

Not an endorsement or a review, just a sample

// reveal.js plugins