Summary Introduction Incident Management A: Incident Detection B: Incident Response Maturity 1 - Best-effort incident detection and handling Best-effort incident detection with available log data Defined high-level incident response strategy Maturity 2 - Formal incident management process in place Automated log evaluation driven by process Root Cause Analysis with feedback loop Maturity 3 - Mature incident management Reliable timely incident detection Proactive incident + emergency exercises Environment Management A: Configuration Hardening B: Patching and Updating Maturity 1 - Best-effort patching and hardening Prioritized best-effort hardening Prioritized best-effort patching Maturity 2 - Formal process with baselines in place Hardening baseline and guidelines available Formal process covering the full stack Maturity 3 - Conformity with continuously improving process enforced Detection and handling of non-conformities Consolidated update process with SLA and reporting Operational Management A: Data Protection B: System decommissioning / Legacy management Maturity 1 - Foundational Practices Basic Data Protections in Place Identification of unused and legacy applications/services Maturity 2 - Managed, Responsive Processes Data catalogued and data protection policy established Decommissioning and legacy migration processes in place Maturity 3 - Active Monitoring and Response Data policy breaches detected and acted upon Proactive reliable handling of legacy applications/services During several presentations on the subject of SAMM and application security, in general, I used to ask the audience members to vote on the different Business Functions in terms of impact on the security of software.

Operations Introduction Incident Management Maturity 1 - Best-effort incident detection and handling Maturity 2 - Formal incident management process in place Maturity 3 - Mature incident management Incident Detection Best-effort incident detection with available log data Automated log evaluation driven by process Reliable timely incident detection Incident Response Defined high-level incident response strategy Root Cause Analysis with feedback loop Proactive incident + emergency exercises Environment Management Maturity 1 - Best-effort patching and hardening Maturity 2 - Formal process with baselines in place Maturity 3 - Conformity with continuously improving process enforced

Verification Introduction Architecture Assessment A: Architecture Validation B: Architecture Compliance Maturity 1 - Review the architecture to ensure baseline mitigations are in place for known risks. Identify application and infrastructure architecture components Ad-hoc review of the architecture against compliance requirements Maturity 2 - Review the complete provision of security mechanisms in the architecture Validate the architecture security mechanisms Analyze the architecture against known security requirements and best practices Maturity 3 - Review the architecture effectiveness and feedback results to improve the security architecture Review of the architecture components effectiveness Feedback the architecture review results into the enterprise architecture, organisation design principles & patterns, security solutions and reference architectures Requirements Driven Testing A: Control Verification B: Misuse/Abuse Testing Maturity 1 - Opportunistically find basic vulnerabilities and other security issues.

Implementation Introduction Secure Build Maturity 1 - Build process is repeatable and consistent Maturity 2 - Build process is optimized and fully integrated into the workflow Maturity 3 - Build process helps prevent known defects from entering the production environment. Build Process The build process is defined and consistent. The build process is fully automated and does not require intervention by the developer. Security defects may trigger the build to stop executing

Design Introduction The design business function holds one of the biggest contradictions in the information security industry. When teams are busy (and let’s be honest, most teams are) they don’t have time for activities such as Threat Modeling or documenting security or architecture requirements. However, these are exactly the activities that could help make teams less busy by allowing organizations make smarter decisions and apply more effective prioritization to determine which security defects require remediation.

Governance Introduction During several presentations on the subject of SAMM and application security, in general, I used to ask the audience members to vote on the different Business Functions in terms of impact on the security of software. In virtually all sessions Governance got the lowest scores, which should surprise no one. Frankly, if you work for an organization responsible for developing only a handful of custom applications, I would agree with that notion.