-
Notifications
You must be signed in to change notification settings - Fork 12
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #313 from aramhovsepyan/35
35
- Loading branch information
Showing
2 changed files
with
54 additions
and
1 deletion.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,49 @@ | ||
# Microsoft SDL and OWASP SAMM Mapping: A Comprehensive Analysis | ||
|
||
## Introduction | ||
|
||
The Microsoft Security Development Lifecycle (SDL) was introduced in 2004 as Microsoft’s response to the security challenges that plagued its Windows operating system. As the first formal secure SDLC framework, it laid the foundation for secure software development practices. | ||
|
||
Today in its latest version, Microsoft SDL comprises 10 security practices, each containing a set of requirements designed to reduce security risks across the software development lifecycle. While Microsoft does not specify terminology, we refer to these as "requirements." In total, there are 51 requirements across SDL's 10 practices. | ||
|
||
## Mapping granularity and semantics | ||
|
||
For this mapping, we aligned Microsoft SDL requirements with OWASP SAMM streams. SAMM's maturity model structure makes it ideal for such a comparison as each stream encapsulates activities within a specific security focus area, progressing through defined maturity levels. However, certain SDL requirements map more closely to specific SAMM activities due to their precise nature. For instance, signing and attesting artifacts aligns with SAMM’s Level 3 Deployment maturity, as lower levels of SAMM Deployment do not address such topics. | ||
|
||
To address this challenge, we have added semantics to the mapping. Most of the mappings the SAMM core team has created (e.g., BSIMM, IEC-62443-4-1) are expressed as simple crossovers. The crossover mappings only say that two items are related without specifying the nature of that relationship. For SDL to SAMM mapping we have added specifics. | ||
|
||
Here is a list of all mapping types: | ||
- Whole-part: Microsoft SDL Requirement is one part of SAMM. | ||
- Synonyms: Microsoft SDL requirement and SAMM stream are identical | ||
- Equivalence: Microsoft SDL requirement and SAMM stream are equivalent, but use different wording | ||
- General-specific: Microsoft SDL requirement is one way to achieve this SAMM Stream. | ||
- Prerequisite-dependency: Microsoft SDL requirement is required first to perform SAMM stream | ||
- Whole-part: SAMM stream is one part of Microsoft SDL requirement. | ||
|
||
|
||
## How similar are Microsoft SDL and SAMM? | ||
|
||
By analyzing the mapping details we are above all interested in understanding how similar the two frameworks are and what are their key differences. Microsoft SDL seems largely to be a subset of SAMM. While most SDL requirements align with SAMM, SAMM has broader coverage, extending to the enterprise-level view of the overall application security program. SDL’s specificity often ties requirements to Microsoft’s tools and solutions (e.g., GitHub, Azure). SAMM emphasizes versatility, accommodating diverse ecosystems and methodologies. | ||
|
||
Most SDL to SAMM mappings are of type **general-specific**, where SDL’s concrete requirements represent a specific way to achieve SAMM’s broader goals. For example, SDL’s recommendation to implement **privileged access workstations (6.3)** maps to SAMM’s high-level guidance on securing build pipelines **(I-SB-A)**. So it is not surprising that only 10 out of 51 SDL requirements have an **equivalence** relationship with SAMM, reflecting similar concepts but different phrasing. | ||
|
||
## SDL requirements not in SAMM | ||
|
||
To further analyze the similarities between the two frameworks we have looked at SDL requirements that were not mapped in SAMM. Only 4 requirements do not have an immediate analog in SAMM. | ||
|
||
1. **Threat modeling resources (3.6)**: As opposed to all other Microsoft SDL items, this one focuses on providing guidance on threat modeling resources, rather than a desired outcome or control. This is the reason why we didn’t map this requirement to a SAMM activity. SAMM provides guidance as an additional resource rather than part of the model. | ||
2. **Encrypt data in transit and at rest (4.1)**, **Post-quantum cryptography (4.2)**, and **Cryptographic agility (4.3)**: These are specific security requirements more aligned with frameworks like OWASP ASVS. They could fit within SAMM’s Secure Requirements (D-SR-A) or Secure Architecture (D-SA-A) streams, depending on the context. | ||
|
||
## SAMM streams not in SDL | ||
We have also looked at SAMM streams that are largely missing from SDL. | ||
|
||
1. **Broader and typical AppSec streams**: SAMM's scope includes areas like application security strategy, security champions programs, compliance obligations, and decommissioning processes, which are absent in SDL. | ||
2. **Supplier security**: SAMM’s **Supplier Security** stream ensures outsourced development adheres to best practices, whereas SDL’s "Secure the Software Supply Chain" focuses only on dependencies and artifacts. | ||
3. **Defect management**: SAMM emphasizes a systematic defect management program, which is crucial for security tracking and preventing regressions. | ||
4. **Requirements testing**: SDL seems to lack positive tests for verifying security requirements. SAMM’s **Requirements Testing** stream covers a broader scope, including abuse test cases and fuzzing, whereas SDL focuses narrowly on stress testing, particularly against DDoS. | ||
|
||
## Conclusion | ||
|
||
Both Microsoft SDL and OWASP SAMM share a common focus on enhancing security within the context of software applications, with a significant overlap in their coverage. However, the two frameworks serve distinct roles: SAMM offers a broader, more versatile structure adaptable to various technologies, while Microsoft SDL provides more specific guidance, particularly tailored to the Microsoft ecosystem. | ||
|
||
This complementary nature makes the combination of both frameworks especially valuable for teams operating in Microsoft environments. SDL’s specificity can act as a practical starting point for implementing SAMM, bridging the gap between high-level maturity goals and actionable security practices. Together, these frameworks empower organizations to build robust and effective application security programs suited to their unique needs and contexts. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters