Isc2 secure sdlc owasp achieving compliance v1.0 2012 05-04
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Isc2 secure sdlc owasp achieving compliance v1.0 2012 05-04

on

  • 905 views

Secure software development compliance requirements are becoming increasingly commonplace in enterprise software development contracts. Software assurance professional Mike Boberski discusses his ...

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.

Statistics

Views

Total Views
905
Views on SlideShare
905
Embed Views
0

Actions

Likes
0
Downloads
11
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Secure software development compliance requirements (i.e. software security requirements) are becoming increasingly commonplace in enterprise software development contracts. This presentation is about way to get 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.There is some time set aside for questions at the end.
  • a.k.a. software assurance
  • Examples of technical requirements – input validation. Examples of process requirements – perform milestone code reviews.If you are an enterprise software developer writing an application for which you have secure software development compliance requirements, you’re about to find out that those requirements are going to be very invasive, in terms of affecting your day-to-day software development activities. You’re not going to be able to hand this document off to your organization’s information assurance team for example. You are going to need to take ownership of the compliance requirements. While it’s true that some requirements for example having to do with the environment can be worked on by other teams, there are not enough that you should feel comfortable that if you otherwise do nothing you’ll automatically be good.
  • Positive vs. negative software securiyt requirementsPositive: do thisNegative: don’t be vulnerable to...Oftentimes compliance requirements are a mix of positive and negativeSee also OWASP ASVS.
  • The necessary preparations to achieve and maintain compliance with software security requirements are best thought of as software development (i.e. not information assurance or information security) activities.Compliance means code and documentation evidenceCompliance means providing evidence of the existence and goodness of controls and activities.Compliance means increased reporting requirementsSecurity issues in code need to be tracked and reported the customer the same as business issues. Compliance means planning and preparing, not reactingWork on compliance requirements can with some forethought be integrated into the way you are currently approaching software development.
  • Make requirements positiveE.g. translate requirements from e.g. “don’t be vulnerable to whatever” into “do this” given your specific development environment.Make requirements actionableDevelop instructions to e.g. “use this” and “here is how to do it” taking into account your specific solution stack.Make requirements quantifiable and measurableHelp establish better, more meaningful metrics that can be used to more effectively track progress and plan than “you have 5000 medium severity findings still open”
  • Tracking progress: You’ll need to manage and report work on compliance requirements.Figuring out your current compliance posture and reporting progress towards improving / maintianing it is job #1 when it comes to both achieving and maintaining software security requirements compliance.Planning work: You’ll need to prioritize and plan compliance work.Enforcing secure coding guidelines: You’ll need to establish solution stack and application-specific secure coding guidance.
  • Scurity-focused advisory developers a.k.a. “security buddies”.
  • Define requirements based on your target
  • Map requirements to things owed
  • Perform an initial assessment to determine your current compliance postureIn example:Severity: high/medium/lowType: source code/documentation/organization responsibilityGroup: thing owed (i.e. deliverable), e.g. security mechanism integrated into code, documented analysis, etc.Title: requirement titleStatus: feature integrated / in progress / potential items to address / not reviewed / not applicableMaturity: e.g. extent to which a mechanism has been integrated, at a glanceNotes: references or descriptions to analysis, coding standards, etc.Other columns: e.g. mapping to bug tracking IDs, releases, etc.
  • More on “positive” threat modeling: Whiteboard-like diagrams can be used graphically represent a system without using any special notation (such as UML). The basic method is to decompose the system into parts and figure out what security controls are needed in what locations within the system.
  • Best practices examples:implemented on the server side, uses a single implementation, operates deny by default, etc.The goal of standardizing security controls is to make sure that the controls developers will be using are of known goodness, in terms of their suitability for meeting specific compliance requirements. Not all security controls are made equal in terms of the specific security checks that they perform (e.g. access control checks) and the specific security effects that they result in (e.g. generating audit records).
  • The goal of standardizing how your developers should use security controls that you’ve added to your solution stack is to enable your developers to be able to use the extra controls with the same speed and ease during a development cycle as non security-related controls. Additional benefits include making verification of the use of controls easier, the usage guidance in effect becomes an informal contract between developers and code reviewers.
  • Use and retrofit security controlsThe goal of starting to use security controls as soon as they are added to your solution stack is to minimize rework and retrofits, while at the same time getting immediate benefits from the new controls when writing new or updated code during the next development cycle. It is hugely important to emphasize though that either new security controls or changed usage of security controls will mean that retrofit development cycles will be required.An example of “practical” is developing Checkstylecheckin scripts using regular expressions that check for use of your common security control library API, compared to e.g. licensing static analysis tools for all the developers on a team. There is no licensing fee associated with the former, is the point.
  • Goal is helping the development manager prioritize and plan compliance work by establishing and executing compliance strategy tactics for both technical and process-related requirements.
  • Visualizing compliance tasks facilitates prioritizing and planning compliance work. Compliance strategy tactics are developed as activities are defined and as requirements are grouped; task boards make war gaming easy.Use a task board:Columns that correspond to lifecycle phases, including security / compliance activity-specific phases (i.e., security verification)Swim lanes that correspond to security controls and lifecycle activities / deliverablesNotes with compliance requirement identifier and corresponding issue tracking identifierOther task board features as commonly used during software development (different colored notes to indicate blocked status, etc.)
  • The goal of limiting work is to try to guard against swamping your developers with security-specific work, more specifically, to guard against development cycles where nothing else is done but adding or swapping out security controls. Note that there will be some instances where this will be very hard to do, in particular when application-wide reviews or retrofits are needed
  • The goal of managing the workflow in short is to work on compliance activities in an agile way, to get the compliance work to the point where e.g. work on a security mechanism can be managed in the same way as work on a business function. A heads-up when making plans to introduce for example code review tools: don’t forget about license costs for tools – code review tools are expensive, besides requiring specialized expertise to use.
  • The goal of setting policies and making adjustments over time is to keep the peace and to be agile not just when it comes to business functions, but security work as well. A key difference in terms of being agile when it comes to security though is to understand that the drivers for changes and improvements won’t be coming from your customer, rather from your security buddy, and from the results of e.g. application-wide code reviews which look for things that are not perhaps otherwise explicitly required.

