Automation and Orchestration Capabilities

Inventory and catalog existing cybersecurity policies and standards:

• The Enterprise and Component collaborate to define a standardized format for policy documentation to facilitate comparison and analysis across the Component environment.
• In collaboration with the Enterprise, Component collects cybersecurity policies and standards for inventory and cataloging (e.g., access control, identification, and authentication policies).
• Component documents the scope of the inventory (e.g., systems, data types, User/Person Entity (PE)/Non-Person Entity (NPE) groups are covered, etc.) and any known limitations.

Document initial gaps and inconsistencies during inventory and cataloging:

• Component documents preliminary gaps and/or conflicting policies discovered in cybersecurity policies and standards during inventory and cataloging.

Review and analyze Component cybersecurity policies and standards to identify gaps in accordance with the ZT RA:

• The Enterprise and Component collaboratively review existing policies and standards for alignment with ZT principles.
• Perform gap analysis of Component cybersecurity policies and standards to determine and document gaps across Pillars and Capabilities according to the ZT RA.
• The Enterprise and Component leverage documentation of discovered gaps across Pillars and Capabilities according to the ZT RA, detailing missing or inadequate policies.

Review and validate Enterprise gap analysis:

• Review the gap analysis report for accuracy and completeness.

Enterprise and Component collaborate to develop remediation plans for identified gaps:

• Develop a remediation plan outlining the steps to address each gap identified in the previous task, in accordance with Enterprise and Component policies and procedures, prioritizing gaps based on overall ZT implementation strategy.

Enterprise and Component develop and/or update existing policies to address identified gaps:

• Ensure new or existing policies are:
  • Consistent with applicable laws, regulations, and industry best practices.
  • Designed to support interoperability and enable ZT functionality across the Enterprise and Component

Implement updated policies in cross-pillar activities:

• Communicate policy updates to relevant stakeholders.
• Apply updated policies for cross-pillar activities, where applicable.

Based on Enterprise guidance, the Component establishes a continuous lifecycle management strategy:

• Component establishes a continuous lifecycle management strategy that:
  • Maintains cybersecurity policies.
  • Incorporates feedback from stakeholders.
  • Meets the evolving needs of the Component.
  • Has a defined schedule for periodic policy reviews and updates.
  • Counters emerging threats.
• As required, Component provides progress reports to the Enterprise on policy inventory completion, gap remediation, and policy update implementation.
• Component investigates opportunities to integrate policy information with existing security solutions to automate policy enforcement and compliance monitoring.

Consider completing Activity 1.1.1 (Discovery) – Inventory User and Activity 2.1.1 (Discovery) – Device Health Tool Gap Analysis, to obtain User/PE/NPE lists:

• Leverage Activity 1.1.1 (Discovery) – Inventory User, to obtain an accurate and comprehensive User/PE list as established in the User Pillar.
• Leverage Activity 2.1.1 (Discovery) – Device Health Tool Gap Analysis, to obtain an accurate and comprehensive Hardware/Software List as established in the Device Pillar.

Collaborate with Enterprise to establish the DAAS access policy:

• Utilize the Enterprise access policy to establish Users/PEs/NPEs profile rules.

Leverage the Enterprise access policy to define Component profile rules for DAAS access:

• Adopt the access policy to define profile rules managing DAAS access for all Users/PEs/NPEs.
• Define the levels of access required for each role (e.g., read-only, read-write, administrative, etc.).
• Specify conditions and/or constraints for access (e.g., time-based, location-based, frequency, etc.).
• Employ a deny-by-default strategy that denies access to all resources by default and only explicitly grants access based on defined roles and responsibilities for all Users/PEs/NPEs.
• Finalize profile rules for DAAS access that meet these requirements.

Create access profiles that adhere to established profile rules:

• Document detailed access profiles for each role (e.g., access permissions, conditions, constraints, etc.).

Deploy ACLs that adhere to access profiles across the Component environment:

• Configure ACLs for all Users/PEs/NPEs to enforce the defined access profiles.
• Where applicable, use existing Policy Decision Points (PDPs) solutions to verify and validate that ACLs are operational and functioning as expected.

Supplement existing profile rules to restrict mission/task-critical access to DAAS within the Component environment for all Users/PEs/NPEs:

