Transcript Software Engineering Lifecycle

Software Engineering Lifecycle
Authors: Jan G. Hogle, Susan Gerhart
This Document was Funded by the National Science Foundation
Federal Cyber Service Scholarship For Service Program:
Grant No. 0113627
Distributed July 2002
Embry-Riddle Aeronautical University • Prescott, Arizona • USA
Software Engineering Lifecycle. ©2002. Jan G. Hogle, Susan L. Gerhart. http://sfsecurity.pr.erau.edu
Software Engineering Lifecycle
Click on the diagram sections to view a slide
Software Engineering Lifecycle. ©2002. Jan G. Hogle, Susan L. Gerhart. http://sfsecurity.pr.erau.edu
Academia produces
students who:




Aren't tuned into the dangers of buffer overflows
Can't recognize a buffer overflow vulnerability when
they see it, so they make the mistake in coding
Are careless in their coding as well as inspection and
testing tasks
Are not made aware of buffer overflows by instructors
or textbooks
Software Engineering Lifecycle. ©2002. Jan G. Hogle, Susan L. Gerhart. http://sfsecurity.pr.erau.edu
Managers, Developers and QA
specialists iterate through cycles of
detailed design and coding but...





Employ poor coding and quality skills learned in school
Are often forced to use low-level languages like C
Use established programming techniques that are highly
error-prone
Fail to incorporate inspection and design techniques
known to prevent and discover buffer overflow
Run levels of code they can't control but which are
riddled with buffer overflows
Software Engineering Lifecycle. ©2002. Jan G. Hogle, Susan L. Gerhart. http://sfsecurity.pr.erau.edu
Buffer Overflow Vulnerabilities
not detected during development
and QA get into products



Vulnerable code slips through tests and inspection
New products expose buffer overflows in old code
from libraries and other vendors
Proper use of products to avoid buffer overflows
isn't known or documented
Software Engineering Lifecycle. ©2002. Jan G. Hogle, Susan L. Gerhart. http://sfsecurity.pr.erau.edu
An End User may find a
Buffer Overflow unintentionally
or may search for it


An ordinary user may observe unusual activity or
symptoms of buffer overflow
Security shops like Eeye and university groups
search for vulnerabilities by playing the role of
attackers on new and old products
Software Engineering Lifecycle. ©2002. Jan G. Hogle, Susan L. Gerhart. http://sfsecurity.pr.erau.edu
An Attacker finds a way
to force a buffer overflow
to meet their purposes



Attackers know common vulnerabilities of vendors
and their products
Attackers learn from the web and from each other
how to make buffer overflows occur
Attackers acquire ways to make buffer overflows
lead to hijacking a system or planting seeds for
future attacks
Software Engineering Lifecycle. ©2002. Jan G. Hogle, Susan L. Gerhart. http://sfsecurity.pr.erau.edu
When product users find a buffer
overflow and alert authorities,
a flurry of patching occurs:


An alert goes to the vendor and official sites like
cert.org
A confirmation, analysis, and explanation goes out
to vendors and users as an advisory
Software Engineering Lifecycle. ©2002. Jan G. Hogle, Susan L. Gerhart. http://sfsecurity.pr.erau.edu
The developer reaction team,
security shop, and authorities
issue a patch:


Users of the product must install the patch to protect
themselves and others
Vendors issue multiple patches, often daily
Software Engineering Lifecycle. ©2002. Jan G. Hogle, Susan L. Gerhart. http://sfsecurity.pr.erau.edu
The development organization
responds to the buffer overflow
vulnerability by:



Fixing the underlying code problem in its later
versions
Replacing patches with corrected code
Improving develpment processes and tools to avoid
similar buffer overflows
Software Engineering Lifecycle. ©2002. Jan G. Hogle, Susan L. Gerhart. http://sfsecurity.pr.erau.edu
There is no feedback to academia.
If there were, it could:




Make the pipeline of students more sensitive to buffer overflows
Improve education and training materials - books, exercises, tools
Encourage authors and instructors to raise the visibility of the
buffer overflow problem
Incorporate economic lessons of publicity and cost analyses from
journalists and industry analysts
Software Engineering Lifecycle. ©2002. Jan G. Hogle, Susan L. Gerhart. http://sfsecurity.pr.erau.edu
About this Project
This presentation is part of a larger package of materials on buffer overflow vulnerabilities, defenses, and
software practices. For more information, go to: http://nsfsecurity.pr.erau.edu
Also available are:
– Demonstrations of how buffer overflows occur (Java applets)
– PowerPoint lecture-style presentations on an introduction to buffer overflows, preventing buffer
overflows (for C programmers), and a case study of Code Red
– Checklists and Points to Remember for C Programmers
– An interactive module and quiz set with alternative paths for journalists/analysts and IT
managers as well as programmers and testers
– A scavenger hunt on implications of the buffer overflow vulnerability
Please complete a feedback form at http://nsfsecurity.pr.erau.edu/feedback.html to tell us how you used
this material and to offer suggestions for improvements.
Software Engineering Lifecycle. ©2002. Jan G. Hogle, Susan L. Gerhart. http://sfsecurity.pr.erau.edu