Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Standard view
Full view
of .
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
Secure Software Engineering (Dod)

Secure Software Engineering (Dod)

Ratings: (0)|Views: 100|Likes:
Published by VENUSHOPE
Secure Software Engineering (Dod)
Secure Software Engineering (Dod)

More info:

Published by: VENUSHOPE on Jan 18, 2011
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





 Secure SoftwareEngineering 
JULY 2005 Vol.8. No.2
Unclassified and Unlimited Distribution
The Challenge of Low Defect, SecureSoftware .................................................8Enhancing Customer Security ...............11Software Development Security ............15User Comment ........................................18
STN 8-2: Software Cost, Quality and Productivity Benchmarks2
Data & Analysis Center for Software (DACS)3
Developing Secure Software
Noopur Davis, Software Engineering Institute
Most security vulnerabilities resultfrom defects that are unintentionallyintroduced in the software during designand development. Therefore, to signifi-cantly reduce software vulnerabilities,the overall defect content of softwaremust be reduced. Defect reduction is apre-requisite for secure software devel-opment, but it is not enough. Securitymust also be deeply integrated into thefull software development life cycle(SDLC).
Most security vulnerabilities resultfrom defects that are unintentionallyintroduced in the software during designand development. Therefore, to signifi-cantly reduce software vulnerabilities,the overall defect content of softwaremust be reduced. Today’s commonsoftware engineering practices lead toa large number of defects in releasedsoftware. However, data from dozensof real-world software projects thathave systematically applied improvedsoftware development practices showone to two orders of magnitude reduc-tion in the number of defects in releasedsoftware. Applying these improvedpractices should lead to a similar reduc-tion in the defects that lead to vulner-abilities. Furthermore, by focusing onthe specific types of defects that lead tovulnerabilities, even greater reductionin vulnerabilities could be achieved.Organizations that have applied thesepractices have realized additional ben-efits of reduced cycle times and reducedsoftware development costs.Along with defect reduction, Secu-rity must be deeply integrated into thefull software development life cycle(SDLC). Security must be “built-in”while the product is being developed,and not just “bolted-on” after the fact. This article begins with a discussionof why defective software is seldomsecure, why defective software is notinevitable, and why reducing defects isless costly than responding to releasedvulnerabilities. Next, security through-out the software development life cyclewill be discussed. The paper closeswith a brief description of the SoftwareEngineering Institute’s (SEI’s) TeamSoftware Process
for Secure SoftwareDevelopment (TSP-Secure).
Defective Software Is Seldom Secure
SEI analysis of thousands of programs produced by thousands of developers show that even experienceddevelopers inject numerous defects asthey perform activities for understand-ing requirements, developing designs,coding, and testing software. One defectis injected for every 7 to 10 lines of newand changed code produced. Even if 99% of these defects are removed beforethe software is released, this leaves 1 to1.5 defects in every thousand lines of new and changed code produced. Soft-ware benchmark studies conducted onhundreds of software projects show thatthe average defect content of releasedsoftware varies from about 1 to 7 defectsper thousand lines of new and changedcode [Jones].According to preliminary analysisdone by the SEI’s CERT
group, over90% of software security vulnerabilitiesare caused by known software defecttypes. The analysis also showed thatmost software vulnerabilities arise fromcommon causes: the top ten causesaccount for about 75% of all vulner-abilities. Another analysis of forty-fivee-business applications showed that 70%of the security defects were software de-sign defects [Jacquith]. Some problemsare caused by sophisticated architecturaland design issues such as inadequateauthentication, invalid authorization,incorrect use of cryptography, failureto protect data, and failure to carefullypartition applications. But most arecaused by simple oversight that leadsto defect types such as declaration er-rors, logic errors, loop control errors,conditional expressions errors, failureto validate input, interface specificationerrors, configuration errors, and failureto understand basic security issues. Ina recent interview, Alan Paller, direc-tor of research at the SANS Institute,“expressed frustration with the fact thateverything on the [SANS Institute Top20 Internet Security] vulnerability listis a result of poor coding, testing andsloppy software engineering. These arenot ‘bleeding edge’ problems, as an in-nocent bystander might easily assume. Technical solutions exist to them all, butthey are simply not implemented.It is clear that software developmentpractices in common use today lead todefective software, that software defectsare a principal cause of software secu-rity vulnerabilities; therefore, to reducevulnerabilities the overall defect contentof software must be reduced.
Defective Software Is Not Inevitable
When presented with the securityproblems caused by defective software,a common response is that softwaredevelopment is inherently prone todefects, and that defective softwareis somehow inevitable. Many peoplebelieve that trying to figure out howto build better software is “a no-winsituation and just beating a dead horse”[Computer World]. However, datafrom dozens of real-world projects haveshown that when developers follow de-fined, measured, and quality controlledpractices, they produce products withvery few overall defects. A recent study
continues on page 4

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->