• Using the existing profile rules, create extended rules to further restrict mission/task-critical access to DAAS.
• Update ACL configurations based on these extended profile rules.
• Use existing Policy Decision Point (PDP) solutions to verify and validate that updated ACLs are operational and functioning as expected, where applicable.

Regularly review and update all profile rules, access profiles, and ACLs:

• Conduct regular reviews of profile rules and access profiles to ensure they remain effective, and in alignment with Enterprise and Component policies and procedures.
• Where applicable, update access profiles and ACLs as needed to reflect roles, responsibilities, and access requirements changes.

Complete Activity 6.1.2 (Phase One) – Organization Access Profile, to obtain Enterprise and Component security profile rules:

• Leverage established Enterprise profile rules for DAAS access using the established User/Person Entity (PE)/Non-Person Entity (NPE) lists, from Activity 6.1.2 (Phase One) – Organization Access Profile.
• Utilize the established Enterprise profile rules to develop security profiles at the Component level.
• Test, verify, and validate security profile rule efficacy in a controlled environment, where applicable.
• Document security profile rules and ensure consistency with ZT principles. Identify any potential conflicts or gaps between the security profile and ZT goals, like Least Privilege access, continuous verification, and micro-segmentation. Describe how any identified discrepancies will be addressed.

Manage DAAS access through Enterprise and Component profile rules:

• Inventory existing Component security profile rules and assess alignment with Enterprise policies.
• Standardize integration processes for merging Component rules into the Enterprise environment.
• Implement an iterative tuning approach to refine rule enforcement without disrupting access.
• Monitor and document rule efficacy, adjusting configurations as needed.

Standardize profile rule management across the Component environment:

• Define Component processes for managing Component profile rules.
• Define rules based on operational processes.
• Develop version control and change management procedures for rule updates, while maintaining rollback capability in case of rule failure.
• Automate rule application and enforcement using security orchestration tools, where possible.
• Document and refine rule management processes, to include dependency mapping.

Select and integrate a Service Catalog/CMDB with existing security solutions:

• Identify and leverage key ZT components, including PDP, PEP, and PIP details, where applicable.
• Develop, populate, and continuously maintain a Service Catalog/CMDB to provide comprehensive visibility into all ZT elements (e.g., attributes, relationships, dependencies, etc.).
• Establish an automated process for updating the Service Catalog/CMDB as the Component environment evolves.
• Ensure Service Catalog/CMDB integration with security monitoring and Incident Response (IR) solutions (e.g., PDPs, PEPs, PIPs, etc.), that allows for querying during IR to trace policy pathway.

Identify, enumerate, and organize manual and automated tasks:

• Apply appropriate solutions to identify and categorize lists of manual and automated task activities across the Enterprise and within the Component environment, where applicable.
• Using the solutions in the previous step, organize task activities into manual and automated categories.
• Identify repetitive and predictable tasks from the task activity list.

Establish an independent audit process for automated security tasks based on defined assessment criteria:

• Establish clear and measurable criteria against which the automated tasks will be audited.
  • These criteria should be derived from the security profiles, from Activity 6.1.3 (Phase Two) – Enterprise Security Profile Part 1, and align with relevant security policies and regulatory requirements.
• Examples of criteria include:
  • Effectiveness: Does the automated task achieve its intended security outcome?
  • Accuracy: Does the task perform its function correctly and reliably?
  • Efficiency: Does the task perform its function in a timely and resource-efficient manner?
  • Compliance: Does the task adhere to relevant security policies and regulations?
  • Logging and Monitoring: Does the task generate sufficient logs and metrics for monitoring and analysis?
• Analyze the audit results to ensure the task activities function as expected and are interoperable across the Enterprise and the Component environments before operational use.

Analyze the manual and automated task activity lists and categorize the task activities appropriately:

• Monitor the Component environment to further understand the manual and automated task activities and categorize them appropriately and effectively.
• Normalize and maintain the manual and automated activity list categories for consistency based on the needs of the Enterprise and the Component.

Prepare Enterprise and Component environments for cybersecurity defense strategy based on the task activity categories:

• Select appropriate cybersecurity solutions based on the policies and procedures of the Enterprise and Component environment.
• Leverage the cybersecurity solutions to fulfill the required functionality to manage the manual and automated task activities based on their determined categories.

Assess the manual task activities and their respective categories in preparation for retirement:

