Embed Size (px)
DESCRIPTION
Secure software development compliance requirements are becoming increasingly commonplace in enterprise software development contracts. Software assurance professional Mike Boberski discusses his recommendations for getting started working on both technical and process-related secure software development compliance requirements using the OWASP Top Ten and OpenSAMM as examples. Agile and iterative software development methodologies in particular are generally seen as being at odds with building security into enterprise applications during development. However, by looking at and working the problem from certain different angles, it turns out that secure software development compliance requirements can in fact be approached by developers in a familiar manner in order to achieve and maintain compliance.
Citation preview
Achieving (and Maintaining) Compliance With Secure Software Development
Compliance Requirements
(ISC)² SecureSDLCMay 17, 2012
• Thank you for attending this presentation.• My name is Mike, I’m a software assurance
professional.• This enterprise software developer-focused
presentation is about working on secure software development compliance requirements.
Welcome!
A little bit about software security
• What “software security” means, in practice:
What are software security requirements?
• Software security requirements:
• Software security compliance requirements:
Technical requirements,Process requirements
Things you owe• Not things you hope or
assume got done or exist
“Things you owe”
• Software security requirements can usually be sorted into three categories:1. Source code2. Documentation (of secure software
development-related activities)3. Organization responsibility (for security-related
infrastructure services)
“Things you owe” continued
• Usually software security requirements have severities or penalties associated with not meeting them:– E.g., severities: high/medium/low– E.g., penalties: monetary penalties
Requirement examples
• Here is a notional example of a technical requirement:– “[The application shall not contain] Injection flaws,
such as SQL, OS, and LDAP injection, [...].” (OWASP Top Ten 2010, A1-Injection)
• Here is a notional example of a process requirement:– “[The application lifescycle shall] Establish release
gates for code review.” (OWASP OpenSAMM, CR3B)
What compliance means
• Achieving and maintaining software security compliance must necessarily be owned by software development teams (i.e. not by information assurance or information security teams).
Take compliance seriously
• Impacts of not taking compliance seriously are not limited to your application’s users.
• Impacts to your business or organization potentially may include:– Litigation resulting from e.g. breach of contract– Very costly repairs to your application– Very costly repairs to interconnected applications– Damage to your business or organization’s reputation,
perhaps mission, etc.
Getting started, carefully
• Looking at compliance from certain different perspectives can help make working on compliance easier. – “Easier” means getting requirements to the point
where they can be worked with the same ease and speed as requirements for business functions.
Achieving & maintaining compliance
Plan work
Track progress
Enforce secure coding guidelines
Report status
Track bugs
• Looking at compliance from three different perspectives, in particular:
Roles & responsbilities
• Tracking progress
• Enforcing secure coding guidelines
• Planning work
Owner: software development manager.
Owner: lead developer & security buddy
Owner: software development manager & security buddy
Tracking progress
• Getting started:1. Establish a compliance target2. Define compliance requirements based on
your compliance target3. Map requirements to things owed4. Perform an initial assessment to determine
your current compliance posture
• Example• The application shall not have OWASP Top Ten
vulnerabilities (these are the notional targeted technical requirements)• OWASP OpenSAMM maturity level 3 activities shall be
performed before the application is released (these are the notional targeted process requirements)
Establish target
Define requirements
Map requirements
Initial assessment
Tracking progress
Tracking progress
• Example:
T10.A1-Injection
SAMM.CR3B
Shall perform user input validation. Shall perform safe datbase queries.
Shall perform milestone code review before the application is released.
Establish target
Define requirements
Map requirements
Initial assessment
Establish target
Define requirements
Map requirements
Initial assessment
Tracking progress
• Example:Shall perform user input validation.Shall perform safe datbase queries.
Shall perform milestone code review before the application is released.
User input validation mechanismParameterized queries
Code review report
Establish target
Define requirements
Map requirements
Initial assessment
Tracking progress
• Example:
ID Severity Type Group Title Status Maturity Notes
T10.A1.1 High Source code
Input validation (users)
Validate all input
Potential items to address
50% ...
...
Thing owed (i.e. deliverable)
Spreadsheet
A few words about performing an initial assessment
• It is strongly advised to perform threat modeling to some extent and then review sampled code, in order to make sure that all security requirements and the overall architecture are considered.
• Example:– Decompose your system into components, analyze
each component for dependencies, then data flows, – Next establish boundaries and determine applicable
security controls based on your requirements.
Enforcing secure coding guidelines
• Getting started:1. Establish security controls2. Establish security control usage3. Use and retrofit security controls4. Repeat steps 1 – 3 as needed.
Enforcing secure coding guidelines
• Rules of thumb:– Don’t build your own controls!– Do work with your security buddy to ensure
security control mechanisms are implemented and work according to industry best practices, and meet your technical compliance requirements.
Establish security controls
Establish security control
usage
Use and retrofit security controls
Enforcing secure coding guidelines
• Example:Project Secure Coding Cheat Sheet
Safe database queries://TODO put description of SQL injection hereHere is an example of how to safely query the database://TODO put code snippet hereNotes://TODO usage notes, links, regular expressions to use to search for queries to review, etc.
...
Establish security controls
Establish security control
usage
Use and retrofit security controls
Wiki
Enforcing secure coding guidelines
• Rules of thumb:– Do publish secure coding guidelines to your
development wiki and provide training as needed– Don’t forget to plan retrofit development cycles for
new or changed security controls.– Do automate secure coding guidelines enforcement
to the extent practical.
Establish security controls
Establish security control
usage
Use and retrofit security controls
A little bit more on enforcing secure coding guidelines
• Enforcing secure coding guidelines doesn’t have to be expensive or hard.
• Example:
Planning work
• Getting started:1. Visualize2. Limit work3. Manage flow4. Set policies5. Improve iteratively
Visualize Limit work
Manage flow
Set policies
Improve iteratively
Planning work
• Example:Security Mechansim
To do In development
In verification Verified
Input validation mechanisms
Threat model document
Task board
Planning work
• Rules of thumb:– Do use your task board to make assignments for related
work– Do assign compliance security tasks using your existing bug
tracking system– Do perform incremental code reviews in between milestone
reviews to the extent practical
Visualize Limit work
Manage flow
Set policies
Improve iteratively
Planning work
• Rules of thumb:– Do what preparations you can as early as you can to avoid
“development team death” • (i.e. to avoid development cycles dedicated entirely to retrofitting new or
changed security controls).
– Work with your security buddy to incrementally role out new or changed controls as needed.
– Work with your security buddy to incrementally role out new or changed lifecycle activities.
Visualize Limit work
Manage flow
Set policies
Improve iteratively
Planning work
• Rules of thumb:– Do set policies around using security controls and enforcing
secure coding standards– Do set policies around timing, depth, and breadth of
verification activities– Do work with your security buddy to enhance and maintain
common security control library functionality
Visualize Limit work
Manage flow
Set policies
Improve iteratively
Where to go from here
• OWASP resources that you may find helpful:– OWASP Contract Annex– OWASP Top Ten– OWASP OpenSAMM– OWASP ESAPI– OWASP ASVS
