Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the Creative Commons Attribution-ShareAlike 2.5 License. To view this license, visit The OWASP Foundation 6 th OWASP AppSec Conference Milan - May Software Security The Bigger Picture Rudolph Araujo Senior Principal, Foundstone Professional Services

6 th OWASP AppSec Conference – Milan – May 2007 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

6 th OWASP AppSec Conference – Milan – May 2007 Agenda  State of Software Security  Defining a Security Frame  Security Requirements Engineering  Security Acceptance Testing  Security Knowledge Management  Parting Thoughts  Q&A 3

6 th OWASP AppSec Conference – Milan – May 2007 STATE OF SOFTWARE SECURITY 4

6 th OWASP AppSec Conference – Milan – May 2007 The Stages of Software Security

6 th OWASP AppSec Conference – Milan – May 2007 Innocence  No formal security requirements  Security flaws are identified through:  Penetration Testing  Security Incidents

6 th OWASP AppSec Conference – Milan – May 2007 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

6 th OWASP AppSec Conference – Milan – May 2007 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

6 th OWASP AppSec Conference – Milan – May 2007 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

6 th OWASP AppSec Conference – Milan – May 2007 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

6 th OWASP AppSec Conference – Milan – May 2007 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

6 th OWASP AppSec Conference – Milan – May 2007 State of Software Security 12

6 th OWASP AppSec Conference – Milan – May 2007 DEFINING A SECURITY FRAME 13

6 th OWASP AppSec Conference – Milan – May 2007 Defining a Security Frame 14

6 th OWASP AppSec Conference – Milan – May 2007 Foundstone Software Security Frame  Configuration Management  Data Protection in Storage & Transit  Authentication  Authorization  User & Session Management  Data Validation  Error Handling & Exception Management  Logging & Auditing 15

6 th OWASP AppSec Conference – Milan – May 2007 SECURITY REQUIREMENTS ENGINEERING 16

6 th OWASP AppSec Conference – Milan – May 2007 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? 17

6 th OWASP AppSec Conference – Milan – May 2007 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  … 18

6 th OWASP AppSec Conference – Milan – May 2007 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  … 19

6 th OWASP AppSec Conference – Milan – May 2007 Requirements Pre Process 1.Work with legal / internal audit to identify drivers  Define an organizational superset 2.Convert each driver to a superset of technical requirements  Use your security frame as a guide  Eliminate duplicates 1.Build application vs. driver matrix 20

6 th OWASP AppSec Conference – Milan – May 2007 Requirements Process 1.Based on features / data elements determine which drivers apply  Leverage data classification / privacy policy 2.“Copy-paste” requirement(s) from superset defined earlier  Consider building a thin “requirements” application  Perhaps an Excel template? 21

6 th OWASP AppSec Conference – Milan – May 2007 SECURITY ACCEPTANCE TESTING 22

6 th OWASP AppSec Conference – Milan – May 2007 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 … 23

6 th OWASP AppSec Conference – Milan – May 2007 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 24

6 th OWASP AppSec Conference – Milan – May 2007 Unit Testing  Data validation  Fuzzing  SQL injection  Buffer overflows  Cross site scripting  Authorization  Method level permissions 25

6 th OWASP AppSec Conference – Milan – May 2007 Build Verification Testing  Integrate source code analysis  Simple regular expression based scans  Commercial tools  Build custom rule sets  Define exit criteria for build acceptance 26

6 th OWASP AppSec Conference – Milan – May 2007 QA Testing IIntegrate with existing bug tracking systems NNo high / medium / low! GGo with Severity / Priority ratings FFollow the existing process TTreat security bugs no different than other bugs WWell maybe a little different ;) 27

6 th OWASP AppSec Conference – Milan – May 2007 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 28

6 th OWASP AppSec Conference – Milan – May 2007 SECURITY KNOWLEDGE MANAGEMENT 29

6 th OWASP AppSec Conference – Milan – May 2007 Why Knowledge Management?  Well, learn from other’s mistakes!  Within your team / organization / community  Guidance on an ongoing basis 30

6 th OWASP AppSec Conference – Milan – May 2007 Software Security Portal  Document repository  Threat modeling artifact repository  Leverage commonality across similar applications  Metrics reporting 31

6 th OWASP AppSec Conference – Milan – May 2007 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 32

6 th OWASP AppSec Conference – Milan – May 2007 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! 33

6 th OWASP AppSec Conference – Milan – May 2007 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 34

6 th OWASP AppSec Conference – Milan – May 2007 PARTING THOUGHTS 35

6 th OWASP AppSec Conference – Milan – May 2007 It takes a village to raise software security! 36

6 th OWASP AppSec Conference – Milan – May 2007