• Evaluate manual task activity operational overhead (e.g., time, labor, resources, etc.).
  • Processing time and system resources.
  • System accuracy and effectiveness.
  • Potential User/Person Entity (PE)/Non-Person Entity (NPE) error(s).
  • Sustained operational functionality and performance metrics.
  • Verification and validation of cybersecurity posture.
• Based on the evaluation, create a list of manual task activities to be retired.
• If manual task activities are to be retired, ensure no loss of functionality within the Enterprise and Component environments prior to manual task activity retirement.
• Verify and validate that automated mechanisms are in place and operational before retiring any manual task activities, where applicable.

Select a cybersecurity defense strategy based on the policies and procedures of the Enterprise and the Component:

• Enterprise and Component are encouraged to collaborate to establish the cybersecurity policies and procedures to meet environmental requirements.
• Choose an automated cybersecurity defense strategy, per the established policies and procedures of the Enterprise and the Component, that can depict process flow diagrams of the environment.

Conduct an independent audit process of the automated cybersecurity defense strategy before operational implementation:

• Audit the cybersecurity defense strategy to ensure effectiveness, Component environment readiness, and interoperability before operational implementation.

In preparation for implementation, create a process flow diagram for the automated cybersecurity defense strategy:

• Create a process flow diagram for the automated cybersecurity defense strategy.

Define baseline and integration requirements for SOAR:

• Define baseline integration requirements based on ZT Target-level functionality, and Enterprise/Component security policies.
• Identify key data sources and security solutions (e.g., SIEM, EDR, NAC, etc.) that require integration with SOAR.
• Develop standardized data formats in alignment with existing schema, logging mechanisms, and API communication protocols for interoperability.
• Conduct initial functional testing to verify and validate baseline integrations and ensure SOAR can ingest actionable security data.
• Document and refine integration for IR automation and security operations.

Determine key integration points across ZT Pillars:

• Map critical integration points, to include Policy Decision Point (PDP)/Policy Enforcement Point (PEP)/ Policy Information Point (PIP) relationships, across the User, Device, Application and Workload, and Network and Environment pillars.
• Prioritize integrations based on their potential to enhance ZT's security posture. Consider the following factors when determining integration priority:
  • Risk Reduction: Minimizing the attack surface. Focus on integrating services with high-risk exposure first.
  • Operational Needs and ZT Enablement: Prioritize integrations that support core operational needs while simultaneously advancing ZT principles.
  • Alignment with Enterprise SOAR Baseline: Leverage the Enterprise SOAR baseline to streamline integration efforts and ensure interoperability. This promotes consistent security policy enforcement and automated responses to threats, further strengthening the ZT framework.
• Perform a gap analysis to identify process deficiencies, required data, response capability gaps (e.g. data fidelity, timestamp integrity), and automation opportunities for implementing ZT principles.
• Collaborate with the Enterprise to define security event triggers, response actions, and policy enforcement criteria.
• Verify and validate integration performance through controlled testing and iterative refinements.

Integrate security solution(s) for IR automation:

• Deploy SOAR integration for bidirectional exchange with EDR, SIEM, Identity and Access Management (IAM) (e.g., Identity, Credential, and Access Management (ICAM), etc.), and network segmentation solutions.
• Configure automated strategies for threat detection, IR, and recovery based on ZT policies.
• Establish secure communication channels (e.g., API authentication, secure tunnels, etc.) for real-time data sharing between SOAR and security solutions, where applicable.
  • Authentication should occur via tokens or certificates, which must be actively managed to ensure they are valid, approved, and not revoked.
• Monitor integration performance, fine-tune automation workflows, and conduct testing to ensure system resilience.
• Monitor and optimize solutions for continuous improvement, ensuring integrations evolve with new security threats and Enterprise needs.

Define DRP that leverages SOAR for IR and recovery:

• Enterprise and Component collaborate to develop DRP that leverages SOAR for IR and recovery requirements in accordance with Enterprise policies and procedures.
• Implement SOAR-driven recovery mechanisms, including containment, rollback, and system restoration procedures.
• Verify and validate data integrity across integration points before and after data sharing.
• Establish continuous monitoring, verification, and validation processes to ensure compliance with recovery and protection objectives.
• Conduct testing to refine recovery strategies and assess IR and recovery efficacy.

Review existing standards and requirements:

