© 2005 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new

collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE. (IEEE

Electronic Information Dissemination, section 8.1.10, pp. 44-45)

For more information, please see http://www.ieee.org/portal/pages/about/documentation/copyright/polilink.html

Adopting a Software Security Improvement Program

Dan Taylor and Gary McGraw

http://www.computer.org/security/

Vol. 3, No. 3May/June 2005

This material is presented to ensure timely dissemination of scholarly and technical work.Copyright and all rights therein are retained by authors or by other copyright holders. All persons

copying this information are expected to adhere to the terms and constraints invoked by eachauthor's copyright. In most cases, these works may not be reposted without the explicit

permission of the copyright holder.

Building Security InEditor: Gary McGraw, gem@cigital.com

other technical decisions only exac-erbate the problem. Regardless ofthese issues, leading software shops(including Microsoft) are workinghard to improve the way they buildsecurity into their products.

Software security initiatives haveproven beneficial for those organiza-tions that have implemented them.Such initiatives involve the adoptionand rollout of the kinds of best prac-tices described in previous install-ments of this department (see the“Software security best practices”sidebar). This article describes an ap-proach that works, with an emphasison business process engineering thatmight be unfamiliar to technicalpractitioners. By following somecommonsense steps, a software secu-rity improvement program has agreater chance of achieving its ulti-mate goal: software security thatmakes business sense.

The business climateMarket forces continue to pressure ITorganizations to become as efficientas possible to stay competitive. As acost-cutting maneuver during the re-cent economic downturn, manycompanies reorganized their IT orga-nizations and cut them to the bone.With no obvious cost cuts remaining,current efficiency efforts focus onimproving productivity. By harness-

ing this productivity momentum, ef-forts to formalize software processimprovement programs and achieveproductivity goals are flourishing.

Any organization can initiatechange, but few can sustain it overtime. So how can we define andmanage a change program in today’sdynamic business environment? Howcan we prepare for and take advan-tage of natural change? How can webuild a sustainable improvementplan that’s flexible enough to adaptover time?

The first priority is to align soft-ware development and operationalprocesses with strategic business ob-jectives. Technologists sometimesforget why they’re doing whatthey’re doing, yet most softwaretoday is created to service business.Those technologists who under-stand that security is a risk manage-ment process that unfolds over timewill have little trouble understandingthat business concerns are a funda-mental driver in balancing and refin-ing security best practices.

The software security best prac-tices we’ve covered are processagnostic and can thus be adopted re-gardless of an organization’s soft-ware development methodology.Because every organization is differ-ent, a software security improve-ment program involving these prac-

tices must be tailored to the givenbusiness and technical situation.

A well-defined roadmap lays outthe specifics of how best to deploysoftware security best practices givena particular organization’s approachto building software. It helps priori-tize change to assure that we first ad-dress only those program initiativesthat provide the highest value orquickest return. This type of roadmapshould follow five basic steps:

• Build a tailored plan. Recognizepotential dependencies betweenvarious initiatives and plan accord-ingly. Keep in mind how your or-ganization develops software anddetermine the best way to gradu-ally adjust what you’re doing tofold in security best practices.

• Roll out individual best-practice initia-tives carefully. Establish championsto drive and take ownership ofeach initiative, coaching and men-toring as needed. Run a successfulpilot in part of your company be-fore attempting to spread bestpractices far and wide.

• Train your people. Developers andarchitects remain blithely unawareof security and the critical rolethey play in it, making training andmentoring a necessity.

• Establish a metrics program. Apply abusiness-driven metrics scorecardto monitor progress and assess suc-cess. Metrics and measures—evenrelative metrics based on risk overtime or business metrics such asmaintenance budget—are criticalto making forward progress in anylarge organization.

• Establish and sustain a continuous im-provement capability. Create a situa-tion in which you can sustain con-

DAN TAYLOR

AND GARY

MCGRAW

Cigital

Adopting software security in a large organization is

a challenge that takes careful planning. Cultural

change of any kind is difficult in big companies,

and the potential minefields surrounding software

process, development tools, programming language, platform, and

Adopting a Software SecurityImprovement Program

88 PUBLISHED BY THE IEEE COMPUTER SOCIETY ■ 1540-7993/05/$20.00 © 2005 IEEE ■ IEEE SECURITY & PRIVACY

Building Security In

www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 89

tinuous improvement by measuringresults and periodically refocusingattention on the weakest aspects ofyour software security program.

The goal of the roadmap is to buildand deploy an approach focused onenabling organizational change.When applied well, it will providethe building blocks for creating andsustaining change over time.

Building blocks of changeEvery cultural change program re-quires buy-in from both manage-ment and tactical technical staff;improvement programs will fail ifeither group is left out or underem-phasized. Every entity within an or-ganization has a different sensitivitytoward change, and these differ-ences must be understood and ac-counted for because they deeplyaffect expectations. Disconnects inexpectation could eventually end upforcing an organization into a least-common-denominator approachthat lacks impact.

