Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Software Security The Bigger Picture


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]
  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>
  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
  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>
  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>
  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>
  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>
  36. 36. It takes a village to raise software security!