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/
