achieving and maintaining compliance with secure software development compliance requirements n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Achieving (and Maintaining) Compliance With Secure Software Development Compliance Requirements PowerPoint Presentation
Download Presentation
Achieving (and Maintaining) Compliance With Secure Software Development Compliance Requirements

Loading in 2 Seconds...

play fullscreen
1 / 30

Achieving (and Maintaining) Compliance With Secure Software Development Compliance Requirements - PowerPoint PPT Presentation


  • 242 Views
  • Uploaded on

Achieving (and Maintaining) Compliance With Secure Software Development Compliance Requirements. (ISC)² SecureSDLC May 17, 2012. Welcome!. Thank you for attending this presentation. My name is Mike, I’m a software assurance professional.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Achieving (and Maintaining) Compliance With Secure Software Development Compliance Requirements' - becky


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
achieving and maintaining compliance with secure software development compliance requirements

Achieving (and Maintaining) Compliance With Secure Software Development Compliance Requirements

(ISC)² SecureSDLC

May 17, 2012

welcome
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.
a little bit about software security
A little bit about software security
  • What “software security” means, in practice:
what are software security requirements
What are software security requirements?
  • Software security requirements:
  • Software security compliancerequirements:

Technical requirements,

Process requirements

Things you owe

  • Not things you hope or assume got done or exist
things you owe
“Things you owe”
  • Software security requirements can usually be sorted into three categories:
    • Source code
    • Documentation (of secure software development-relatedactivities)
    • Organizationresponsibility(for security-related infrastructure services)
things you owe continued
“Things you owe” continued
  • Usuallysoftware security requirements have severities or penalties associatedwith not meeting them:
    • E.g., severities: high/medium/low
    • E.g., penalties: monetary penalties
requirement examples
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
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
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
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
Achieving & maintaining compliance
  • Looking at compliance from three different perspectives, in particular:

Enforce secure coding guidelines

Track bugs

Track progress

Plan work

Report status

roles responsbilities
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
Tracking progress
  • Getting started:
    • Establish a compliance target
    • Define compliance requirements based on your compliance target
    • Map requirements to things owed
    • Perform an initial assessment to determine your current compliance posture
tracking progress1
Tracking progress
  • 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)
tracking progress2
Tracking progress
  • Example:

Shall perform user input validation.

Shall perform safe datbase queries.

Shall perform milestone code review before the application is released.

T10.A1-Injection

SAMM.CR3B

tracking progress3
Tracking progress
  • Example:

User input validation mechanism

Parameterized queries

Code review report

Shall perform user input validation.

Shall perform safe datbase queries.

Shall perform milestone code review before the application is released.

tracking progress4
Tracking progress
  • Example:

Thing owed (i.e. deliverable)

Spreadsheet

a few words about performing an initial assessment
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
Enforcing secure coding guidelines
  • Getting started:
    • Establish security controls
    • Establish security control usage
    • Use and retrofit security controls
    • Repeat steps 1 – 3 as needed.
enforcing secure coding guidelines1
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.
enforcing secure coding guidelines3
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.
a little bit more on enforcing secure coding guidelines
A little bit more on enforcing secure coding guidelines
  • Enforcing secure coding guidelines doesn’t have to be expensive or hard.
  • Example:
planning work
Planning work
  • Getting started:
    • Visualize
    • Limit work
    • Manage flow
    • Set policies
    • Improve iteratively
planning work1
Planning work
  • Example:

Task board

planning work2
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
planning work3
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.
planning work4
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
where to go from here
Where to go from here
  • OWASP resources that you may find helpful:
    • OWASP Contract Annex
    • OWASP Top Ten
    • OWASP OpenSAMM
    • OWASP ESAPI
    • OWASP ASVS
questions
Questions
  • About Me:
    • Mike Boberski
    • Booz Allen Software Assurance Team
    • boberski_michael@bah.com