[ISM] Secure-by-design:

Secure-by-design and secure-by-default principles, use of memory-safe programming languages where possible, and secure programming practices are used as part of application development.

[SSDF] Maintain security lifecycle documentation records (SSS-02-01-07)

Maintain comprehensive records of security requirements, risks, and design decisions throughout the software's lifecycle. Track responses to each risk, including mitigations and justifications for exceptions, and periodically review these records to make necessary updates, ensuring an ongoing focus on security management and risk mitigation.

[SAMM] Perform application risk assessments (SSS-02-01-07-01)

Conduct regular application risk assessments to evaluate the potential business impact of attacks, focusing on breaches of confidentiality, integrity, and availability. Use a straightforward methodology, such as a structured set of 5-10 questions, to identify key application characteristics, including whether the application processes sensitive financial or privacy-related data or if it is internet-facing. Based on these findings, create a risk profile for each application and classify them using a simple qualitative scheme (e.g., high/medium/low risk). Use these classifications to prioritize security efforts and compare risks across applications. Mature organizations with risk-driven frameworks may employ more advanced quantitative methods but should leverage existing effective schemes where applicable rather than creating new ones unnecessarily. This structured assessment process ensures consistent evaluation and documentation of application risks, enabling effective risk mitigation and informed decision-making throughout the software lifecycle.

Operations

ID Operation Description Phase Agent
SSS-02-01-07-01-01 Standardized Application Risk Evaluation Questions Develop a set of 5-10 standardized questions to evaluate application risk, focusing on confidentiality, integrity, and availability (CIA), and key characteristics (e.g., financial data, privacy). Preparation Security team, Risk management team, Business analysts
SSS-02-01-07-01-02 Conduct application risk assessments Use the defined criteria to assess each application and understand its risk profile. Evaluate factors such as whether the application is internet-facing or processes sensitive data. Development Development teams, Security team
SSS-02-01-07-01-03 Classify applications by risk level Assign qualitative risk levels (e.g., high, medium, low) to applications based on the assessment results, ensuring consistent and comparable evaluations. Development Security team, Risk management team
SSS-02-01-07-01-04 Document and share risk profiles Maintain a centralized repository of application risk profiles, making them accessible to relevant stakeholders for prioritizing security efforts and tracking over time. Deployment Security team, Development leads, Compliance team
SSS-02-01-07-01-05 Periodically reassess application risk Conduct regular reviews or reassessments following major application changes, such as new features, integrations, or changes in the threat landscape Post-deployment Security team, Risk management team

References

Industry framework Academic work Real-world case
Information Security Manual (ISM-0401)
NIST Secure Software Development Framework (PW.1.2)
OWASP SAMM: Software Assurance Maturity Model (D-TA-1-A)

[SAMM] Inventorize risk profiles (SSS-02-01-07-02)

Establish a comprehensive inventory of application risk profiles to evaluate and prioritize security assurance activities across the organization. Implement an extensive, standardized evaluation framework that assesses risks related to information security (confidentiality, integrity, and availability of data), privacy concerns, and the interdependencies between applications (e.g., potential modifications to data categorized as read-only by other systems). This assessment should include all applications, including existing and legacy systems. Utilize business impact analysis to quantify and classify application risks, acknowledging that simple qualitative schemes (e.g., high/medium/low) may not sufficiently capture enterprise-wide complexities. Instead, adopt a more robust classification approach that enables consistent comparisons and prioritization across applications. Leverage these risk profiles to create a centralized inventory managed by Security Officers, providing accountability and transparency. This inventory equips Product Owners, Managers, and other organizational stakeholders with a clear, unified understanding of application risk levels, enabling informed decision-making and prioritization of security-related activities.

Operations

ID Operation Description Phase Agent
SSS-02-01-07-02-01 Develop a comprehensive risk evaluation framework ncorporate frameworks like NIST SP 800-30 or FAIR to evaluate risks thoroughly. Include questions on privacy implications and application interdependencies. Preparation Security team, Risk management team, Business analysts
SSS-02-01-07-02-02 Conduct risk assessments across all applications Evaluate all applications (existing, legacy, and new) to quantify and classify their risk levels using business impact analysis, covering security, privacy, and dependencies. Development Security team, Development leads, Compliance team
SSS-02-01-07-02-03 Quantify and classify risks with advanced metrics Leverage detailed metrics (e.g., financial impact, compliance penalties) to classify application risks on an enterprise-wide level, enabling more granular prioritization. Development Risk management team, Security team
SSS-02-01-07-02-04 Build a centralized risk profile inventory Consolidate risk profiles into a centralized inventory tool, making them accessible to stakeholders such as Security Officers to prioritize security activities. Deployment Security team, Product managers, IT operations
SSS-02-01-07-02-05 Review and update the inventory regularly Establish a schedule to reassess and update the risk profiles of applications to reflect changes in business operations, application use, and threat landscapes. Post-deployment Security team, Risk management team

References

Industry framework Academic work Real-world case
Information Security Manual (ISM-0401)
NIST Secure Software Development Framework (PW.1.2)
OWASP SAMM: Software Assurance Maturity Model (D-TA-2-A)

[SAMM] Standardize and scale threat modeling (SSS-02-01-07-03)

Adopt a standardized threat modeling methodology aligned with application risk levels to systematically identify, prioritize, and address potential security threats across the organization. Train architects, security champions, and other stakeholders in practical threat modeling techniques, using detailed playbooks, templates, and organization-specific examples. Ensure the methodology includes key components such as system diagramming, threat identification, design flaw mitigation strategies, and validation of threat model artifacts. Leverage frameworks like STRIDE or organization-specific threat checklists to uncover vulnerabilities and rank design flaws by risk level. Implement mitigating controls for identified threats and ensure stakeholders have the tools and knowledge needed to address these risks effectively. Define triggers for updating threat models, such as technological changes or new deployment environments, to maintain their relevance. Integrate the outputs of threat modeling into defect management processes for effective follow-up. Utilize application team tools to document and manage threat modeling artifacts, ensuring they are accessible, actionable, and updated as necessary. This standardized approach scales threat modeling across the organization, reinforcing proactive risk management and enhancing security posture.

Operations

ID Operation Description Phase Agent
SSS-02-01-07-03-01 Adopt a standardized threat modeling methodology Select and formalize a threat modeling approach (e.g., STRIDE, LINDDUN) tailored to organizational needs, aligned with application risk levels, and compatible with existing processes. Preparation Security team, Architects, Risk management team
SSS-02-01-07-03-02 Train stakeholders in threat modeling Provide hands-on training for architects, Security Champions, and other stakeholders, focusing on diagramming, threat identification, Development flaw mitigation, and validation. Development Security team, External trainers, Development teams
SSS-02-01-07-03-03 Create threat modeling playbooks and templates Develop standardized playbooks, templates, and organization-specific examples to make the threat modeling process clear, repeatable, and scalable across teams. Development Security team, Architects
SSS-02-01-07-03-04 Integrate threat models with defect management Ensure the output of threat modeling feeds directly into the defect management process, enabling seamless follow-up on identified risks and mitigations. Development Security team, Development leads

References

Industry framework Academic work Real-world case
Information Security Manual (ISM-0401)
NIST Secure Software Development Framework (PW.1.2)
OWASP SAMM: Software Assurance Maturity Model (D-TA-2-B)