Keeping things simple helpspeople understand and support aprogram. Breaking down a majorchange program into logical seg-ments with specific deliverables tiedto each segment (or initiative) is aproven tactical approach. In prac-tice, we find that a reasonable timerange for any given initiative is threeto four months. This type of step-wise approach minimizes risk whileenabling an organization to test thewaters as it gauges receptivity tochange.

In terms of breaking down a pro-gram, we recommend a multiphasedplanning approach that accounts forthe dependencies among related ini-tiatives. Dependencies can helpwhen adjusting the general se-quence to account for those itemslikely to require a dependent taskprior to being kicked off—buildinga set of measurement tools, for ex-ample, will directly depend on thesoftware development methodology

used. If an early segment includes se-lecting or adopting a given method-ology, tool choice issues should bedeferred to a later segment becausethey require an in-place methodol-ogy to be effective.

A clear sequence of initiativeshelps an organization achieve aspecific level of adoption, test thewaters, measure and validate ac-complishments, and set the stagefor the next level. We follow a six-phase change program maturity-path sequence.

Phase 1The first phase, stop the bleeding, istargeted at known problem areas insoftware development programs. Ifparticular security bugs, such asbuffer overflows, cause the biggestproblem, a good phase 1 approachmight involve the adoption of acode-scanning tool and an associ-ated process for its use. If tens ofthousands of security-critical appli-

cations have unknown risks, a goodphase 1 approach might be to per-form a high-level risk analysis of theapplication portfolio and organizethe applications in order of critical-ity/security exposure so that theplan addresses those applicationsmost at risk first.

Phase 2The second phase, harvest the low-hanging fruit, focuses on finding thequick wins that are instrumental ingetting buy-in from the organiza-tion and in helping a program buildmomentum. Both phase 1 and phase2 are good barometers for determin-ing the organization’s receptivity to-ward change.

Phase 3The third phase, establish a foundation,is about setting up components thatprovide building blocks for futureinitiatives. Typical tasks in this phaseinclude creating change control pro-

www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 89

Software security best practices

Asuccessful software security improvement program is based on adopting best practices like

the ones shown with arrows in Figure A. These best practices are applied to software artifacts

created during the software development process, but they are “process agnostic” because they

don’t assume that any particular methodology is being used. An overview of all software devel-

opment life cycle best practices appears in an earlier installment of this department.1

Reference1. G. McGraw, “Software Security,” IEEE Security & Privacy, vol. 2, no. 2, 2004, pp. 80–83.

Abusecases

Securityrequirements

Riskanalysis

Externalreview

Risk-basedsecurity tests

Staticanalysis(tools)

Riskanalysis

Penetrationtesting

Securitybreaks

Requirementsand use cases

Design Testplans

Code Testresults

Fieldfeedback

Figure A. Software development life cycle. We can apply several software securitybest practices (the arrows) throughout the SDLC, given a set of common softwareartifacts (shown along the bottom).

Building Security In

grams, building a root cause analysisfunction, and setting up criticalfeedback loops. One such feedback

loop can identify any security prob-lems discovered via best practicessuch as code review and cycle themback into training (to teach develop-ers how to avoid common securityproblem in the first place).

Phase 4The fourth phase, craft core competen-cies, is driven by an organization’scurrent as well as desired strengths.If an organization has a strong repu-tation for creating solid architecturedocumentation, for example, it willlikely be more receptive to architec-tural risk analysis than it is to abusecase development. This phase ex-plicitly involves the adoption ofsoftware security best practices in amanner tailored to the organiza-tion’s strengths.

Phase 5The fifth phase, develop differentiators,emphasizes and highlights those at-tributes and characteristics not eas-ily duplicated by competitors, andthat thus differentiate the organiza-tion from competitors. Measure-ment and metrics systems put inplace with a software security im-provement program can demon-strate how well things are goingfrom a security perspective, whichcan serve as an important differen-tiator from the competition.

Phase 6The final phase, build out the “nice tohaves,” involves adopting those ca-pabilities that aren’t necessarily

aligned to a given strategic businessobjective, but that bring value byachieving some improvement in

productivity. We leave them last forobvious reasons.

Building an improvement programOnce we have a specific and action-able plan, a pragmatic approachshould drive each initiative. A clearunderstanding of what will be builtduring each part of the program,who will own it, and how they willbuild, deploy, and continue to im-prove it over time is essential.

The general framework and plandiscussed earlier should include sev-eral factors, including (but not lim-ited to),

• tools, • processes, • decision criteria and associated

actions, • templates, • examples and blueprints, • best practices, • guidelines, and • metrics and measures.

Several other drivers, including cur-rent software architectures, securitypolicies and guidelines, and regula-tory requirements, can also helpalign the framework with the strate-gic business direction.

The most important decision forassuring success in a cultural changeprogram is the selection of champi-ons—those individuals who willbuild, deploy, drive, and own eachinitiative going forward. Should aninitiative involve the adoption of sta-

