Zero Trust Continuous Configuration Enforcement (ZT-CCE)
Change Kill Chain: A Phase-Based Model To Prioritize Supply Chain Risk Management (SCRM) Activities
The concept of the Zero Trust Continuous Configuration Enforcement (ZT-CCE) model was to create a proof of concept for an efficient way to plan out a roadmap to successfully implement robust Zero Trust and Supply Chain Risk Management (ZT/SCRM) cybersecurity and privacy practices that focus on prevention and automated remediation. The ZT-CCE is essentially a “Change Kill Chain” for how this model highlights the nature of preventative security controls as an efficient way to protect an organization from the expense and operational disruptions associated with incident response and business continuity activities. The end result is a viable approach for organizations to use in order to create a prioritized project plan for ZT/SCRM practices that avoids a myopic, point solution focus by adopting secure practices that are applicable across the supply chain.
"Zero Trust Architecture (ZTA) is more than just by tying logical access to a user’s identity and should take into account the validated integrity of systems, applications and services across the supply chain."
Applying The Kill Chain Model To SCRM
The concept of a "kill chain" adopts the premise that it is easier to stop and prevent further damage if insecure practices or malicious activities are discovered earlier, rather than later. The intention of using the Change Kill Chain is:
By applying a prioritized, phased approach towards ZT/SCRM-related activities, it is possible to avoid rework and cascading failures by addressing dependencies earlier in the process; and
Focusing resources and efforts on preventative controls, rather than detective controls.
Prevention, tied with automated, reactive technologies can minimize operational disruptions from either hostile or accidental incidents.
The Change Kill Chain breaks the concept of ZT/SCRM down into 24 major steps, which can then be translated into a project plan. This project was approached from the question of, “If a consultant was hired to build a ZT/SCRM program, what would the plan be to start from nothing to get a company to where it has operational ZT/SCRM capabilities?” While the Change Kill Chain maps controls from NIST SP 800-161 to the steps in the model, it is important to emphasize that the prioritization and “bucketing” of controls into phases is a subjective endeavor and not everyone may agree with this approach. If you choose to use the Change Kill Chain, you will invariably need to modify the approach to fit your organization's unique business practices and specific needs.
[click on image to download PDF]
[click on image to download graphic]
The Change Kill Chain is made up of 24 phases (these correspond to those shown in the associated infographic). It is important to note that these steps can be applied both to internal practices and Third-Party Service Providers (TSP). Realistically, an organization must first “master the fundamentals” and have its own ZT/SCRM practices in order before proactive oversight of TSPs is feasible.
The Change Kill Chain is based on the principles of the Integrated Controls Management (ICM) model:
Define applicable controls;
Assign maturity-based criteria;
Publish policies & standards;
Assign stakeholder accountability;
Maintain situational awareness;
Manage risk; and
[click on image to download graphic]
Resilient vs Reactive Operational Mindset - Important Considerations For ZT/SCRM Planning
National Institute of Standards and Technology’s (NIST) SP 800-160, Developing Cyber Resilient Systems: A Systems Security Engineering Approach, is the authoritative source for "cyber resiliency" and secure engineering principles within the realm of cybersecurity and data protection. A common definition of resilience is “the capacity to quickly recover from difficulties.” Resilience is a measure of an organization’s elasticity – being able to spring back into a pre-determined operational state following an event. Organizations should strive to be resilient to IT and cybersecurity-related incidents both internally and across the supply chain. This concept requires automating Continuous Configuration Enforcement (CCE) across all application technology platforms.
NIST’s National Cybersecurity Center of Excellence (NCCoE) has produced several reference materials intended to support ransomware threat mitigation and all guidance starts with the assumption that devices are hardened - that is NIST's baseline starting assumption for organizations to protect against ransomware. Hardening systems and the automation of security validation is not a new concept where NIST SP 800-31, Guide to Malware Incident Prevention and Handling for Desktops and Laptops, states that "Organizations should have vulnerability mitigation capabilities to help prevent malware incidents. Organizations should have documented policy, processes, and procedures to mitigate known vulnerabilities that malware might exploit. Because a vulnerability usually can be mitigated through one or more methods, organizations should use an appropriate combination of techniques, including security automation technologies with security configuration checklists and patch management, and additional host hardening measures so that effective techniques are readily available for various types of vulnerabilities."
Traditional incident response and recovery operations are not designed with resilience in mind. Recovery is absolutely possible and Service Level Agreement (SLAs) help establish acceptable data loss parameters, maximum outages, etc. However, this is more of a way to bracket risk management decisions and while is an efficient manner to justify budgets for Continuity of Operations (COOP)-related technologies and staffing, it is not sustainable. While reactive operations are often viewed as heroic endeavors that “saved the organization from doom,” it does not mean that reactive model is the best methodology or least expensive path to follow. Resiliency is.
Reactive-Focused Security Operations: Downstream of Events/Incidents
If you study the graphic below, there are a few key takeaways:
Effort is on the downstream or “right side” of an incident or event – it is reactive. Baselining and configuration management on the upstream or “left side” of the event is often compliance-focused and are not directly tied to response/recovery operations.
The traditional, reactive model has minimal focus on baselining and configuration management.
When an incident occurs, there are structured plans to respond that span from minutes to years in duration:
Incident Response Plan (IRP)
Disaster Recovery Plan (DRP)
Business Continuity Plan (BCP)
Expense is primarily associated with event detection, response, remediation and recovery operations.
Resiliency-Focused Security Operations: Upstream of Events/Incidents
If you study the graphic below, there are a few key takeaways:
Effort is on the upstream or “left side” of an incident or event is prevention-focused. A decrease in effort on the upstream side of an event, will likely result in a decreased operational impact on the downstream or “right side” of the event occurrence.
There is significant effort placed on baselining and automating configuration management operations.
When an incident occurs, the automated remediation actions minimize impact and the necessity to activate IRPs, DRPs and BCPs.
Expense is primarily associated with tightly-controlled configuration management practices.
C-SCRM Kill Chain Phases
1. Establish Context for Supply Chain Risks & Implement A Zero Trust & Supply Chain Risk Management (ZT/SCRM) Program.
To build and maintain efficient and effective operations, a ZT/SCRM program must have a hierarchical vision, mission and strategy that directly supports the organization’s broader strategic objectives and business processes. This process of establishing context involves identifying all applicable external compliance requirements (e.g., laws, regulations and contractual obligations), as well as internal directives (e.g., Board of Directors (BoD), corporate policies, etc.). This is a due diligence element of the ZT/SCRM program.
This step has 5 subcomponent steps:
1a. Assign a Chief Supply Chain Officer (CSCO) to establish and run the ZT/SCRM program.
1b. Restructure the organization chart to eliminate conflicts of interests among leadership representing Lines of Business (LOB) within the organization.
1c. Identify applicable external requirements (e.g., laws, regulations & contractual obligations)
1d. Identify applicable internal requirements (e.g., business practices, BoD dictates, corporate policies, etc.)
1e. Develop a cybersecurity & data program-specific mission and strategy that supports the broader corporate strategy and business operations.
2. Define Applicable Zero Trust & SCRM Controls.
A tailored control set of cybersecurity and data protection controls must exist. This control set needs to be made of Minimum Compliance Criteria (MCC) and Discretionary Security Requirements (DSR). This blend of “must have” and “nice to have” requirements establish an organization’s tailored control set to ensure both secure practices and compliance are designed for.
This step has 3 subcomponent steps:
2a. Identify MCC.
2b. Identify DSR.
2c. Implement secure engineering principles and adopt a Zero Trust Architecture (ZTA).
3. Define Maturity-Based Criteria for ZT/SCRM Controls.
The cybersecurity & privacy program must assign maturity targets to define organization-specific “what right looks like” for controls. This establishes attainable criteria for People, Processes, Technology & Data (PPTD) requirements. Tailored maturity level criteria can be used to plan for, budget for and assess against. Maturity targets should support the organization’s need for operational resiliency.
This step has 4 subcomponent steps:
3a. Establish organization-wide maturity criteria for people, processes and technology.
3b. Establish maturity criteria for sensitive data and/or critical systems, applications and services.
3c. Develop & implement a resource plan (e.g., business plan, budget, road map, etc.) to meet compliance obligations.
3d. Prioritize objectives from the resource plan for PPTD requirements.
4. Publish Policies & Standards for ZT/SCRM.
Documentation must exist, otherwise an organization’s cybersecurity and data protection practices are unenforceable. Formalizing organization-specific requirements via policies and standards are necessary to operationalize controls. Documented policies and standards provide evidence of due diligence that the organization identified and implemented reasonable steps to address its applicable requirements.
This step has 2 subcomponent steps:
4a. Publish organization-wide cybersecurity and privacy policies to address applicable security and data protection requirements.
4b. Publish standards to enforce cybersecurity and privacy policies.
5. Assign Stakeholder Accountability.
Controls must be assigned to stakeholders to ensure accountability (e.g., business units, teams and/or individuals). These “control owners” may assign the task of executing controls to “control operators” at the Individual Contributors (IC)-level. Stakeholders utilize the prescriptive requirements from policies and standards to develop Standardized Operating Procedures (SOP) that enable ICs to execute those controls. The documented execution of procedures provides evidence of due care that reasonable practices are being performed.
This step has 5 subcomponent steps:
5a. Identify "control owners" for all applicable cybersecurity and privacy controls. These are the individuals or teams responsible for the control.
5b. Identify the "control operators" for all applicable cybersecurity and privacy controls. These are the individuals or teams executing the control.
5c. Stakeholders ensure control owners develop documented SOP to address the control objective(s).
5d. Stakeholders ensure control owners develop a System Security Plan (SSP) to document the "who, what, how, why, when & where" for products & services.
5e. Formalize access agreements for internal and external personnel, including rules of behavior for critical technologies.
6. Maintain Situational Awareness - Establish An Internal Audit (IA) Capability.
Situational awareness must involve more than merely “monitoring controls” (e.g., metrics). While metrics are a point-in-time snapshot into discrete controls’ performance, the broader view of metrics leads to a longer-term trend analysis. When properly tied in with current risk, threat and vulnerability information, this insight provides “situational awareness” that is necessary for organizational leadership to adjust plans to operate within the organization’s risk threshold.
An organization’s Internal Audit (IA) function provides quality control. This function can help validate the scope and impact of risk, which stakeholders may be unaware of. IA practices generate evidence of due care that reasonable steps are in place to validate stakeholder claims and assumptions.
This step has 10 subcomponent steps:
6a. Create a detailed asset inventory for all business-critical systems, applications and services (internally hosted as well as those hosted by third-parties).
6b. Create a detailed data inventory for all sensitive data, including "crown jewels" Intellectual Property (IP).
6c. Create a detailed inventory of contracts that flow-down sensitive data to Third-Party Service Providers (TSP).
6d. Create a detailed network diagram that includes TSPs and the geographic location where data is stored, transmitted and/or processed.
6e. Create a detailed inventory of TSP that make up the Direct Supply Chain (DSP) (e.g., direct contracts).
6f. Categorize TSP based to identify their criticality to the organization's mission and business processes, per LOB
6g. Create a Data Flow Diagram (DFD) that shows how sensitive data from the organization to TSP, including the TSP's subcontractors.
6h. Inventory TSP access control for both critical systems and sensitive data.
6i. Develop ZT/SCRM -specific metrics.
6j. Identify key stakeholders for a Quarterly Business Review (QBR) on ZT/SCRM metrics and issues.
7. Manage Risk.
Proactive risk management processes must exist across all phases of development/information/system life cycles to address confidentiality, integrity, availability and safety aspects. Risk management must address internal and external factors, including cybersecurity, privacy and ZT/SCRM considerations. To manage risk, it requires the organization to enforce a clearly defined risk threshold and ensure reasonably-expected secure practices are operational.
This step has 3 subcomponent steps:
7a. Develop & implement a Risk Management Program (RMP) to identify, assess and remediate risk.
7b. Perform a gap assessment from applicable statutory, regulatory and contractual obligations.
7c. Create a Plan of Action & Milestone (POA&M) to track and remediate deficiencies.
8. Change Control.
Develop & implement change control processes and workflows, including a Change Control Board (CCB) that is technically competent to evaluate security ramifications for baseline security configuration deviations.
9. Centralized Configuration Management Plan (CMP).
Develop and implement a centralized Configuration Management Plan (CMP) to enforce secure configurations.
10. System Hardening.
Identify, build & implement secure baseline configurations (e.g., hardening standards) for all technology platforms.
11. Incident Response.
Develop & implement incident response capabilities to detect, respond to and recover from incidents.
12. Physical Security.
Develop & implement physical security capabilities to detect, respond to and recover from physical security incidents.
13. Continuous Monitoring.
Develop & implement continuous monitoring capabilities through log collection and analysis (e.g., SIEM).
14. Identity & Access Management (IAM).
Develop & implement Identity & Access Management (IAM) to address "least privilege" and Role-Based Access Control (RBAC).
15. Network Security.
Develop & implement network security practices.
Develop & implement proactive maintenance practices.
17. Attack Surface Management (ASM).
Develop & implement Attack Surface Management (ASM) practices as part of a broader Vulnerability & Patch Management Program (VPMP).
18. Threat Intelligence.
Develop & implement a threat intelligence capability.
19. Business Continuity.
Develop & implement business continuity capabilities (e.g., Disaster Recovery (DR), Business Continuity (BC), Continuity of Operations (COOP), etc.).
20. Security Awareness Training.
Build and maintain a security-minded workforce through training & awareness.
21. Tamper Resistance & Detection.
Develop & implement tamper resistance and detection capabilities.
22. Information Assurance Program (IAP).
Develop & implement an Information Assurance Program (IAP) to validate control implementation.
23. Decommission & Migration.
Develop & implement system application and service decommissioning and migration capabilities.
24. Supply Chain Protections.
Implement and monitor supply chain protections (contractual obligations, assessments & monitoring compliance).
Going forward... cybersecurity and data protection measures must adapt and evolve to address business operations and the evolving threat landscape. This requires the adoption of a Plan, Do, Check & Act (PDCA) approach (Deming Cycle) to ensure the organization proactively identifies its requirements, implements appropriate protections, maintains situational awareness to detect incidents, operates a viable capability to respond to incidents and can sustain key business operations, if an incident occurs.