Exploring Microsoft Security Development Lifecycle (SDL)

Hello All,

Greetings for the day!

I was reading Power Platform related security article and got to know that – Power Platform service follows the Security Development Lifecycle (SDL). So curious to know about SDL and hence the article.

In this article we will discuss

• What is Microsoft Security Development Lifecycle
• 12 practices of Security Development Lifecycle
• what is Threat Modeling

Microsoft Security Development Lifecycle

• The Security Development Lifecycle (SDL) consists of a set of practices that support security assurance and compliance requirements
• The SDL helps developers build more secure software by reducing the number and severity of vulnerabilities in software / application, while reducing development cost
• Microsoft’s Security Development Lifecycle (SDL) embeds
  • comprehensive security requirements
  • technology specific tooling
  • mandatory processes into the development and operation of all software products
• This is continuous process – process should be updated with new techniques related to security
• There are 12 Security Development Lifecycle practices
  • Provide Training
  • Define Security Requirements
  • Define Metrics and Compliance Reporting
  • Perform Threat Modeling
  • Establish Design Requirements
  • Define and Use Cryptography Standards
  • Manage the Security Risk of Using Third-Party Components
  • Use Approved Tools
  • Perform Static Analysis Security Testing (SAST)
  • Perform Dynamic Analysis Security Testing (DAST)
  • Perform Penetration Testing
  • Establish a Standard Incident Response Process

PRACTICE #1 – Provide Training

• Everybody (Developers, Architects, Managers, Testers) involved in application / software development should understand security basics
• Proper training will enforce to implement security policies, SDL practices, standards, best practices

PRACTICE #2 – Define Security Requirements

• Implementing security and privacy is the fundamental aspect for any application / software
• Implementation of security and privacy is irrespective of development methodology we are using
• Security requirements must be updated timely basis in application and changes to threat landscape
• Identify the security requirements during initial phase of application – Initial design and planning stages
• Mostly following are the factors which influence security requirements
  • Legal and Industry requirements
  • Best practices / Coding practices
  • Internal standards
  • Previous incidents
  • Known threats

PRACTICE #3 – Define Metrics and Compliance Reporting

• It is important to define minimum acceptable levels of security
• Engineering / Development team should be accountable for meeting security criterias
• Setting up the acceptable levels, will help team to follow standard through the application development
• To track Key Performance Indicators or Security practices / tasks – the bug tracking / work tracking tools can be used like – AZURE DevOps
• Tracking tools will helps – security defects / tasks can be clearly labeled and setting with appropriate priority and severity

PRACTICE #4 – Perform Threat Modeling

• Threat modeling is – It’s an engineering technique we can use to help us to identify threats, attacks, vulnerabilities, and countermeasures that could affect our application
• We can use threat modeling to meet our company’s security objectives, and reduce risk
• There are five major threat modeling steps:
  •  Defining security requirements
  •  Creating an application diagram
  •  Identifying threats
  •  Mitigating threats
  •  Validating that threats have been mitigated

• Threat modeling can be applied at the component, application, or system level
• It is a practice that allows development teams to consider, document, and (importantly) discuss the security implications of designs in the context operational environment and in a structured fashion
• Reference – Microsoft Security Development Lifecycle Threat Modelling

PRACTICE #5 – Establish Design Requirements

• It is important that Security features / techniques such as – Logging, Cryptography, Authentication, Encryption etc are applied consistently and with detailed understanding of security they provide
• These techniques should be applied from initial phase so that no vulnerability occured in design

PRACTICE #6 – Define and Use Cryptography Standards

• Generally encryption techniques are used to protect all data either in storage or during transmission
• Its important to develop clear encryption standards that provide specifics on every element of encryption implementation
• Best practice is – Use only industry standard encryption libraries
• Also we need to make sure, whenever any update requires or need to replace encryption libraries we could easily do those

PRACTICE #7 – Manage the Security Risk of Using Third-Party Components

• Third party components include both – open-source software (OSS) and commercial off-the-shelf (COTS)
• For any third party component integrated in application, make sure to understand impact that a security vulnerability in them
• Have a accurate inventory of third party components – type of component used, security implementation in them

PRACTICE #8 – Use Approved Tools

• Make list of approved tools – check for their security checks / implementations
• Microsoft Security Development Lifecycle Resources

PRACTICE #9 – Perform Static Analysis Security Testing (SAST)

• Analyse the code before compilation / publishing
• Make sure all coding practices / best practices followed
• SAST is typically integrated into the commit pipeline to identify vulnerabilities each time the software is built or packaged

PRACTICE #10 – Perform Dynamic Analysis Security Testing (DAST)

• Performing run-time verification of our fully compiled or packaged software – checks functionality that is only apparent when all components are integrated and running
• This is achieved using a tool or suite of prebuilt attacks or tools that specifically monitor application behavior for memory corruption, user privilege issues, and other critical security problems

PRACTICE #11 – Perform Penetration Testing

• Penetration testing is a security analysis of a software system / application performed by skilled security professionals simulating the actions of a hacker
• Penetration test is perform to uncover potential vulnerabilities resulting from coding errors, system configuration faults, or other operational deployment weaknesses
• The test typically finds the broadest variety of vulnerabilities
• Penetration tests are often performed in conjunction with automated and manual code reviews to provide a greater level of analysis

PRACTICE #12 – Establish a Standard Incident Response Process

• Prepare Incident Response Plan
• This plan includes
  • Contact – In case security emergency
  • Protocol for security servicing
  • Plan for third-party code / components
• This plan helps to identify new threats which occurs over time
• This plan should be created in coordination with – organization’s dedicated Product Security Incident Response Team (PSIRT)
• References
  • Using Azure Security Center for an incident response

Thanks for reading. Any suggestion / feedback / thoughts are welcome

Have a nice time ahead and HAPPY LEARNING