• Leverage documentation and review existing data tagging, classification standards, and requirements to select appropriate ML solutions.
• Identify existing tagging schemas (e.g., metadata, labels, security levels, etc.) to determine their suitability for informing ZT Access Control policies and driving automated tagging with the chosen ML solution.
• Ensure the ML solution complies with Component security objectives and requirements.

Identify relevant data sets:

• Leverage the Component-federated tag library, from Activity 4.2.1 (Phase One) – Define Data Tagging Standards, which contains tagged and classified data used within the Component environment, ensuring tagging is standardized.
• Utilize the Global Key Access Store, a centralized data tag repository and single source of truth for all tags, from Activity 4.3.1 (Phase One) – Implement Data Tagging and Classification Tools.
• Determine data formats (e.g., structured, unstructured, images, text, etc.) and assess their compatibility with ML solutions.
• Ensure data is validated, accurately tagged, and classified according to standards, from Activity 4.2.1 (Phase One) – Define Data Tagging Standards.

Determine an appropriate ML solution based on compatibility and requirements:

• Select the appropriate ML solution (e.g., supervised learning, reinforcement learning, etc.) based on data availability and classification needs.
• Evaluate whether the ML solution supports classification constraints (e.g., need for role-based access to specific data types).
• Verify and validate that the ML solution can accommodate Component-determined labeling and classification.
• Confirm ML systems comply with Component data handling protocols, from Activity 5.4.4 (Phase Two) – Protect Data in Transit.

Deploy ML solution:

• Run the ML model in a test environment before deploying it in operational workflows to ensure performance and compatibility.
• Integrate ML solution with existing Component data management systems, where applicable.

Ingest and process data for ML solutions:

• Ingest and process data in the ML solution from the Component-federated tag library and the Global Key Access Store (e.g., data normalization, data transformation, feature engineering, etc.).
• Verify and validate that the ML solution maintains existing data tags and classifications.

Establish performance baselines:

• Define Key Performance Indicators (KPIs) for tagging accuracy, precision, false negative rate, recall, and overall model efficiency.
• Compare ML outputs to existing labels and classifications to determine deviations.
• Identify categorize, and document misclassifications (e.g., annotation error, system bias, model drift, etc.) in comprehensive error reports in preparation for model refinement.
  • If errors are detected, restore to a known good state.

Refine ML models using ingested data:

• Adjust parameters and data preprocessing techniques to improve performance.
• Retrain the model using a subset of verified and validated data to improve generalization, where applicable.

Verify and validate implemented data management/ML solutions:

• Conduct manual verification of ML-generated classifications against ground-truth labels.
• Confirm that the data management/ML solutions are operational and performing as expected.
  • If errors are detected, restore to a known good state.

Train ML solution with supervised learning to improve analysis results:

• Select an approved, validated representative training dataset containing tagged and classified examples from existing data repositories.
• Use Enterprise and Component-approved supervised learning techniques to map input data to correct tags and classification labels.
• Implement cross-validation techniques to avoid errors (e.g., overfitting, bias-variance, data leakage, etc.)

Apply automated data tagging:

• Configure ML models to apply classification tags to new data.
• Integrate real-time tagging within Component data processing pipelines.
• Implement confidence scoring mechanisms to flag uncertain classifications for review.

Monitor performance through Subject Matter Experts (SMEs) and automated reviews:

• Track and document tag and classification accuracy metrics over time.
• Create a workflow where SMEs review and approve ML-generated tags and classifications.
• Establish automated alerting for tagging and classification anomalies.
• Implement a feedback loop where incorrect classifications are fed back into training datasets.

Iterate and improve the ML solution:

• Retrain models in an iterative approach using corrected datasets from human reviews.
• Regularly update training datasets to reflect evolving tagging and classification patterns.
  • If errors are detected, restore to a known good state.

Ensure compliance and security:

• Conduct periodic compliance reviews to ensure the ML solution follows Enterprise and Component tagging and classification standards and requirements.
• Implement Role-Based Access Controls (RBACs) to prevent unapproved classification modifications.
• Maintain audit logs of ML tagging (e.g., who/what applied the tag) and classification activity for review and accountability.

Identify and categorize all response activities within the environment:

• Uniquely identify all response activities for all approved manual and automated response activities within the Enterprise and Component environments.
• Uniquely identify and create categorized criteria or elements for all manual and automated response activities within the Enterprise and Component environments.
• Verify and validate that categorization is comprehensive and accurate across Enterprise and Component environments.