tic analysis tools for code review, forexample, a champion well versed inimplementation-level securityanalyses, the target language, andhow to effectively use source-codeanalysis tools is vital. Ideally, such in-dividuals won’t be “freshly trained”in the area they’re meant to own;rather, they should have a hand in de-veloping the initiative and its com-ponents. A champion must be moti-vated, driven, and, most importantly,supported by the management team.They must also be good communi-cators and possess a strong capabilityto train and mentor others.

Establishing a metrics programOverstating the importance ofmeasurement and metrics is hard.Measurement provides manage-ment with critical insight into howto support strategic decision-making processes. Measures arenumeric values assigned to a givenartifact, software product, orprocess, and a metric is a combina-tion of two or more measures thattogether provide some business-rel-evant meaning. When consideredseparately, for example, “lines ofcode” and “number of securitybreaches” are two distinct measuresthat provide very little businessmeaning because there’s no contextfor their values. However, a metriccomprising “number of breaches”per “lines of code” provides a muchmore interesting relative value: wecan use it to compare and contrast agiven system’s security defect den-sity against similarly sized systemsand thus provide management withuseful data for decision making.

Ideally, metrics and measuresfocus on four primary areas: project,process, product, and organization.The first three are specific to a givenartifact or activity in a software de-velopment effort, whereas the latter’spurpose is to determine trends acrossthe three other areas.

Establishing a metrics capability isa challenging undertaking. Early

90 IEEE SECURITY & PRIVACY ■ MAY/JUNE 2005

A well-defined roadmap lays out the specifics

of how best to deploy software security best

practices given a particular organization’s

approach to building software.

Building Security In

www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 91

standard software process approachesfocused on sequentially building alevel of sufficiency in four areas in aparticular order: process, controls,metrics, and improvement. Unfortu-nately, following these basic steps inthe prescribed order implies that wedon’t address metrics until late in theprogram. By then, it might be too latebecause processes and controls put inplace early on might not be properlydesigned to provide the kinds metricsneeded later. In such cases, some sig-nificant rework might be required toachieve business alignment. Conse-quently, it’s now generally agreed thatmeasurement and analysis must be in-cluded much earlier in the process de-velopment model.

All metrics should renderdecision criteria based on strategicbusiness objectives. For this reason,business objectives must be articu-lated first and used to guide the en-tire program, from process and con-trol development onward.

T he targeted end state for any im-provement program (security or

otherwise) is a sustainable ability toevolve and change with the businessclimate. A critical foundation forcontinuous improvement is intro-spective in nature: each process mustbe carefully analyzed, assessed withrespect to the need for change, ad-justed as appropriate, and re-instan-tiated after refreshing. This feedbackcycle is critical for ensuring that anygiven initiative stays relevant.Process for process’s sake is a well-known pitfall that should beavoided. Unfortunately, many orga-nizations have a tendency to be-come lazy and slip back into oldhabits; control processes can helpcounter this tendency.

A critical feature for the successof continuous improvement in-volves the periodic auditing and ex-plicit reformulation of the organi-zation’s strategic objectives toensure they haven’t changed toomuch over time. If business needs

have moved far enough to pushprocesses and procedures off track,then the entire software securityinitiative must be reevaluated.

A critical challenge facingsoftware security today is the dearthof experienced practitioners. Ap-proaches that rely solely on appren-ticeship as a method of propagationare unlikely to scale quicklyenough; as the field evolves and es-tablishes best practices, businessprocess engineering can play acentral role in encapsulating andspreading this emerging disciplinemore efficiently.

Dan Taylor is managing principal ofCigital’s Productivity and Assurance

Consulting practice. He is an activemember of the American Society ofQuality and the Information SystemsAudit and Control Association. Taylorhas a BA in psychology and quantita-tive analysis from Clark University andan MBA in finance from Rutgers Uni-versity. Contact him at dtaylor@cigital.com.

Gary McGraw is chief technology officerof Cigital. His real-world experience isgrounded in years of consulting withmajor corporations and software pro-ducers. McGraw is the coauthor ofExploiting Software (Addison-Wesley,2004), Building Secure Software (Addi-son-Wesley, 2001), Java Security (JohnWiley & Sons, 1996), and four otherbooks. He has a BA in philosophy fromthe University of Virginia and a dual PhDin computer science and cognitive sciencefrom Indiana University. Contact him atgem@cigital.com.

Ensure that your networks operate safely and provide critical services even in the face of

attacks. Develop lasting security solutions, withthis peer-reviewed publication.

Top security professionals in the field shareinformation you can rely on:

Wireless Security • Securing the Enterprise • Designing for Security Infrastructure Security • Privacy Issues

• Legal Issues • Cybercrime • Digital Rights Management •Intellectual Property Protection and Piracy • The Security

Profession • Education

Order your subscription today.

www.computer.org/security/

BE SECURE.

DON’T RUN THE RISK.

BE SECURE.

DON’T RUN THE RISK.