1. A Scientific Approach to Software Security Dennis Fisher May 15, 2012 The Kaspersky Lab Security News Service

2. Software security pre-history

3. In the beginning, things were OK Defenders had the advantage Computers were rare, code was impenetrable Few people understood how to break software Computers were isolated Not accessible to outside attackers Physically secured Software was written by professionals Purpose-built applications No Web to worry about Software security pre-history

5. Source: Wikipedia

6. Bugs were kind of cute Seen as problems to be solved Bugs were studied as oddities, artifacts of the development process Defects rather than vulnerabilities Developers learned actual lessons from mistakes Information was shared Mostly unreachable by attackers Needed local access, intimate knowledge of the software Writing exploits was really hard Software security pre-history

7. And then this happened

8. Microsoft ruled the world Windows was ubiquitous Software monoculture that gave attackers an advantage Write once, hit many Vulnerabilities abounded Buffer overflows Memory corruption Security was an afterthought at best The game changed completely

10. The Trustworthy Computing era Focus on security over features Development of SDLC process Becomes a model for the industry and financial services companies Pain begets change

11. Microsoft’s SDLC Source: Microsoft

12. The emergence of BSIMM Comprehensive maturity model for software security programs Developed through study of dozens of organizations’ programs Describes 109 discrete activities across four domains Software security matures

13. 13 Intel + eleven unnamed firms

14. A framework for success Source: BSIMM

15. Case study: Adobe

16. Adobe was the new Microsoft Huge installed base of vulnerable users Old development practices with no rigorous approach to threat modeling or code quality Common set of vulnerabilities and weaknesses across applications Starting from zero (day)

17. Pain begets change FIGURE. Adobe Reader exploits by month in 2008, indexed to the monthly average for 2H08 July through December 2008

18. The importance of the SDL Reader 9 was developed without the current SDL or security as a priority Reader 9 was the target of a high volume of malware Helped spur a company wide change in practices and priorities Reader 9 vs. Reader X

19. The importance of the SDL Adobe implemented a rigorous software security program beginning in early 2009 Included training and threat modeling and lessons learned from Microsoft’s SDL experience Reader X developed with SDL in place, implementation of a sandbox and anti-exploit technologies Reader 9 vs. Reader X

20. Results Reader 9 had nine publicly disclosed zero day vulnerabilities Reader X has NO zero days to date Attackers have largely moved on to other products as main targets Reader 9 vs. Reader X

21. Better software through science Software security is gradually becoming a priority Mature, formalized programs are having a measurable effect on defects and attacks Internal development organizations can watch and learn from successes of vendors Conclusions

22. Questions? dennis@threatpost.com