Analyze categorized response activities to address security incidents and operational challenges:

• Leverage categorized response activities for all manual and automated response activities within the Enterprise and Component environments to improve awareness and handle incidents and challenges.
• Verify and validate that security incidents are handled in a timely and effective manner to ensure that threats and anomalies are addressed systematically and efficiently.

Improve response time through response process automation:

• Enterprise and Component collaborate to automate Zero Trust (ZT) responses based on established policies, such as access revocation, network segmentation changes, and alerting.
• Integrate automated response tooling with existing Policy Enforcement Points (PEPs) to streamline security actions and ensure consistent application.

Assess current Component ZT posture and identify gaps:

• Perform a gap analysis to determine how existing security automation capabilities support or hinder ZT principles and identify areas of improvement that can be resolved with appropriate SOAR solution(s).
• Identify Component-specific security gaps hindering ZT adoption that could be addressed by SOAR solution(s), focusing on automation opportunities for Least Privilege and continuous verification.

Complete predecessor Activity 6.6.2 (Phase One) – Standardized Application Programming Interface (API) Calls and Schemas Part 1, in order to:

• Leverage standardized Application Programming Interface (API) calls to enable seamless SOAR solution(s) integration, consistent communication, and secure data exchange across the Component’s security infrastructure.

Complete predecessor Activity 6.7.1 (Phase One) – Workflow Enrichment Part 1, in order to:

• Leverage SOAR workflows to automate key ZT actions, such as access revocation, micro-segmentation changes, verification, and validation of device posture, improving IR and threat mitigation.

Component collaborates with the Enterprise to develop SOAR solution(s) requirements, such as:

• Develop baseline technical and operational requirements in alignment with ZT principles and ZT Target-level functionality.
• Define functional capabilities (e.g., IR automation, scalability, threat intelligence integration, etc.).
• Reconcile any conflicts between Enterprise cybersecurity policies and ZT principles when implementing SOAR, prioritizing ZT requirements where feasible.

Develop procurement strategy:

• Determine appropriate procurement approach (e.g., Enterprise-wide contract, individual Component procurements, etc.).
• Ensure alignment with Enterprise and Component acquisition policies.

Component evaluates and procures appropriate SOAR solution(s):

• Conduct technical assessments and tool demonstrations before selecting a SOAR solution capable of meeting the Component’s requirements and achieving the objectives.
• Evaluate SOAR solution(s) based on compliance with established requirements, ZT principles, and Component needs.
• Component should procure the relevant SOAR solution(s) based on the evaluation results in alignment with appropriate procurement policies.

Develop initial SOAR functionalities:

• Implement baseline configurations and policies to automate actions, such as access requests, security event analysis, and vulnerability remediation in alignment with ZT principles.
• Begin initial integrations with the existing Component cybersecurity infrastructure.

Develop SOAR Implementation Plan:

• Define a phased integration approach based on the Component’s ZT maturity, beginning with automation of foundational capabilities such as Identity, Credential, and Access Management (ICAM), endpoint protection, and network segmentation.
• Identify integration points between the SOAR solution(s) and existing security solutions (e.g., Security Information and Event Management (SIEM), threat intelligence platforms, vulnerability management, and endpoint detection and response) to enable contextual data sharing and automated decision-making.
• Establish interoperability and scalability standards to ensure SOAR workflows can dynamically orchestrate IR actions, enforce access policies, and adapt to evolving threat conditions across environments.

Implement SOAR solution(s):

• Deploy SOAR solution(s) across Components per the Implementation Plan developed above to enable ZT Target-level functionality.
• Establish continuous monitoring for dynamic decision-making based on Access Control policies and performance metrics.
• Integrate SOAR into the Component's IR plan, automating ZT responses like access revocation and system isolation to enforce Least Privilege and minimize the impact of breaches.

Verify and validate SOAR integration and functionality:

• Confirm that SOAR solution(s) perform all required functions specified in the established requirements.
• Confirm that SOAR integrations enable automated enforcement of ZT policies, including Access Control policies, data protection policies, and IR playbooks.
• Establish continuous monitoring with verification and validation procedures to ensure continued functionality throughout the environment.

Evaluate tooling and solutions for compliance:

• Review Enterprise API standards.
• Determine which Automation and Orchestration tools should be reviewed for compliance across the Enterprise and Component environments.
• Ensure the tools adhere to Enterprise API security standards and protocols across the Enterprise and Component environments.

