Successfully reported this slideshow.

Software Security The Bigger Picture

545 views

Published on

  • Be the first to comment

  • Be the first to like this

Software Security The Bigger Picture

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

×