Embed Size (px)
Citation preview
A Scientific Approach to Software SecurityDennis FisherMay 15, 2012
The Kaspersky Lab Security News Service
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
Software security pre-history
Software security pre-history
Software security pre-history
Source: Wikipedia
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
And then this happened
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
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
Microsoft’s SDLC
Source: Microsoft
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
Intel
+ elevenunnamedfirms
A framework for success
Source: BSIMM
Case study: Adobe
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)
Pain begets change
FIGURE . Adobe Reader exploits by month in 2008, indexed to the monthly average for 2H08
July through December 2008
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
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
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
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