Based on the evaluation, determine if the tooling is compliant or non-compliant with Enterprise API standards:

• Define assessment criteria for evaluating tool compliance (e.g., proper protocols and capabilities to monitor, control access, interoperate with other pillars, etc.).
• Create a compliance checklist based on the identified Enterprise API standards and requirements.
• Using the checklist results, determine whether the Automation and Orchestration tooling and solutions are compliant or non-compliant.

Perform a technical evaluation of Automation and Orchestration tooling to confirm functionality:

• Test each compliant tool to verify and validate required functionalities (e.g., monitoring, access control, interoperability with other pillars, etc.).

Define the API standard or equivalent automated interchange mechanism:

• Component collaborates with the Enterprise and considers best practices for existing API standards that support robust authentication/authorization mechanisms (e.g., OAuth 2.0, OpenID Connect, etc.) and data encryption for data in transit and at rest.
• Define a comprehensive API standard document that outlines:
  • Approved patterns, protocols, and security measures.
  • Logging, monitoring, and Incident Response (IR).
  • Data formats based on the Enterprise/Component collaboration and industry best practices.

Manage exceptions:

• Identify and document APIs that are incompatible with established standards.
• Evaluate and document risks associated with each noncompliant API in accordance with Enterprise and/or Component risk assessment policies.
• Determine disposition for each API:
  • Approved with a documented exception, or
  • Rejected and scheduled for remediation or decommissioning.
• Grant approval only when the mission justification outweighs the assessed security risks.
• Periodically reassess all approved exceptions to confirm continued necessity and acceptable risk.

Catalog all existing APIs across the Component:

• Identify all APIs within the Component environment(s).
  • Where possible, leverage automated discovery tools and create an API catalog with details on usage, data sensitivity, and current security posture.
  • Leverage the SDN API inventory, from Activity 5.2.1 (Discovery) – Define Software-Defined Networking (SDN) Application Programming Interfaces (APIs).
  • Leverage identified APIs, from Activity 3.2.3 (Phase Two) – Automate Application Security and Code Remediation Part 1.
• Review the API catalog to identify which APIs require updates for compliance and which must maintain backward compatibility for legacy integrations.

• Collaborate and coordinate on existing API standards or equivalent automated interchange mechanisms as agreed upon across the Component environment.
• Determine environment-specific requirements in preparation for adopting the API standard or equivalent automated interchange mechanisms.
• Assess environment applications and services to identify necessary updates for alignment with the API standard, where applicable, across the Component environment.
• Develop a phased rollout plan to minimize disruption that prioritizes APIs based on risk, criticality, and update feasibility.

Update existing APIs through adoption of the new API standard:

• Test implementation of the new API standard in a controlled environment, for example:
  • Confirm APIs properly apply and support configurations defined by the new standard.
  • Verify that deployed solutions and integrated systems remain compatible with the updated API requirements.
• Update existing APIs to comply with new API standard.

Verify and validate updated APIs:

• Perform:
  • Functional testing on the updated APIs to ensure they meet the new standards.
  • Integration testing to confirm interoperability with other systems across the Component environment.
  • Security testing, such as penetration testing, vulnerability scanning, etc.
  • Performance testing.
• Where possible, create automated services or workflows that will enforce the API standards.
• Establish continued monitoring and alerting for non-compliance or deviations from the established API standard.

Monitor and document solutions to ensure functionality:

• Establish real-time/near real-time monitoring solutions to track the status of API performance and security compliance.
• Leverage API gateway logs and Security Information and Event Management (SIEM) systems to detect anomalous API activity that could indicate malicious activity.

Determine ZT applications/services readiness for adoption of API standard, from Activity 6.6.2 (Phase One) – Standardized Application Programming Interface (API) Calls and Schemas Part 1:

• Evaluate governance readiness and technical interoperability for all Component ZT applications/services (e.g., PEP, PDP, PIP, etc.) for API standard adoption.
• Determine which Component ZT applications/services are prepared to adopt the API standard based on readiness and interoperability evaluation.

Manage Exceptions:

• Applications/services that cannot adopt API standards are:
  • Identified
  • Documented
  • Approved or rejected
• Approval is granted when justification for the exception outweighs the risks to the Enterprise/Component.
• Risks are determined by the Enterprise and/or Component.
• Approvals are periodically reassessed.

