Your SlideShare is downloading. ×
  • Like
Software Security The Bigger Picture
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Software Security The Bigger Picture

  • 376 views
Published

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
376
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
29
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • You then describe what you have done. You have to interlace it with stories. At CMU you built a web server, heaven help us if anyone uses t. You didn’t know any better etc. Describe life as a developer in India. Get personal.
  • The next slide shows the kinds of issues that are identified in companies at this stage through external pen testing
  • Remember, we’re addressing the symptoms and not the disease! We’re attacking applications as we find that they are broken in a reactive approach instead of a proactive approach
  • We’re beginning to address the economics of software security by pushing the identification of bugs and flaws earlier in the lifecycle of a piece of software. However, we may still be doing these activities late in the SDLC. We are still looking at applications individually and addressing the symptoms and not the disease. The next slide shows the difference it what can be found by pen testing vs. code reviews
  • Now, we’ve come to the realization that we need to begin addressing the disease itself and the organization begins making tentative steps toward a software security program.
  • Now, we’ve come to the realization that we need to begin addressing the disease itself and the organization begins making tentative steps toward a software security program.

Transcript

  • 1. Software Security The Bigger Picture Rudolph Araujo Senior Principal, Foundstone Professional Services [email_address] www.codesecurely.org
  • 2. Who am I?
    • Developer for over 10 years
      • Foundstone / McAfee
      • Morgan Stanley
      • BindView
    • Microsoft Visual Developer Security - MVP
    • Masters from Carnegie Mellon University
      • Computer Science / Information Security
    • Areas of expertise: C / C++ / C#, Windows / Unix
  • 3. Agenda
    • State of Software Security
    • Defining a Security Frame
    • Security Requirements Engineering
    • Security Acceptance Testing
    • Security Knowledge Management
    • Parting Thoughts
    • Q&A
  • 4. STATE OF SOFTWARE SECURITY
  • 5. The Stages of Software Security
  • 6. Innocence
    • No formal security requirements
    • Security flaws are identified through:
      • Penetration Testing
      • Security Incidents
  • 7. Application Security Awareness
    • Penetrate & Patch
      • Bug fixing late in the lifecycle is extremely expensive and time consuming
      • Reactive approach
    • Application Security
      • Identifies and corrects instances of security issues in applications
      • Tactical, near-term approach to securing an application
  • 8. Application Security Enlightenment
    • Push security earlier in the lifecycle
    • Threat Model the Application
      • Structured approach for identifying, evaluating and mitigating risks to system security
      • Models the system as an attacker would see it
        • … with the advantage of knowing the internal s
    • Code Review the Application
  • 9. Software Security Awareness
    • Application Security is expensive and time consuming
      • Vulnerabilities are still found year after year
    • Application Security Enlightenment is false enlightenment
      • Addressing the symptoms and not the disease
  • 10. Software Security Awareness
    • Root cause analysis determines the sources of insecure software
        • People
          • Lack of security knowledge and motivation
        • Process
          • Reactive approach to security issues
        • Technology
          • Lack of appropriate tools
  • 11. Software Security Enlightenment
    • Create a holistic Software Security program
      • Integrate security into all phases of the SDLC
        • High-ROI activities first
      • Not all software security programs are identical
        • Build a program to meet your needs
  • 12. State of Software Security
  • 13. DEFINING A SECURITY FRAME
  • 14. Defining a Security Frame
  • 15. Foundstone Software Security Frame
    • Configuration Management
    • Data Protection in Storage & Transit
    • Authentication
    • Authorization
    • User & Session Management
    • Data Validation
    • Error Handling & Exception Management
    • Logging & Auditing
  • 16. SECURITY REQUIREMENTS ENGINEERING
  • 17. Security Requirements Engineering
    • Lack of / bad software requirements leads to bad software
      • Lack of security requirements leads to insecure software
      • No benchmarks for QA to perform testing
      • No traceability!
    • Problem: Requirements are often written by business analysts or product management that may not be technical
      • AES-256-CBC – WTF is that? 
  • 18. Organizational Drivers
    • Regulatory compliance
      • SOX 404
      • HIPAA
      • PCI
      • GLBA
      • CA SB1386 / State Notification Laws
      • BASEL II
      • FISMA
      • EU Data Protection Directive
    • Industry regulations and standards
      • FFIEC
      • OWASP Top 10 / Guides
      • SCADA Security
      • OASIS
      • ISO 17799
  • 19. Organizational Drivers
    • Company policies / documents
      • Privacy policy
      • Coding standards
      • Patching policy
      • Data classification policy
      • Infosec policies
      • Acceptable use policies
      • Export control
      • Results from previous security audits
    • Security features
      • Authentication
      • Authorization
      • Administrative interfaces
      • User management
  • 20. Requirements Pre Process
    • Work with legal / internal audit to identify drivers
      • Define an organizational superset
    • Convert each driver to a superset of technical requirements
      • Use your security frame as a guide
      • Eliminate duplicates
    • Build application vs. driver matrix
  • 21. Requirements Process
    • Based on features / data elements determine which drivers apply
      • Leverage data classification / privacy policy
    • “ Copy-paste” requirement(s) from superset defined earlier
    • Consider building a thin “requirements” application
      • Perhaps an Excel template?
  • 22. SECURITY ACCEPTANCE TESTING
  • 23. Security Acceptance Testing
    • QA folks test software!
      • How many test for security?
      • Plus unit tests, build verification tests, test driven development …
    • Penetration testing can often be too late
    • But …
  • 24. Security Acceptance Testing
    • The Mindset 
      • Training and exposure
      • Consider Foundstone Hacme* / WebGoat
    • Testers need to help define the threat model
      • Use threat model to prioritize and scope effort
    • Define attack libraries of test cases
      • Based on vulnerabilities and the security frame
      • Based on phase of testing
    • Choose which ones to apply to this rev
  • 25. Unit Testing
    • Data validation
      • Fuzzing
      • SQL injection
      • Buffer overflows
      • Cross site scripting
    • Authorization
      • Method level permissions
  • 26. Build Verification Testing
    • Integrate source code analysis
      • Simple regular expression based scans
      • Commercial tools
    • Build custom rule sets
    • Define exit criteria for build acceptance
  • 27. QA Testing
    • Integrate with existing bug tracking systems
      • No high / medium / low!
      • Go with Severity / Priority ratings
    • Follow the existing process
      • Treat security bugs no different than other bugs
        • Well maybe a little different ;)
  • 28. QA Testing
    • Tag security bugs
      • Maybe used to ensure developer assigned to fix is “security conscious”
    • Classify by security frame
      • Allows root cause and other statistical analyses
    • Classify by nature
      • Bugs
      • Flaws
      • Commendations
      • Informational
    • Mark for regression testing
  • 29. SECURITY KNOWLEDGE MANAGEMENT
  • 30. Why Knowledge Management?
    • Well, learn from other’s mistakes!
      • Within your team / organization / community
    • Guidance on an ongoing basis
  • 31. Software Security Portal
    • Document repository
    • Threat modeling artifact repository
      • Leverage commonality across similar applications
    • Metrics reporting
  • 32. Software Security Wiki
    • Security architectures and infrastructure components
    • Reviewed and tested code snippets for commonly used tasks
    • Links to additional information about software security on the Internet
    • Lessons learned from previous security issues identified in applications
  • 33. Security Knowledge Management
    • Benefits
    • Wide distribution of best practices
    • Prevention of repetition of similar issues
    • Improved productivity
    • Overall better software quality
    • Gotchas!
    • Don’t disclose too soon – even if it is internal only!
    • Anonymize the examples and code if necessary
    • Share not only the issue but how the issue was discovered and fixed
      • Root cause analysis
      • Tweaking the SSDLC
    • Make sure the fix is bug free!
  • 34. Special Case: Third Party Components
    • Open Source / COTS
      • OpenSSL
      • zlib
    • Who is tracking updates / patches?
      • The average developer???
      • Which of our applications are affected?
      • What’s the plan to rollout patches?
    • Back again to matrices!
      • Role: Software Security Architect
        • Subscribe to mailing lists
          • Patch reliability
        • Notify application owners
  • 35. PARTING THOUGHTS
  • 36. It takes a village to raise software security!
  • 37.