1 / 30

Empirical Software Security Assurance

Empirical Software Security Assurance. David Harper EMEA Services Director Fortify Software. Outline. The Case for Application Security Current Application Security Initiatives Securing in-house developments is only part of the solution. The Case for Application Security.

hao
Download Presentation

Empirical Software Security Assurance

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Empirical Software Security Assurance David Harper EMEA Services Director Fortify Software

  2. Outline • The Case for Application Security • Current Application Security Initiatives • Securing in-house developments is only part of the solution

  3. The Case for Application Security

  4. We Spend a Lot of Money on Information Security ($288B)1 • Encryption • Firewall • Anti Virus • Access Control • DB Security • End Point Security • Application Security • Data Loss Prevention 1Gartner Symposium/ITxpo, October 10, 2007

  5. We Would Like to See info-sec spending Business impact (# of incidents & exploits)

  6. We Are Faced With info-sec spending Business impact (# of incidents & exploits)

  7. Applications are the New Frontier • Applications are the New Frontier • Increasingly Accessible • Results are Profitable • Application Vulnerabilities are the New Entry Point • Easy to exploit • Opportunities are plentiful • Network-Based Security Solutions are ineffective for today’s threat • Pen Testing confirms the problem but does not provide a solution

  8. An Inconvenient Truth Two weeks of ethical hacking Business Logic Flaws Security Errors Code Flaws 10 Person-years of development

  9. Another Inconvenient Truth…

  10. Security in the Development Lifecycle

  11. Initiate Define Design Develop Test Implement Operate Strategy & Metrics Policy & Compliance Education & Guidance Threat Assessment Security Requirements Secure Architecture Design Review Code Review Security Testing Vulnerability Management Environment Hardening Operational Enablement Secure Development Life-Cycle • See www.opensamm.org Governance Construction Verification Deployment

  12. Current Application Security Initiatives

  13. SDL Adoption Curve • How can we learn from the early adopters?

  14. OWASP CLASP – Best Practices • Institute Awareness Program • Perform Application Assessments • Capture Security Requirements • Implement Secure Development Practices • Build Vulnerability Remediation Procedures • Define and Monitor Metrics • Publish Operational Security Guidelines

  15. Fortify SSA - Best Practices • Rapid identification and remediation of critical vulnerabilities • Don’t “forget to fix” or “boil the ocean” • Prevent introduction of new vulnerabilities • Integrate into existing SDLC with minimal process changes • Provide flexibility to integrate with new • Provide support for the developers • Training in the context of their own code base • Mentoring as required • Monitor and control • Automate gathering of statistics and publish • Enforcement via security gate • Continuous Improvement

  16. What has actually been implemented? • Building Security In Maturity Model • Benchmark based on 9 leading application security initiatives • Financial Services • ISV’s • Technology Vendors • Produced by security experts • Brian Chess • Gary McGraw • Sammy Migues • See www.bsi-mm.com for more details

  17. Key Findings - Roles • Executive Sponsorship Critical • Drive Cross-Functional Program • Accountability and Empowerment • Software Security Group (SSG) • Enforcement and Mentoring • Seed with Software Security Experts • Cross-train software people on security not the other way round • Size 1-2% of development group • Satellite Group • Project level security leads

  18. Key Findings - Governance • Build Support throughout the organization • SSG plays an evangelism role • Meet regulatory or internal needs with a unified approach • SSG creates a single policy • Promote culture of security throughout the organization • Provide awareness training • See yourself in the problem • Create/use material specific to company history

  19. Key Findings - Construction • Create proactive security guidance around security features • SSG provides reference implementation of security features • Understand the organization’s history • Collect and publish attack stories • Meet demand for security features • Create security standards

  20. Key Findings – Verification • Build internal capability on security architecture • Have SSG lead review efforts • Drive efficiency/consistency with code review automation • Use automated tools along with manual review • Use encapsulated attacker perspective • Integrate black box security tools into the QA process (including protocol fuzzing)

  21. Key Findings - Deployment • Demonstrate that your organization is vulnerable • Use external pen testers to find problems • Provide a solid host/network foundation for software • Ensure host/network security basics in place • Use operational data to change developer behaviour • Identify software bugs found in operational monitoring and feed back to development

  22. The Next Step

  23. The Four Pillars of Software • The software you build • The software you commission others to build • The software you buy (and the services you run) • The open source software used in your business

  24. Software Security Assurance (SSA) • A risk management strategy for all sources of software risk Assess Software for vulnerabilities Remediate Vulnerabilities found in software Prevent Software security vulnerabilities

  25. Outsourced Code • Approach • Leverage vendor’s SDL or implement an extended SDL • Key Pointers • Make SDL part of the contract, preferably before you sign • Agree roles and responsibilities for all SDL activities • Verification activities cannot be done by out-sourcer • Demand access to metrics during development to demonstrate • Assess – Remediate - Prevent

  26. COTS Code • Approach • Manage the “Supply Chain” • Implement Software Vendor Management • Key Pointers • Start with enterprise wide baseline audit of existing COTS apps and assess risk • Establish security standards for the approval of new COTS apps as part of the procurement process • Approach to addressing security vulnerabilities is key • Require access to security audit results

  27. Open Source Software • Approach • Select In-house, out-sourced or COTS strategy on a per application basis • Key Pointers • Kill the myth that Open Source Software is inherently secure • Maintain inventory of all Open Source components • Specify application security approach • Assign accountability • Contribute security fixes back to the community • Utilize Fortify's Open Review Project • http://opensource.fortify.com

  28. Software Security Assurance Measureable Reduction of Risk Preventing Introduction of New Risks Compliance with Application Security Mandates Risk in ExistingLegacy Applications Risk in Development Lifecycle Software Security Assurance

  29. Summary • The Case for Application Security • Network Security is not enough • Current Application Security Initiatives • Security embedded in the development life-cycle • Securing in-house developments is only part of the solution • Systematic prevention of all software risk

  30. Q&A David Harper dharper@fortify.com +44 118 983 2055

More Related