Develop and execute an integration plan:

• Develop a strategy to integrate the API standard across the Component environment, prioritizing high-impact (e.g., enforcement points) systems first.
• Create a roadmap for API standard adoption across all prepared ZT applications/services, to include required schema alignment (e.g., mandatory attributes for PDP/PEP), focusing on those requiring Target-level or Advanced integration.
• Develop a transition plan to replace ZT applications/services that are determined unprepared for API standard adoption.
• Collaborate with relevant teams to outline technical and security requirements for API standard adoption in each ZT application/service.
• Implement necessary updates to the environment of ZT applications/services to facilitate API standard integration.

Implement continuous monitoring and automation to ensure compliance:

• Configure continuous monitoring to track API usage, performance, drift detection, and security events in real-time.
• Verify and validate API standard compliance through regular testing for all ZT applications/services.
• Provide feedback and continuous improvement recommendations to further optimize API standard compliance and automation.

Test, verify, and validate API standard adoption and automation:

• Conduct functional testing to ensure the APIs function as expected and adhere to the prior defined standards.

Audit and document API standard integration and automation:

• Conduct regular audits to verify and validate compliance with API standards and confirm that integration and automation are functioning as expected.
• Document audit results to identify gaps and areas for improvement in the API integration across the Component environment.

Consider completing Activity 7.5.1 (Phase One) – Cyber Threat Intelligence (CTI) Program Part 1, to develop a CTI policy:

• Component collaborates with the Enterprise to develop a CTI policy that informs ZT actions, such as access revocation, network segmentation changes, and enhanced security monitoring, based on real-time threat data.
  • Ensure scalability and adaptability to future threats, from Activity 7.5.1 (Phase One) – Cyber Threat Intelligence (CTI) Program Part 1.

Component continues collaboration with the Enterprise to develop cybersecurity IR procedures based on the CTI policy:

• Leverage the established CTI policy to develop cybersecurity IR procedures in alignment with Enterprise and Component policies and the NIST CSF functions:
  • Identify
  • Protect
  • Detect
  • Respond
  • Recover.
• Incorporate automated ZT actions into the IR procedures, such as access revocation, system isolation, and dynamic network segmentation, to support timely detection, containment, mitigation, and incident recovery.

Implement security response workflows that incorporate contextual and threat intelligence to drive adaptive, automated responses:

• Prioritize detected security incidents based on their potential impact to the ZT Architecture (ZTA), considering User/Person Entity (PE)/Non-Person Entity (NPE) behavior, historical threat trends, access logs, and other relevant data.
• Analyze historical threat events to identify patterns, techniques, or exploit paths that could circumvent ZT controls, and use findings to enhance preventive and detective capabilities.
• Enhance security response workflows by integrating CTI feeds into ZT enforcement points, enabling automated incident containment actions such as access revocation, host isolation, or dynamic network segmentation in accordance with the Component IR procedures.

Define enrichment requirements to support ZT-aligned IR workflows:

• Collaborate with the Enterprise to verify and validate external enrichment sources before ingestion, ensuring data accuracy, reliability, and relevance to ZT access control and automated responses.
• Identify the types of enrichment data required (e.g., entity behavior, device posture, vulnerability indicators) to enhance threat prioritization, detection fidelity, and response decisions.

Identify key enrichment data sources, from Activity 7.5.1 (Phase One) – Cyber Threat Intelligence (CTI) Program Part 1:

• Utilize internal data sources (e.g., Security Information and Event Management (SIEM), Endpoint Detection and Response (EDR), monitoring solutions, etc.) to gain comprehensive visibility into the security posture of ZT environments. Focus on data that provides insights into User/PE access patterns, device security, and application behavior.
• Reference approved external data sources, from Activity 7.5.1 (Phase One) – Cyber Threat Intelligence (CTI) Program Part 1 (e.g., threat intelligence feeds, vulnerability databases, industry reporting).

Plan environmental readiness for future enrichment integrations, where applicable:

• Identify where enrichment data will be consumed (e.g., policy enforcement points, analytics platforms) to strengthen ZT enforcement decisions.
• Ensure technical and policy prerequisites are defined for future ingestion and orchestration of approved enrichment data.

Test and validate security response workflows and IR processes prior to full implementation:

