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
Click on the diagram sections to view a slide
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

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

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

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

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

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

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

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


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

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.