Secure Software Development Life Cycle

1. Three pillars of software security
 1) Risk Management framework ( http://melancholy8914.blogspot.co.uk/2017/01/security-risk-analysis-with-coras.html )
 2) Software security touchpoints
 3) Knowledge

 http://www.swsec.com/resources/pillars/

2. Software Security Touchpoints
 : Numbered according to effectiveness and importance of their "natural utility" per Gary McGraw in "Software Security"

Security Development Lifecycle (SDLC)	Touchpoints
Requirement & Use Cases	2) Architectural risk analysis  5) Abuse / Misuse Cases  6) Security Requirements
Architecture & Design	2) Architectural risk analysis
Test Plans	4) Risk-based security testing
Code	1) Code review with a tool
Tests & Test Results	3) Penetration testing
Feedback from the Field	3) Penetration testing  7) Security operations

 1) Code review with a tool
  - Static analysis tools to identify common vulnerabilities
  ( http://melancholy8914.blogspot.co.uk/2017/01/low-level-software-vulnerabilities.html )
  e.g. buffer overflow

 2) Architectural risk analysis
  ( http://melancholy8914.blogspot.co.uk/2017/01/security-risk-analysis-with-coras.html )
  - Inspections and analysis approaches
  e.g. lack of authentication

 3) Penetration testing
  - Use application like an attacker
  e.g. Information leakage

 4) Risk-based security testing
 ( http://melancholy8914.blogspot.co.uk/2017/01/risk-based-testing.html )
  - Security features an attack patterns / misuse cases
  e.g. Elevation of privilege

 5) Abuse / Misuse Cases
  ( http://melancholy8914.blogspot.co.uk/2017/01/eliciting-security-requirements.html )
  - Think like an attacker
  e.g. Spoofing

 6) Security requirements
  ( http://melancholy8914.blogspot.co.uk/2017/01/eliciting-security-requirements.html )
  - Functional security requirements and emergent security requirements
  e.g. No explicit description of necessary data protection

 7) Security operations
  - Network security, firewalls
  e.g. Intrusion detection

http://www.swsec.com/resources/touchpoints/

3. Security Development Lifecycle (SDL)
 : A software development security assurance process consisting of security practices by Microsoft

SDL	Practices	Descriptions
Training	1) Core Security Training	- Need to cover all the topics in the SDL
Requirements	2) Security and Privacy Requirements	- These are process and team organisation requirements, not technical requirements for the product
	3) Create quality gates/bug bars	- Define and document a bug bar for security and privacy  - Ensure that bug reporting tools can track security and privacy issues
	4) Security and Privacy Risk Assessment	- Start a security plan  - Identify timing and resources for SDL steps  - Security Risk Assessment: Identify specific functional areas  - Privacy Risk Assessment: Initial Privacy Impacting Rating (PIR)
Design	5) Establish Design Requirements	- Consider design principles
	6) Attack Surface Analysis / Reduction	- The best proactive strategy is to reduce a system's attack surface  - A system's attack surface has three abstract dimensions   : targets and enablers   : channels and protocols   : access rights
	7) Threat Modelling	- A process to understand (potential) security threats to a system, determine risks from those threats, and establish appropriate mitigations ( http://melancholy8914.blogspot.co.uk/2017/01/uncover-security-design-flaws-with.html ) ( http://melancholy8914.blogspot.co.uk/2017/01/uncover-privacy-design-flaws-with.html )
Implementation	8) Use Approved tools	- Security isn't static: Update your tools because they change with dynamic threat environment
	9) Deprecate Unsafe Functions	- Unsafe functions:  http://msdn.microsoft.com/en-us/library/bb288454.aspx
	10) Perform Static Analysis	- Code review with a tool
Verification	11) Perform Dynamic Analysis	- Run-time verification necessary to ensure a program's functionality works as designed  - Black box testing: testing proceeds without knowledge of the code  ( http://melancholy8914.blogspot.co.uk/2017/01/low-level-software-vulnerabilities.html )
	12) Fuzz Testing	- Deliberately send attack strings to the program to see how the program will react
	13) Attack Surface Review	- Inevitably, the code won't match the initial design  - Use Attack Surface Analyzer (ASA) to analyse actual attack surface
Release	14) Incident Response Plan	- Prepare Cyber Security Incident Response Plan (CSIRP)
	15) Final Security Review	- The Final Security Review (FSR) is an examination of all SDL activities performed prior to release  - Used as a determining factor on whether or not to release
	16) Release / Archive	- Complete final signoffs
Response	17) Execute Incident Response Plan	- Get ready to execute on response tasks outlined during Security Response Planning

https://www.microsoft.com/en-us/sdl/