A Scientific Approach to Software Security Dennis Fisher May 15, 2012

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

2. Software security pre-history

3. Software security pre-history • 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

4. Software security pre-history

5. Software security pre-history Source: Wikipedia

6. Software security pre-history • 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

7. And then this happened

8. The game changed completely • 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

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

11. Microsoft’s SDLC Source: Microsoft

12. Software security matures 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

13. + eleven unnamed firms Intel

14. A framework for success Source: BSIMM

15. Case study: Adobe

16. Starting from zero (day) 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

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

18. Reader 9 vs. Reader X 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

19. Reader 9 vs. Reader X 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

20. Reader 9 vs. Reader X 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

21. Conclusions 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

22. Questions? dennis@threatpost.com