• Conduct controlled environment testing to ensure workflows include sufficient context (e.g., affected system, incident type, attribution metadata) for successful implementation.
• Verify and validate security response workflows and IR processes:
  • Can be implemented across the environment in accordance with Enterprise-aligned CTI policy and IR procedures.
  • Accurately and appropriately incorporate CTI and enrichment data.
  • Drive Component IR procedures, commensurate with the threat event level, ensuring that the action(s) taken align with the threat category and potential risks.
  • Support the intended ZT enforcement decision paths for future automation.

Leverage the established Cyber Threat Intelligence (CTI) policy, from Activity 6.7.1 (Phase One) – Workflow Enrichment Part 1:

• Utilize the Enterprise and Component cybersecurity IR procedures, from Activity 6.7.1 (Phase One) – Workflow Enrichment Part 1.

Identify additional advanced incident categories, scenarios, and response types for integration into existing workflows:

• Leverage IR types as determined in Activity 7.2.2 (Phase Two) – Threat Alerting Part 2.
• Identify advanced incident categories and scenarios (e.g., phishing, ransomware, insider threats, Advanced Persistent Threats (APTs), etc.)

Extend existing workflows to integrate the additional advanced incident categories, scenarios, and response types:

• Map current IR processes, to include decision-point sources (e.g., policy Decision Point (PDP) decision logs, Policy Enforcement Point (PEP) denial logs), and identify opportunities to leverage data analytics and threat intelligence to inform and automate ZT responses.
• Identify gaps and bottlenecks that prevent effective implementation of ZT principles during IR. Focus on areas where automation and data enrichment can improve security and reduce risk.
• Extend workflows to incorporate advanced incident categories and scenarios, gradually increasing automation and sophistication as the Component’s ZT implementation matures.

Identify enrichment data sources, from Activity 6.7.1 (Phase One) – Workflow Enrichment Part 1:

• Verify and validate internal and external enrichment data sources meet fidelity thresholds (e.g., approved sources, timestamp accuracy, confidence scoring, etc.), from Activity 6.7.1 (Phase One) – Workflow Enrichment Part 1.

Integrate enrichment data sources into the existing extended workflow developed in the previous task:

• Map the existing extended workflow to the enrichment data sources (e.g., steps, decision points, data flows, etc.).
• Identify gaps, bottlenecks, and areas where automation and/or additional enrichment data should improve the extended workflow.
• Use the mapping to extend existing workflows to include enrichment data, which will provide security teams with the intelligence necessary to respond more effectively to incidents.

Utilize the CTI policy, from Activity 6.7.1 (Phase One) – Workflow Enrichment Part 1, to identify CTI data feeds for advanced threat discovery:

• Leverage CTI data to enhance ZT data quality and integration.
  • Evaluate, verify, and validate CTI data feeds for their accuracy, timeliness, and relevance to ZT security. Prioritize feeds that provide high-fidelity threat intelligence and integrate seamlessly with existing ZT security solutions.
  • Conduct periodic reviews and purge intelligence/feeds as necessary.
  • Expand IR workflows to incorporate automated data analysis and correlation, combining internal security data with external threat intelligence to improve threat detection and response within a ZT framework.

Verify and validate IR workflows:

• Confirm existing IR workflows, from Activity 6.7.1 (Phase One) – Workflow Enrichment Part 1, continue to function as expected.
• Verify and validate IR workflows:
  • Successfully integrate and associate the advanced threat intelligence data with events as appropriate.
  • Equip security teams with the intelligence required to detect, investigate, and respond to incidents more efficiently and effectively.

Monitor and optimize IR workflows and enrichment sources:

• Implement continuous monitoring to track the performance of the IR workflows and to identify issues and/or areas of improvement.
• Continuously optimize the IR workflows based on feedback and performance data to ensure they remain efficient and effective.

Collaborate with the Enterprise to select approved enrichment sources based on Enterprise policies and procedures for future integration:

• Leverage Enterprise policies and procedures to select additional enrichment sources (e.g., UAM, UEBA, User/PE/NPE profiles, baselines, etc.)

Evaluate Component environment integration points during enrichment source adoption:

• Identify integration requirements for data flow between the Component environment and enrichment source(s).
• Determine the expected outputs and the impact on the existing security workflows before adoption.
• Before adoption, consider component environment scalability and interoperability (e.g., Application Programming Interface (API) availability, data formats, protocols, etc.).
• Ensure the Component environment can effectively ingest, process, and correlate enrichment data.