Forging the Trust Signature: Defining Access Profile Rules for DAAS (Zero Trust Activity 6.1.2)

We’ve been laying the groundwork for Zero Trust automation by defining enterprise-wide policies (Activity 6.1.1) that span across Identity, Device, Data, and Network pillars. Now, we translate those broad policies into actionable, granular rules that dictate precisely who can access what in your environment, particularly focusing on all enterprise resources. This brings us to Zero Trust Activity 6.1.2: Organization Access Profile.

This activity dives deep into defining access profile rules which are comprehensive signatures of allowed access for specific resources. In this context, DAAS stands for “data, applications, assets, services.” This means the scope of our access rules covers nearly everything in the enterprise’s digital environment. DoD Components are tasked with developing these highly granular rules for both mission/task and non-mission/task DAAS access. This process directly utilizes the rich data and context we’ve been gathering from all foundational pillars: User, Data, Network & Environment, and Device. The DoD Enterprise then plays a crucial role by working with Components to synthesize these specific profiles into Enterprise security profile rules, aiming for a common access approach to DAAS across the entire organization. A phased approach can even be used, limiting initial risk by first creating profiles for critical DAAS access.

This activity is pivotal because it operationalizes the principle of least privilege and continuous verification. It’s about codifying “patterns of behavior” for access control, ensuring that every access attempt to DAAS is explicitly authorized based on a multifaceted profile.

The outcomes for Activity 6.1.2 highlight the successful development and initial standardization of these profile rules:

1. Component scoped profile rules are created to determine access to DAAS using capabilities from User, Data, Network & Environment, and Device pillars.
2. Initial Enterprise profile rules for access standard is developed for access to DAAS.
3. When possible, Component profile(s) utilize Enterprise available services in the User, Data, Network & Environment, and Device pillars.
4. Component mission/task critical profile rules are created.

The patterns of behavior are established for what outcomes are needed for access control at the Component level. This means you have a precise blueprint for who, on what device, from where, and under what conditions can access specific data services.

Solutions for Achieving Organization Access Profile

Implementing Activity 6.1.2 requires a collaborative approach to policy definition, leveraging data from across your Zero Trust ecosystem, and utilizing platforms capable of managing and enforcing granular access profiles:

1. Collaborative Policy Definition and Standardization:
   1. Process: Components define detailed access profile rules for their DAAS instances, mapping users/NPEs, devices, and network context to specific data access permissions. The Enterprise then works to consolidate and harmonize these into common Enterprise-level profiles, standardizing the approach.
   2. Data Sources: This process heavily relies on the attributes gathered from previous Zero Trust activities:
      1. User Pillar: User identity (roles, groups, attributes) from your Enterprise IdP (e.g., Okta).
      2. Device Pillar: Device identity, management status, compliance posture, and health (from UEDM, EDR).
      3. Data Pillar: Data classification and tagging (from Activity 4.4.2).
      4. Network & Environment Pillar: Network location, segment, and resource context.
2. Centralized Policy Management and Orchestration Platforms:
   1. Utilize a central platform capable of defining, storing, and managing these complex access profile rules. This platform acts as the Policy Decision Point (PDP) for DAAS access.
   2. Ensure this platform can consume attributes from various sources and translate the profile rules into enforceable policies.
3. Integrating Data and Policy Enforcement with Enterprise Services:
   1. Enterprise IdP/IdAM: Your Enterprise IdP serves as the authoritative source for user and NPE identities and attributes, which are fundamental to the “who” in the access profile rules.
   2. Zero Trust Network Access (ZTNA) / Cloud Security Platforms: These are often the key enforcement points for DAAS access. They take the defined access profile rules and apply them in real-time, brokering connections to DAAS based on identity and device posture.
   3. API Gateways: For DAAS accessed via APIs, these gateways enforce the API-specific access policies defined in the profile rules.
   4. Microsegmentation Solutions: Contribute by isolating DAAS components and enforcing policies down to the workload level.

How Zscaler and Okta Work Together to Achieve Desired Outcomes:

The synergy between Zscaler and Okta is central to successfully implementing the access profile rules in Activity 6.1.2, particularly for securing DAAS access:

• Okta (Enterprise IdP/IdAM): The “Who” and “What are they?”
  • Provides Rich Identity Context: Okta acts as the authoritative source for user and NPE identities. It manages their attributes (roles, groups, department, clearances, etc.). These are the fundamental inputs for the “User” pillar component of the access profile rules.
  • Enables Policy Foundations: Okta’s identity data, including attributes related to privileged access (if using Okta Privileged Access), directly informs the “Role, Attribute, and Condition-Based Access Control” aspects of the access profiles.
• Zscaler (Network & Environment / Device & Policy Enforcement): The “How and Where are they?” and “Can they connect?”
  • Consumes Okta Identity: Zscaler’s Zero Trust Exchange integrates seamlessly with Okta. When a user or NPE attempts to access a resource, Zscaler first authenticates the user/NPE via Okta, retrieving their verified identity and attributes.
  • Gathers Device & Network Context: Zscaler’s platform (e.g., via its Zscaler Client Connector, or integration with UEM/EDR like Trellix) gathers real-time device posture and network context (e.g., location, managed status, compliance, threat indicators).
  • Applies Enterprise Security Profile: With the user’s identity (from Okta) and the device/network context (from its own sensors/integrations), Zscaler becomes a primary Policy Enforcement Point (PEP). It evaluates the Enterprise Security Profile rules defined in Activity 6.1.2 in real-time. This allows it to dynamically enforce complex RBAC/ABAC and condition-based access controls for users and devices accessing DAAS.
  • Creates Logical Network Zones: Zscaler’s ability to create “logical network zones” for applications contributes to segmenting DAAS access, making these services invisible to unauthorized profiles.
• The Combined Synergy: Okta feeds Zscaler the authoritative user identity and attributes. Zscaler then takes this identity, combines it with real-time device and network context (some derived from its own agents, some integrated from other security tools), and applies the granular access profile rules (defined in Activity 6.1.2) to dynamically enforce access to DAAS. This partnership ensures that “patterns of behavior” for access are rigorously enforced on a per-identity basis, whether for users or devices, fulfilling the outcomes for DAAS access.

The Technical Buyer Takeaway

For technical buyers, this step is where you translate the data from your User, Device, Data, and Network pillars into precise, actionable access profile rules for DAAS. This means orchestrating a significant effort to define these granular profiles, ensuring seamless integration between your Enterprise IdP (Okta) and your network access enforcement points (Zscaler). This partnership allows Okta to provide the core identity context, while Zscaler leverages this information, combined with device and network context, to dynamically enforce access to your DAAS based on the defined profile rules. This activity establishes the critical “patterns of behavior” for access control, enhancing security by ensuring every DAAS interaction is explicitly permitted based on a multifaceted, continuously evaluated trust signature.

Pillar: Automation and Orchestration
Capability: 6.1 Policy Decision Point (PDP) & Policy Orchestration
Activity: 6.1.2 Policy Governance & Ownership
Phase: Target Level
Predecessor(s): 6.1.1 Policy Inventory & Development
Successor(s): 6.1.3 Enterprise Security Profile Part 1
Predecessor(s): None
Successor(s): 3.5.1 Continuous Authorization to Operate (cATO) Part 1