| A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | ID | Practice | Stream Level Maturity Goal | Leading Assignment | Stakeholder 1 | Stakeholder 2 | Stakeholder 3 | Rationale | ||||||||||||||||||
2 | Governance | |||||||||||||||||||||||||
3 | Strategy & Metrics | |||||||||||||||||||||||||
4 | G-SM-A | Create and Promote | Identify objectives and means of measuring effectiveness of the security program. | Product security strategy | Organizational Security Strategy | Business Strategy | Product security strategy is a dedicated Assignment that takes the lead in this stream, in very close collaboration with the organizational security strategy. In practice, these responsibilities are often found in the same role at smaller organizations. The larger executive management team needs to be on board if a security initiative is to succeed. | |||||||||||||||||||
5 | G-SM-B | Measure and Improve | Identify objectives and means of measuring effectiveness of the security program. | Product security strategy | Organizational Security Strategy | Business Strategy | Product security strategy and organizational security strategy are jointly in charge of creating the whole measurement-based improvement approach. Executive management are informed stakeholders | |||||||||||||||||||
6 | Policy & Compliance | |||||||||||||||||||||||||
7 | G-PC-A | Policy & Standards | Identify and document governance and compliance drivers relevant to the organization. | Product security strategy | Organizational Security Strategy | Architecture | Evangelizing Security | Policies and standards are defined by product security strategy and signed off by organizational security strategy. Architecture assists in their translation to specific product areas, and evangelizing security exist in translation to all teams. | ||||||||||||||||||
8 | G-PC-B | Compliance Management | Identify and document governance and compliance drivers relevant to the organization. | Organizational Security Strategy | Cybersecurity Regulatory Compliance | Product security strategy | Product Ownership | Organizational Security Strategy is in charge of compliance management and works in tandem with Cybersecurity Regulatory Compliance to handle compliance management. Product Security Strategy and Product Ownership are key stakeholders. | ||||||||||||||||||
9 | Education & Guidance | |||||||||||||||||||||||||
10 | G-EG-A | Training and Awareness | Offer staff access to resources around the topics of secure development and deployment. | Evangelizing Security | Security Awareness and Training | Evangelizing security leads the effort on selecting and pusing for secure development and role-specific training, and work with Security Awareness and Training to make sure the training is rolled out in the organization. | ||||||||||||||||||||
11 | G-EG-B | Organization and Culture | Offer staff access to resources around the topics of secure development and deployment. | Evangelizing Security | Technical Leadership (Dev Lead) | Product security strategy | The teamlead for "Evangelizing Security" is responsible for building out a team of security evangelists and scaling the practice. This is in close support with the technical leadership Assignment and assisted by product security strategy. | |||||||||||||||||||
12 | Design | |||||||||||||||||||||||||
13 | Threat Assessment | |||||||||||||||||||||||||
14 | D-TA-A | Application Risk Profile | Best-effort identification of high-level threats to the organization and individual projects. | Product security strategy | Organizational Security Strategy | Product ownership | Architecture | Product security strategy takes the lead, collaborating closely with Organizational Security. The latter defines the overall risk strategy and is aware of the risk appetite / tolerance of the organization. Product Ownership assists with determining the profiles and mapping risk profiles to requirements. The architecture Assignment assists with technical guidance. | ||||||||||||||||||
15 | D-TA-B | Threat Modeling | Best-effort identification of high-level threats to the organization and individual projects. | Architecture | Offensive Security Testing | Product ownership | Technical Leadership (Dev Lead) | Architecture is in the lead to build out and scale the threat modeling practice. Offensive Security Testing plays an essential role coming up with realistic threat scenarios. Product Ownership helps define the threat risk. Finally, Technical leadership plays a supporting role. | ||||||||||||||||||
16 | Security Requirements | |||||||||||||||||||||||||
17 | D-SR-A | Software Requirements | Consider security explicitly during the software requirements process. | Architecture | Product ownership | Evangelizing Security | Defensive Security Testing | Architecture advises product ownership on security requirements. Evangelizing Security helps refine security requirements in the team. Defensive Security Testing supports from their knowledge domain where needed. | ||||||||||||||||||
18 | D-SR-B | Supplier Security | Consider security explicitly during the software requirements process. | Vendor Management | Cybersecurity Regulatory Compliance | Product security strategy | Vendor Management has the end Assignment here, but needs to be advised on security matters by both the Cybersecurity Regulatory Compliance and Product Security Strategy responsibilities | |||||||||||||||||||
19 | Secure Architecture | |||||||||||||||||||||||||
20 | D-SA-A | Architecture Design | Insert consideration of proactive security guidance into the software design process. | Architecture | Technical Leadership (Dev Lead) | Security is one of the core components of any architecture, and needs to be considered together with other "ilities". The Assignment to oversee this lies with Architecture in close collaboration with the Technical Leadership Assignment. Both need to build up security knowledge as the organization matures. | ||||||||||||||||||||
21 | D-SA-B | Technology Management | Insert consideration of proactive security guidance into the software design process. | Architecture | Defensive Security Testing | Technical Leadership (Dev Lead) | Technology management is about assessing the technological risks, where Devensive Security Testing can help. Architecture is still the lead Assignment. Technical Leadership is involved as well. | |||||||||||||||||||
22 | Implementation | |||||||||||||||||||||||||
23 | Secure Build | |||||||||||||||||||||||||
24 | I-SB-A | Build Process | Build process is repeatable and consistent. | Build system and automation | Technical Leadership (Dev Lead) | Architecture | Build system and automation is in charge of setting up the build and deploy pipelines. Technical leadership is closely involved. Architecture has a secondary role as certain architectural considerations might be essential when setting up the CI/CD. Vice versa as well - certain CI/CD decisions might have architectural impact. | |||||||||||||||||||
25 | I-SB-B | Software Dependencies | Build process is repeatable and consistent. | Build system and automation | Architecture | Cybersecurity Regulatory Compliance | Technical Leadership (Dev Lead) | Cybersecurity Regulatory Compliance is included due to licensing impact | ||||||||||||||||||
26 | Secure Deployment | |||||||||||||||||||||||||
27 | I-SD-A | Deployment Process | Deployment processes are fully documented. | Build system and automation | Architecture | Technical Leadership (Dev Lead) | Build system and automation is in charge of setting up the build and deploy pipelines. Technical leadership is closely involved. Architecture has a secondary role as certain architectural considerations might be essential when setting up the CI/CD. Vice versa as well - certain CI/CD decisions might have architectural impact. | |||||||||||||||||||
28 | I-SD-B | Secret Management | Deployment processes are fully documented. | Build system and automation | Architecture | Technical Leadership (Dev Lead) | Whereas the responsibilities needed for this practice are the same as for I-SD-A, note that Architecture plays a more essential role here due to the typical interplay between secret management and architectural decisions. | |||||||||||||||||||
29 | Defect Management | |||||||||||||||||||||||||
30 | I-DM-A | Defect Tracking | All defects are tracked within each project. | Technical Leadership (Dev Lead) | Evangelizing Security | Defensive Security Testing | Technical leadership is the primary responsible for defect tracking in close collaboration with the evangelizing security Assignment. Defensive Security Testing is involved in a secondary role. | |||||||||||||||||||
31 | I-DM-B | Metrics and Feedback | All defects are tracked within each project. | Evangelizing Security | Product security strategy | Technical Leadership (Dev Lead) | This is the team-level equivalent of G-SM-B. The Evangelizing Security Assignment functions as the liaison between Product Security Strategy and Technical Leadership | |||||||||||||||||||
32 | Verification | |||||||||||||||||||||||||
33 | Architecture Assessment | |||||||||||||||||||||||||
34 | V-AA-A | Architecture Validation | Review the architecture to ensure baseline mitigations are in place for typical risks. | Defensive Security Testing | Architecture | Technical Leadership (Dev Lead) | While this is clearly a task in the Architecture Assignment domain, Defensive Security testing has the lead in the Verification phase. Technical leadership is closely involved. What their team has built based on the architecture, is what is being evalated here. | |||||||||||||||||||
35 | V-AA-B | Architecture Mitigation | Review the architecture to ensure baseline mitigations are in place for typical risks. | Offensive Security Testing | Architecture | V-AA-B is the offensive counterpart of V-AA-A | ||||||||||||||||||||
36 | Requirements Testing | |||||||||||||||||||||||||
37 | V-RT-A | Control Verification | Opportunistically find basic vulnerabilities and other security issues. | Defensive Security Testing | Technical Leadership (Dev Lead) | Defensive security testing is in the lead for manual and automated verification activities. Technical leadership assists to ensure all requirements are translated to security test cases. | ||||||||||||||||||||
38 | V-RT-B | Misuse/Abuse Testing | Opportunistically find basic vulnerabilities and other security issues. | Offensive Security Testing | Technical Leadership (Dev Lead) | V-RT-B is the offensive counterpart of V-RT-A. In this stream, the focus is on negative misuse/abuse test cases. Offensive security testing has the lead to ensure the most realistic abuse test cases are covered, with technical leadership in the loop to make sure all requirements are covered. | ||||||||||||||||||||
39 | Security Testing | |||||||||||||||||||||||||
40 | V-ST-A | Scalable Baseline | Perform security testing (both manual and tool based) to discover security defects. | Defensive Security Testing | Build system and automation | Product security strategy | Technical Leadership (Dev Lead) | Defensive security testing advises on test tooling and helps with triaging and fine tuning of the results. Build system and automation makes sure the tooling is integrated, product security strategy and technical leadership are on board to determine response times and KPI's | ||||||||||||||||||
41 | V-ST-B | Deep Understanding | Perform security testing (both manual and tool based) to discover security defects. | Offensive Security Testing | Technical Leadership (Dev Lead) | Architecture | Offensive Security Testing is in the lead of maturing this stream, Technical leadership and Architecture are involved closely to define which are the critical components and make sure flagged issues are solved. | |||||||||||||||||||
42 | Operations | |||||||||||||||||||||||||
43 | Incident Management | |||||||||||||||||||||||||
44 | O-IM-A | Incident Detection | Best-effort incident detection and handling | Security Operations | Infrastructure | Technical Leadership (Dev Lead) | Security operations is in charge of the incident detection daily activities. Infrastructure and Technical Leadership are depended on to provide the right integrations and logging, and are pulled when incidents are detected. | |||||||||||||||||||
45 | O-IM-B | Incident Response | Best-effort incident detection and handling | Security Operations | Infrastructure | Technical Leadership (Dev Lead) | Organizational Security Strategy | Security operations is in charge of the initial incident response, infrastructure and technical leadership are part of the initial second line responders. The organizational security Assignment is helps define the concrete contingency scenarios for detected issues. | ||||||||||||||||||
46 | Environment Management | |||||||||||||||||||||||||
47 | O-EM-A | Configuration Hardening | Best-effort patching and hardening | Infrastructure | Technical Leadership (Dev Lead) | Architecture | Infrastructure leads the configuration hardening practice. Technical leadership and Architecture are closely involved as well, to make sure applications maintain the level of hardening required from the infrastructure side. | |||||||||||||||||||
48 | O-EM-B | Patching and Updating | Best-effort patching and hardening | Infrastructure | Technical Leadership (Dev Lead) | Architecture | Security Operations | Patching and updating is most often carried out by infrastructure. Technical leadership and architecture are typically involved in planning. Security operations mainly provide threat intelligence. | ||||||||||||||||||
49 | Operational Management | |||||||||||||||||||||||||
50 | O-OM-A | Data Protection | Foundational Practices | Cybersecurity Regulatory Compliance | Architecture | Technical Leadership (Dev Lead) | Infrastructure | Data protection is largely led by legal and compliance. Technical leadership is in charge of creating and maintaining data catalogs. Infrastructure plays a secondary role and is involved with activities like back ups and their timely destruction. | ||||||||||||||||||
51 | O-OM-B | System Decommissioning / Legacy Management | Foundational Practices | Product ownership | Technical Leadership (Dev Lead) | Infrastructure | Product ownership is in charge of the product lifecycle. Technical leadership supports this lifecycle, together with infrastructure. In addition, infrastructure is in charge of handling the upgrades/migrations. | |||||||||||||||||||
52 | ||||||||||||||||||||||||||
53 | ||||||||||||||||||||||||||
54 | ||||||||||||||||||||||||||
55 | ||||||||||||||||||||||||||
56 | ||||||||||||||||||||||||||
57 | ||||||||||||||||||||||||||
58 | ||||||||||||||||||||||||||
59 | ||||||||||||||||||||||||||
60 | ||||||||||||||||||||||||||
61 | ||||||||||||||||||||||||||
62 | ||||||||||||||||||||||||||
63 | ||||||||||||||||||||||||||
64 | ||||||||||||||||||||||||||
65 | ||||||||||||||||||||||||||
66 | ||||||||||||||||||||||||||
67 | ||||||||||||||||||||||||||
68 | ||||||||||||||||||||||||||
69 | ||||||||||||||||||||||||||
70 | ||||||||||||||||||||||||||
71 | ||||||||||||||||||||||||||
72 | ||||||||||||||||||||||||||
73 | ||||||||||||||||||||||||||
74 | ||||||||||||||||||||||||||
75 | ||||||||||||||||||||||||||
76 | ||||||||||||||||||||||||||
77 | ||||||||||||||||||||||||||
78 | ||||||||||||||||||||||||||
79 | ||||||||||||||||||||||||||
80 | ||||||||||||||||||||||||||
81 | ||||||||||||||||||||||||||
82 | ||||||||||||||||||||||||||
83 | ||||||||||||||||||||||||||
84 | ||||||||||||||||||||||||||
85 | ||||||||||||||||||||||||||
86 | ||||||||||||||||||||||||||
87 | ||||||||||||||||||||||||||
88 | ||||||||||||||||||||||||||
89 | ||||||||||||||||||||||||||
90 | ||||||||||||||||||||||||||
91 | ||||||||||||||||||||||||||
92 | ||||||||||||||||||||||||||
93 | ||||||||||||||||||||||||||
94 | ||||||||||||||||||||||||||
95 | ||||||||||||||||||||||||||
96 | ||||||||||||||||||||||||||
97 | ||||||||||||||||||||||||||
98 | ||||||||||||||||||||||||||
99 | ||||||||||||||||||||||||||
100 |