Take a look at the new version of this page: [ beta version ]. Tell us what you think.

ABSTRACT

Security is often an afterthought when developing software, and is often bolted on late in development or even during deployment or maintenance, through activities such as penetration testing, add-on security software and penetrate-and patch maintenance. We believe that security needs to be built in to the software from the beginning, and that security activities need to take place throughout the software lifecycle. Accomplishing this effectively and efficiently requires structured approach combining a detailed understanding on what causes vulnerabilities, and how specific activities combine to prevent them.In this paper we introduce key elements of the approach we are taking: vulnerability cause graphs, which encode information about vulnerability causes, and security activity graphs, which encode information about security activities. We discuss how these can be applied to design software development processes (or changes to processes) that eliminate software vulnerabilities.

REFERENCES

• 1: Kent Beck, Embracing Change with Extreme Programming, Computer, v.32 n.10, p.70-77, October 1999 [doi>10.1109/2.796139]
• 2: Kent Beck, Extreme programming explained: embrace change, Addison-Wesley Longman Publishing Co., Inc., Boston, MA, 1999
• 3: Greg Hoglund , Gary McGraw, Exploiting Software: How to Break Code, Pearson Higher Education, 2004
• 4: Michael Howard, Building More Secure Software with Improved Development Processes, IEEE Security and Privacy, v.2 n.6, p.63-65, November 2004 [doi>10.1109/MSP.2004.95]
• 5: Michael Howard , David E. Leblanc, Writing Secure Code, Microsoft Press, Redmond, WA, 2002
• 6: Ivar Jacobson , Grady Booch , James Rumbaugh, The unified software development process, Addison-Wesley Longman Publishing Co., Inc., Boston, MA, 1999
• 7: Jack Koziol , David Litchfield , Dave Aitel , Chris Anley , Sinan Eren , Neel Mehta , Riley Hassell, The Shellcoder's Handbook: Discovering and Exploiting Security Holes, John Wiley & Sons, 2004
• 8: Carl E. Landwehr , Alan R. Bull , John P. McDermott , William S. Choi, A taxonomy of computer program security flaws, ACM Computing Surveys (CSUR), v.26 n.3, p.211-254, Sept. 1994 [doi>10.1145/185403.185412]
• 9: W. S. Lee, D. L. Grosh, F. A. Tillman, and C. H. Lie. Fault tree analysis, methods and applications - a review. IEEE Transactions on Reliability, R-34, August 1985.
• 10: Richard C. Linger, Cleanroom Process Model, IEEE Software, v.11 n.2, p.50-58, March 1994 [doi>10.1109/52.268956]
• 11: Steve Lipner, The Trustworthy Computing Security Development Lifecycle, Proceedings of the 20th Annual Computer Security Applications Conference (ACSAC'04), p.2-13, December 06-10, 2004 [doi>10.1109/CSAC.2004.41]
• 12: G. McGraw. Software security. Security & Privacy Magazine, 2(2):80--83, Mar-Apr 2004.
• 13: Steve R. Palmer , Mac Felsing, A Practical Guide to Feature-Driven Development, Pearson Education, 2001
• 14: S. T. Redwine and N. Davis. Task force for improving security across the development lifecycle task force report, Appendix B: Processes to produce secure software, 2004.
• 15: SSE-CMM website. http://www.sse-cmm.org/ (accessed June 2005).
• 16: J. Viega. The CLASP application security process, 2005. http://www.securesoftware.com/ (accessed June 2005).
• 17: J. Viega and G. McGraw. Building Secure Software. Addison-Wesley, 2002.

INDEX TERMS

Primary Classification:
  D. Software
  D.2 SOFTWARE ENGINEERING
      D.2.0 General

General Terms:
Security

Keywords:
software development process, software security, vulnerability analysis