Isc2 secure sdlc owasp achieving compliance v1.0 2012 05-04 Presentation Transcript

  • 1. Achieving (and Maintaining) Compliance With Secure Software Development Compliance Requirements (ISC)² SecureSDLC May 17, 2012
  • 2. Welcome!• 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.
  • 3. A little bit about software security• What “software security” means, in practice:
  • 4. What are software security requirements?• Software security Technical requirements, requirements: Process requirements• Software security Things you owe compliance • Not things you hope or assume got done or exist requirements:
  • 5. “Things you owe”• Software security requirements can usually be sorted into three categories: 1. Source code 2. Documentation (of secure software development-related activities) 3. Organization responsibility (for security-related infrastructure services)
  • 6. “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
  • 7. 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)
  • 8. 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).
  • 9. 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.
  • 10. 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.
  • 11. Achieving & maintaining compliance• Looking at compliance from three different perspectives, in particular: Enforce secure coding guidelines Track Plan Track Report bugs work progress status
  • 12. Roles & responsbilities Owner: software development• Tracking progress manager.• Enforcing secure Owner: lead developer & coding guidelines security buddy• Planning work Owner: software development manager & security buddy
  • 13. Tracking progress• Getting started: 1. Establish a compliance target 2. Define compliance requirements based on your compliance target 3. Map requirements to things owed 4. Perform an initial assessment to determine your current compliance posture
  • 14. Tracking progress Establish Define Map Initial target requirements requirements assessment• 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)
  • 15. Tracking progress Establish Define Map Initial target requirements requirements assessment• Example: T10.A1-Injection Shall perform user input validation. Shall perform safe datbase queries. Shall perform milestone code review SAMM.CR3B before the application is released.
  • 16. Tracking progress Establish Define Map Initial target requirements requirements assessment• Example:Shall perform user input validation. User input validation mechanismShall perform safe datbase queries. Parameterized queriesShall perform milestone code reviewbefore the application is released. Code review report
  • 17. Tracking progress Establish Define Map Initial target requirements requirements assessment • Example: Thing owed (i.e. deliverable)ID Severity Type Group Title Status Maturity NotesT10.A1.1 High Source Input Validate Potential 50% ... code validation all input items to (users) address...
  • 18. 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.
  • 19. Enforcing secure coding guidelines• Getting started: 1. Establish security controls 2. Establish security control usage 3. Use and retrofit security controls 4. Repeat steps 1 – 3 as needed.
  • 20. Enforcing secure coding guidelines Establish Establish Use and retrofit security security control security controls usage controls• 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.
  • 21. Enforcing secure coding guidelines Establish Establish Use and retrofit security security control security controls usage controls• Example: Project Secure Coding Cheat Sheet Safe database queries: //TODO put description of SQL injection here Here is an example of how to safely query the database: //TODO put code snippet here Notes: //TODO usage notes, links, regular expressions to use to search for queries to review, etc. ...
  • 22. Enforcing secure coding guidelines Establish Establish Use and retrofit security security control security controls usage controls• 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.
  • 23. A little bit more on enforcing secure coding guidelines• Enforcing secure coding guidelines doesn’t have to be expensive or hard.• Example:
  • 24. Planning work• Getting started: 1. Visualize 2. Limit work 3. Manage flow 4. Set policies 5. Improve iteratively
  • 25. Planning work Limit Manage Set Improve Visualize work flow policies iteratively• Example:Security To do In In verification VerifiedMechansim developmentInputvalidationmechanismsThreat modeldocument
  • 26. Planning work Limit Manage Set Improve Visualize work flow policies iteratively• 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
  • 27. Planning work Limit Manage Set Improve Visualize work flow policies iteratively• 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.
  • 28. Planning work Limit Manage Set Improve Visualize work flow policies iteratively• 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
  • 29. Where to go from here• OWASP resources that you may find helpful: – OWASP Contract Annex – OWASP Top Ten – OWASP OpenSAMM – OWASP ESAPI – OWASP ASVS
  • 30. Questions• About Me: – Mike Boberski – Booz Allen Software Assurance Team – boberski_michael@bah.com