Granular Control in the Network Environment (Activity 5.1.2 Part 2)

We have begun defining granular network access rules based on identity and device context in Activity 5.1.1 Part 1. Building on that policy foundation, and recognizing the increasing prevalence and importance of Application Programming Interfaces (APIs) in modern architectures, Zero Trust Activity 5.1.2: Define Granular Control Access Rules & Policies Part 2 directs our focus to applying granular access controls specifically at the API level, leveraging the context of the data being accessed.

This activity zeroes in on securing the interactions with data and services that happen over APIs within a Software-Defined Network (SDN) or alternative network architecture. It mandates that DoD Components utilize data tagging and classification standards (established, for example, in Activity 4.4.2) to develop data filters for API access. 

Imagine your data is tagged with sensitivity levels (e.g., Public, Internal, Confidential, Top Secret) or categories (e.g., Financial, HR, Customer). When an application or user attempts to access this data through an API call, the “data filters” (policies) intercept that request. These filters look at the data’s tags/classification and the identity/attributes of the entity making the request (who they are, their role, device compliance, etc.). Based on pre-defined rules, the filter then decides whether to allow or deny the specific API operation (read, write, delete, etc.) on that particular data. Instead of just saying “User A can access Application X,” these filters add a layer of granularity, saying things like “User A can access Application X, but only to view data tagged as ‘Public'” or “User B can modify data tagged as ‘Confidential’ via this specific API, but only from a managed device.”

In the context of Zero Trust, this is a powerful way to achieve granular control over data usage. It moves beyond simply authenticating the user and authorizing access to an application and instead enforces rules based on the sensitivity of the information being handled in real-time API interactions.

This activity is crucial because APIs represent direct pathways to data and application functionality. Without granular controls at this layer, even if network access is granted, sensitive data could be exposed or manipulated inappropriately. Securing the API level strengthens authorization and authentication, promotes encryption, and enhances monitoring.

The outcomes for Activity 5.1.2 Part 2 highlight the progress in implementing data-aware API security:

  1. Define data tagging filters for API infrastructure to support interoperability.
  2. Enforce authentication for all APIs at the API layer.

The ultimate end state for this activity emphasizes a more secure and monitored API landscape: Security is enforced at an API level to strengthen authorization and authentication, promote enabling encryption protocols, and support monitoring of malicious behavior at an API level to improve incident response. This signifies a move towards treating APIs as critical control points in the Zero Trust network environment.

Not that this activity is focused on implementing with non-mission/task critical applications and services as the initial phase.

Solutions for Achieving Define Granular Control Access Rules & Policies Part 2

Implementing granular control at the API level based on data context requires integrating data classification, identity, policy, and API management tools within your network architecture:

1. Leveraging Data Tagging and Classification:

  • Utilize the data tagging and classification standards and tools established in Activity 4.4.2. Ensure that data is accurately classified and tagged with sensitivity levels or other relevant attributes.
  • Make this data classification metadata available to the systems enforcing API access policies.

2. Formalizing API Decision Points (PDPs and PEPs):

  • Within your SDN or alternative network architecture, formally define where API access decisions will be made (Policy Decision Points – PDPs) and where they will be enforced (Policy Enforcement Points – PEPs).
  • API Gateways or API Management platforms often serve as these enforcement points, sitting in front of APIs to mediate access.

3. Implementing Granular Access Policies at the API Layer:

  • Define access policies specifically for APIs, leveraging attributes of the user (from IdP), the device (from device posture tools), the application making the API call, and the data classification/tags of the data being accessed or manipulated.
  • Develop “data filters” within these policies that allow or deny API operations based on the sensitivity of the data. For example, a policy might allow a user to read low-sensitivity data via an API but deny them the ability to write or delete high-sensitivity data via the same API, even if they have general access to the application.
  • Implement these policies within the formalized API Decision and Enforcement Points.

4. Enforcing Authentication for All APIs:

  • Implement mechanisms at the API layer to enforce strong authentication for all API calls. This goes beyond simply authenticating the user or device that initiated a session; it ensures that every API request is verified. This can involve API keys, OAuth tokens, or mutual TLS authentication, often managed through an API Gateway integrated with the Enterprise IdP.

5. Integrating Identity and Device Context:

  • Ensure that API Decision and Enforcement Points can access identity information from the Enterprise IdP (who is making the API call) and device context (from UEM/device posture tools) to inform granular policies.

6. Implementing for Non-Mission/Task Critical Applications:

  • Begin the implementation of these data-aware API access controls with applications and services that are not deemed mission or task critical. This allows for testing and refinement of policies and technical integrations before deploying to more sensitive systems.

Key Items to Consider:

  • API Inventory and Discovery: You need a comprehensive inventory of all APIs in your environment to apply policies effectively.
  • Integration of Data Classification with API Enforcement: Ensuring seamless and real-time access to data classification metadata by API Gateways or other enforcement points is crucial for data-aware policies.
  • Defining Granular Policies for Diverse API Operations: APIs have various operations (GET, PUT, POST, DELETE). Policies need to be granular enough to control specific actions based on data sensitivity.
  • Performance Implications: Implementing policy enforcement and logging at the API layer can introduce latency; performance testing is important.
  • Standardizing API Security: Establish enterprise standards for API authentication, authorization, and logging to ensure consistency.
  • Monitoring API Activity: Implement robust logging and monitoring of API access and usage events to detect anomalies and potential misuse, feeding into your Visibility & Analytics pillar.

Relevant Technologies and Tools:

Successfully implementing Activity 5.1.2 relies on technologies that enable granular control and monitoring at the API layer:

  • API Gateways / API Management Platforms: Serve as primary enforcement points, mediating access to APIs, enforcing authentication, applying policies, and often providing logging.
  • Data Tagging and Classification Tools: Provide the metadata about data sensitivity that informs API access policies (from Activity 4.4.2).
  • Enterprise Identity Provider (IdP) / Identity and Access Management (IdAM) Solutions: Authenticate users and NPEs making API calls and provide identity attributes for authorization.
  • Software-Defined Networking (SDN) or Alternative Network Architecture Components: The underlying network infrastructure that may influence where API Decision and Enforcement Points are placed and how traffic is routed.
  • Policy Decision Points (PDPs) / Policy Enforcement Points (PEPs) (API-Specific): Components within the architecture responsible for evaluating and enforcing API access policies. These can be functions of API Gateways or separate services.
  • Logging and Monitoring Infrastructure: Including SIEM, API monitoring tools, and potentially UEBA, for collecting, analyzing, and alerting on API access and usage logs.

For the Technical Buyer:

Activity 5.1.2 extends Zero Trust principles to the API layer, ensuring that access to data and functionality via APIs is strictly controlled and monitored based on context, including the sensitivity of the data involved. 

For technical buyers, this activity means leveraging API Gateways or Management platforms to enforce strong authentication for all APIs and defining granular policies that utilize data tagging and classification to restrict actions based on data sensitivity. Implementing this for non-critical applications first allows you to refine your approach before protecting your most sensitive APIs. This activity is fundamental to securing the increasingly vital API communication pathways in your network environment, a key element of a comprehensive Zero Trust architecture.

Pillar: Network and Environment

Capability: 5.1 Data Flow Mapping

Activity: 5.1.2 Define Granular Control Access Rules & Policies Part 2

Phase: Target Level

Predecessor(s): 5.1.1 Define Granular Control Access Rules & Policies Part 1

Successor(s): None

Technology Partners