Dr. Drew Hwang, CIS, Cal Poly Pomona
Home
101
WDD
ECOMM
SWA
SP
Secure Web Development
Home
Basics
Offense
Defense
SDLC
Code
Access
Parameter
Perimeter
Browser
Industry
Resource
SDLC
Microsoft SDL
Agile Development
Best Practice
Requirement Elicitation
Static Analysis
Dynamic Analysis
Online Stores Case
System Goals
System Architecture
Framework
References
Print
Microsoft Security Development Lifecycle (SDL)
(source:
Microsoft Security Development Lifecycle
)
The Security Development Lifecycle (SDL) is a software development process that helps developers build more secure software and address security compliance requirements while reducing development cost.
Phrase One: Training
Practice #1: Core Security Training
Stay informed about security basics and recent trends in security and privacy.
Recommended Training
Phrase Two: Requirements
Practice #2: Establish Security and Privacy Requirements
Identify key milestones and deliverables
Assign security experts
Define minimum security and privacy criteria for an application
Deploying a security vulnerability/work item tracking system
Practice #3: Create Quality Gates/Bug Bars
Define minimum acceptable levels of security and privacy quality
Set a meaningful bug bar (i.e., severity thresholds of security vulnerabilities)
Practice #4: Perform Security and Privacy Risk Assessments
Examine software design based on costs and regulatory requirements
Identify need for threat modeling and security design reviews
Phase Three: Design
Practice #5: Establish Design Requirements
Address security and privacy concerns early to minimize the risk of schedule disruptions and reduce a project's expense.
Validate all design specifications against a functional specification
Practice #6: Perform Attack Surface Analysis/Reduction
Thoroughly analyze overall attack surface
disable or restrict access to system services
apply the principle of least privilege
Employing layered defenses
Practice #7: Use Threat Modeling
Identify need for threat modeling and security design reviews
Apply a structured approach to threat scenarios to identify security vulnerabilities, determine risks from those threats, and establish appropriate mitigations.
Phase Five: Implementation
Practice #8: Use Approved Tools
Publish a list of approved tools and associated security checks
Keep the list regularly updated
Practice #9: Deprecate Unsafe Functions
Analyze all project functions and APIs to ban unsafe ones
Use newer compilers or code scanning tools to check code for functions on the banned list
Replace the unsafe functions with safer alternatives
Practice #10: Perform Static Analysis
Analyze the source code prior to compilation to ensure that secure coding policies are being followed
Phase Seven: Verification
Practice #11: Perform Dynamic Analysis
Perform run-time verification of the software
Check functionality using tools that monitor application behavior for memory corruption, user privilege issues, and other critical security problems.
Practice #12: Perform Fuzz Testing
Induce program failure by deliberately introducing malformed or random data to the application
Practice #13: Conduct Attack Surface Review
Review attack surface upon code completion
Ensure that any new attack vectors created as a result of the changes have been reviewed and mitigated including threat models
Phase Six: Release
Practice #14: Create an Incident Response Plan
Prepare an Incident Response Plan to address new threats that can emerge over time
identify appropriate security emergency contacts
establish security servicing plans for code inherited from other groups within the organization and for licensed third-party code
Practice #15: Conduct Final Security Review
Review all security activities that were performed to ensure software release readiness.
Eexamine threat models, tools outputs and performance against the quality gates and bug bars defined during the Requirements Phase
Practice #16: Certify Release and Archive
Certify software prior to a release to ensure security and privacy requirements were met
Archive all specifications, source code, binaries, private symbols, threat models, documentation, emergency response plans, and license and servicing terms for any third-party software.
Phase Seven: Response
Practice #17: Execute Incident Response Plan
Implement the Incident Response Plan instituted in the Release phase
Deliver security updates and authoritative security guidance