# DevSecOps <a href="https://devsecops.org">DevSecOps</a> was developed in 2013 as a methodology for building software safer sooner, with several organizations migrating their workloads to the public cloud and/or software-defined infrastructure. During those cloud migrations, it became apparent that reactive controls and manual reviews could not keep pace with the speed and scale demanded by a continuous software delivery pipeline, regardless of contributing capability. From a [[Cybersecurity]] perspective, the value creation process driven by software development required adversary intelligence to be shared between cybersecurity and software engineers, software security requirements to be identified early, threat mitigations applied more broadly, and security verification to run throughout the entire Software Development Life Cycle (SDLC). This evolution demanded a new incarnation of cybersecurity capabilities and a rework of the top-level process. This overlay provides a maturity path for adopting the Cyber City Map from a DevSecOps perspective, starting with Incident Containment and moving towards an ideal state of a closed-looped Cybersecurity Program that can be continuously improved as part of the Software Development process. This process also helped us decide on a DevSecOps Maturity Model path for assessing the state of a DevSecOps program using the Cyber City Map. ## Cyber City Map x DevSecOps | | Stage 1 | Stage 2 | Stage 3 | Stage 4 | Stage 5 | | ------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------- | ------------------------------------------------------------- | --------------------------------------------------------- | --------------------------------------------------------------- | | | ***Ability to Respond, Fix, and Restore*** | ***Ability to Plan, Protect, and Monitor*** | ***Ability to Build, Verify, and Defend*** | ***Ability to Strategize, Refine, and Triage*** | ***Ability to Predict, Optimize, and Improve*** | | **A. [[Adversary Research]]** | | | A.1 [[Persona Management]] | A.2 [[Dwell Analytics]]<br><br>A.4 [[Exploit Management]] | A.3 [[Target Prediction]]<br><br>A.5 [[Adversary Intelligence]] | | **B. [[Control Development]]** | | B.3 [[Policy Management]]<br><br>B.2 [[Standards Management]] | B.1 [[Defense Modeling]] | B.5 [[Threshold Management]] | B.4 [[Test Plan Management]] | | **C. [[Threat Mitigation]]** | | C.3 [[Deny Listing]] | C.4 [[Deception Management]] | C.1 [[Allow Listing]] | C.2 [[Challenge Management]] | | **D. [[Control Verification]]** | D.4 [[Remediation Management]] | D.3 [[Risk Prioritization]] | D.2 [[Resilience Testing]] | D.1 [[Attack Surface Enumeration]] | D.5 [[Assurance Reporting]] | | **E. [[Incident Containment]]** | E.3 [[Incident Management]]<br><br>E.5 [[Asset Restoration]] | E.1 [[Alert Correlation]] | E.2 [[Case Management]] | E.4 [[Forensic Analysis]]<br><br> | E.6 [[Abuse Reporting]] | | [[Foundational Capabilities]] | [[Application Management]]<br><br>[[Backup and Recovery]] | [[Log Management]] | [[Code Management]]<br><br>[[Identity and Access Management]] | [[Asset Management]] | | ## Maturity Levels Maturing a DevSecOps program begins with establishing a set number of incident containment hours that outline a boundary for risk tolerance to be leveraged by the organization and developing capabilities that help drive down risk before an incident needs to be contained. ### Level 1 - The Basics At a basic level, every organization must be able to contain an adversary-instigated incident and restore a system back to health to begin its DevSecOps journey. Some call these capabilities "Shield Right" or "Shift Right", meaning they are closer to the end of the value creation process. These capabilities are often required by regulations and compliance standards with the need becoming obvious during an incident, making them a must-have. [[Application Management]] [[Asset Restoration]] [[Backup and Recovery]] [[Incident Management]] [[Remediation Management]] ### Level 2 - Standards and Transparency When an organization has the Level 1 basics in place, it is time to move towards creating standards and transparency that help enable the organization in the event of an incident. Being explicit about the organization's security policies and configuration standards helps everyone to understand clearly what needs to be done. Additionally, at Level 2, the organization has become declarative about what is not allowed in the environment and has identified alerts that would require immediate action. [[Alert Correlation]] [[Deny Listing]] [[Log Management]] [[Policy Management]] [[Risk Prioritization]] [[Standards Management]] ### Level 3 - Resilient by Design At Level 3, an organization can demonstrate more understanding of its adversaries and the attack surface that is being targeted. Organizations operating at Level 3 maturity have categorized their adversaries and established defensive models with test plans that help verify that digital assets are resilient by design. At this level, organizations have invested in building their environment so that it supports continuous testing and the ability for root cause issues to be traced for remediation. [[Case Management]] [[Code Management]] [[Deception Management]] [[Defense Modeling]] [[Identity and Access Management]] [[Persona Management]] [[Resilience Testing]] ### Level 4 - Measurably Secure Many organizations that have been doing DevSecOps for years are beginning to explore measurement and how to prove their digital assets are measurably secure. At this level, an organization has systems in place that map to their adversary personas. Planning and conversations revolve around where to reduce adversary dwell and whether enough investment exists to meet a control threshold. Organizations may be investing in allow listing for a more explicit security program. Testing is aggressive at this level with attack surface enumeration guiding how tests are performed to meet the goals of resilience and prove assets are measurably secure. Forensic analysis becomes a key contributor towards tracing root cause cybersecurity failures so they can be addressed. [[Allow Listing]] [[Asset Management]] [[Attack Surface Enumeration]] [[Dwell Analytics]] [[Exploit Management]] [[Forensic Analysis]] [[Threshold Management]] ### Level 5 - Continuous Improvement At the highest level of maturity, elite performers are able to continuously improve their capabilities achieving lower levels or risk. Organizations at this level have a significant advantage because they are able to understand more precisely where adversaries will spend their time and what that ultimately means in terms of value loss. Test plans and assurance reporting are used to prove that digital assets are protected, tested, and managed inline with defined cybersecurity expectations. The organization is highly integrated into the community of threat sharing and abuse reporting, considering it a major option in supporting its interests both internally and in alignment with its third parties. [[Target Prediction]] [[Adversary Intelligence]] [[Test Plan Management]] [[Challenge Management]] [[Assurance Reporting]] [[Abuse Reporting]] ## Inspiration & Resources + https://cloud.google.com/devops/state-of-devops/ + https://devsecops.org + https://csrc.nist.gov/Projects/program-review-for-information-security-assistance/security-maturity-levels + https://owasp.org/www-project-devsecops-maturity-model/ ## Release Notes + [[Q1 2024 Release#Develop Overlay for DevSecOps]] + [[WIP - Q3 2024 Release]] ## [Cyber City Map](https://cybercitymap.com/) © 2023-2024 by [ThirdScore, Inc.](https://thirdscore.com/) All Rights Reserved.