Software Integrity Controls

An Assurance-Based Approach to Minimizing Risks in the Software Supply Chain

June 14, 2010

EditorStacy Simpson, SAFECode

ContributorsDiego Baldini, NokiaGunter Bitz, SAP AGDavid Dillard, Symantec CorporationChris Fagan, Microsoft CorporationBrad Minnis, Juniper Networks, Inc.Dan Reddy, EMC Corporation

ii

Table of Contents Introduction 1

TheRiskstoSoftwareIntegrityinaSupplyChain 2

TheITSystemSupplyChain 3

SoftwareIntegrityControls 4

VendorSourcingIntegrityControls 5

VendorSoftwareDevelopmentIntegrityControls 10

VendorSoftwareDeliveryIntegrityControls 16

FutureDirections 21

Conclusion 23

Acknowledgments 23

1

IntroductionSoftwareassuranceismostcommonlydis-

cussedinthecontextofpreventingsoftware

vulnerabilitiesthatarisefromunintended

codingerrorsandotherqualityissuesranging

fromincompleterequirementstopoorimple-

mentation.Thereductionofvulnerabilities

incodeisachievedthroughtheapplication

ofsecuredevelopmentpracticestothe

softwaredevelopmentlifecycle,sometimes

referredtoassoftwaresecurityengineering.

However,asamoredistributedapproach

tocommercialsoftwaredevelopmenthas

evolved,questionshavebeenraisedabout

whatadditionalproductsecurityandcom-

mercialrisksareintroducedintheglobal

softwaresupplychain.Oneemergingarea

ofconcernissoftwareintegrity,anexample

ofwhichistheriskthatmaliciouscodecould

beeitherintentionallyinsertedbyathreat

agentorunintentionallyinsertedduetopoor

processcontrolsintoasoftwareproductas

itmovesthroughtheglobalsupplychain.

Analyzingthisriskinthecontextofsoftware

engineeringrequiresanunderstandingnot

onlyofsoftwaresecurityengineering,butalso

theotheressentialpillarsofsoftwareassur-

ance—softwareintegrityandauthenticity.

SAFECodedefinessoftwareassuranceas“con-

fidencethatsoftware,hardwareandservices

arefreefromintentionalandunintentional

vulnerabilitiesandthatthesoftwarefunc-

tionsasintended.”Achievingthisconfidence

requiressoftwarevendors1toapplypractices

andcontrolstomeetthreekeygoals:

Security: Securitythreatstothesoft-

wareareanticipatedandaddressedduring

thesoftware’sdesign,developmentand

testing.Thisrequiresafocusonsecurity-

relevantcodequalityaspects(e.g.,“free

frombufferoverflows”)andfunctional

requirements(e.g.,“passportnumbers

mustbeencryptedinthedatabase”).

Integrity:Securitythreatstothesoftware

areaddressedintheprocessesusedtosource

softwarecomponents,createsoftwarecom-

ponentsanddeliversoftwaretocustomers.

Theseprocessescontaincontrolstoenhance

confidencethatthesoftwarewasnotmodi-

fiedwithouttheconsentofthesupplier.

1. Thispaperusesboththeterms“supplier”and“vendor”tomeananentitythatproducessoftware.Thesetermsmaybeusedinterchangeablyintherealworld,andthe“vendor”practiceslistedinthisdocumentapplytoallsoftware“suppliers.”However,inordertobeabletodescribetherelationshipbetweensoftwaresupplierswithoutconfusion,weareusingtheterm“vendor”throughoutthedocumenttoidentifyaspecificentityinasupplychain.Thus,inthiscontext,“supplier”referstoanentitythatprovidessoftwarecomponentstothe“vendor.”

Integrity

ASSURANCE

Security

Authenticity

Three Pillars of Software Assurance

2

Authenticity:Thesoftwareisnot

counterfeitandthesoftwaresupplier

providescustomerswaystodifferenti-

ategenuinefromcounterfeitsoftware.

Thispaperisfocusedonexaminingthesoft-

wareintegrityelementofsoftwareassurance

andprovidesinsightintothecontrolsthat

SAFECodemembershaveidentifiedaseffec-

tiveforminimizingtheriskthatintentional

andunintentionalvulnerabilitiescouldbe

insertedintothesoftwaresupplychain.

The Risks to Software Integrity in a Supply ChainTheriskofanattackerusingthesupply

chainasanattackvectordeservessome

furtherexamination.Evidencesuggests

thatattackersfocustheireffortsonsocial

engineeringorfindingandexploitingexist-

ingvulnerabilitiesinthecode,whichare

usuallytheresultofunintentionalcoding

errors.Thus,expertshaveconcludedthat

Tohelpothersintheindustry

initiateorimprovetheir

ownsecuredevelopment

programs,SAFECode

haspublished“Fun-

damentalPractices

forSecureSoftware

Development:A

GuidetotheMost

EffectiveSecure

DevelopmentPractices

inUseToday.”Basedonananalysis

oftheindividualsoftwareassurance

effortsofSAFECodemembers,thepaper

outlinesacoresetofsecuredevelop-

mentpracticesthatcanbeapplied

acrossdiversedevelopmentenviron-

mentstoimprovesoftwaresecurity.

Thebriefandhighlyactionablepaper

describeseachidentifiedsecurity

practiceacrossthesoftwaredevelop-

mentlifecycle—Requirements,Design,

Programming,Testing,CodeHandling

andDocumentation—andoffersimple-

mentationadvicebasedonthereal-world

experiencesofSAFECodemembers.

Thesepracticesaredesignedtobeused

inconjunctionwiththesoftwareinteg-

ritypracticesoutlinedinthispaper.

Toobtainafreecopyofthepaper,

visitwww.safecode.org.

Thispaperhasbeendeveloped

inconjunctionwithSAFECode’s

previouslypublished“Soft-

wareSupplyChainIntegrity

Framework,”whichoutlines

ataxonomyforthesoftware

supplychainandaframework

foranalyzingandestablishing

softwareintegritycontrols.

Integrity

ASSURANCE

Security

Authenticity

The Software Supply Chain Integrity Framework

Defining Risks and Responsibilities for Securing Software in the Global Supply Chain

July 21, 2009

Editor Stacy Simpson, SAFECode

ContributorsDan Reddy, EMCBrad Minnis, Juniper NetworksChris Fagan, Microsoft Corp.Cheri McGuire, Microsoft Corp.Paul Nicholas, Microsoft Corp.Diego Baldini, NokiaJanne Uusilehto, NokiaGunter Bitz, SAPYuecel Karabulut, SAPGary Phillips, Symantec

3

asupplychainattackisnotthemostlikely

attackvector.Notably,theexperiencesof

leadingreputablesoftwarecompanieswho

workwiththeirsupplierssupportthisfinding.

Further,thereisgrowingrecognitionthat

1)thereisnoonewaytodefendagainst

everypotentialvectoramotivatedattacker

mayseektoexploit;2)focusingonthe

placewheresoftwareisdevelopedisless

usefulforimprovingsecuritythanfocus-

ingontheprocessbywhichsoftwareis

developedandtested;and3)thereare

circumstanceswhentheinsertionofmalicious

codewouldbealmostimpossibletodetect.

Thesechallengeshighlightthatariskfrom

thesupplychaincouldindeedundermine

aproduct’sintendedfunctionordamage

customertrust.Accordingly,majorsoftware

supplierstakepreventativeactionagainstany

unauthorizedchangesintheformofsoftware

integritycontrols.Thesecontrolspreservethe

qualityofsecurelydevelopedcode,prevent

theinadvertentintroductionofvulnerabilities

andhelptopreventtheintentionalinsertion

ofmaliciouscode.Vendorsleveragethese

integritycontrolstoachievetheseobjectives

byaddressingthesecurityoftheprocesses

usedtosource,developanddeliversoftware.

The IT System Supply ChainTheITsystemsupplychainisaglob-

allydistributedanddynamiccollectionof

people,processesandtechnology.Software

isonecomponentofalargerITsolution

andeachsoftwarevendorisonlyonepart

ofacomplexchainofsuppliers,systems

integratorsandultimateendusers.Assuch,

eachvendorisonlyonelinkofalarger,

morecomplexITsystemsupplychain.

Asavendor’scustomermaynotbethe

ultimateenduserintheITsystemsupply

chain,itisimportanttoanalyzewherealong

thesupplychainsoftwaresecurity,integ-

rityandauthenticitypracticesandcontrols

canbeappliedeffectivelyandefficiently.

EachsupplieralongtheITsystemsupplychain

hasbothanopportunityandaresponsibility

toapplysoftwareassurancepracticesand

controlsinordertopreservesoftwareintegrity,

Integrity

ASSURANCE

Security

Authenticity Integrity

ASSURANCE

Security

Authenticity Integrity

ASSURANCE

Security

Authenticity Integrity

ASSURANCE

Security

Authenticity

TiernSupplier Tier2Supplier Tier1Supplier Integrator

Software Assurance Is a Shared Responsibility In the IT System Supply Chain

Customer

4

securityandauthenticitywithintheportionof

thesoftwaresupplychainitcontrols.Naturally,

avendorhasthemostdirectcontroloverits

owninternalpractices.Avendor’sreachinto

itsownsuppliersfortheirsoftwareassurance

practicesandcontrolsmaynotbeasdirect.

WithintheirrespectivelinksoftheITsystems

supplychain,allsoftwarevendorscontroland

managethreekeylifecycleprocesseswhere

theycaneffectivelyandefficientlyimplement

softwareassurancepracticesandcontrols:

1. SoftwareSourcing:Vendorsselecttheir

componentandservicessuppliers,estab-

lishthespecificationsforasupplier’s

deliverablesandhaveactivitiesto“on-

board”softwareandhardwarecomponents

andservicesreceivedfromsuppliers.

2. SoftwareDevelopment:Vendors

build,test,assemble,integrateand

packagecomponentsfordelivery.

3. SoftwareDelivery:Vendorsdeliver

thesoftwareproducttocustomers

andprovideongoingsustainment.

Itiswithinthesethreeprocessesthateffective

softwaresecurity,integrityandauthentic-

itypracticesandcontrolsmustbeappliedin

ordertoimprovetheassuranceofdelivered

software.Thispaperwillfocusspecifically

onthesoftwareintegritycontrolsthatven-

dorsapplytoeachoftheseprocesses.

ItshouldbenotedthatSAFECodemember

companies,likeindustrycompaniesatlarge,

arestillsharinginformationandexamining

practicalandmeaningfulmeansofmeasur-

ingandverifyingsoftwareassuranceinthe

marketplace.Asthatworkmatures,wecan

expectmoreconsistencyinhowinforma-

tionaboutinternalprocessesisasserted

andevaluatedbetweentradingpartners.

Thus,whilethispaperfocusesontheprac-

ticesandcontrolsinvolvedalongthesupply

chain,itwasdevelopedwiththerecognition

thatmoreworkinthisareaneedstobe

done,anditdoesnotattempttobehighly

prescriptivewithrespecttomeasurement.

Software Integrity ControlsThefollowingsectionswilldetailthesoft-

wareintegritycontrolsthatSAFECodehas

identifiedaseffectiveforminimizingthe

riskthatvulnerabilitiescouldbeintention-

allyorunintentionallyinsertedintothe

softwaresupplychain.Thisanalysisisbased

onthereal-worldexperiencesofSAFECode

members.Theseintegritycontrolsaimto

preservethebaselevelofsecurityina

productachievedthrougheachsupplier’s

Software Sourcing• Procurement

Software Development and Testing• Environment• Personnel• Software Development

Software Delivery• Distribution• Sustainment

5

securedevelopmentpracticesbyhelpingto

preventtheintroductionofvulnerabilitiesas

aproductmovesalongthesupplychain.

Thecontrolsidentifiedinthefollowing

sectionsarebasedonthesevenbasic

principlesforsoftwareintegrityoutlined

inSAFECode’spreviouslypublished“Soft-

wareSupplyChainIntegrityFramework:”

• ChainofCustody

• LeastPrivilegeAccess

• SeparationofDuties

• TamperResistanceandEvidence

• PersistentProtection

• ComplianceManagement

• CodeTestingandVerification

Theseprinciplessupportthedevelopment

ofthesoftwareintegritycontrolsoutlined

inthispaperandidentifiedbySAFECode

aspractical,repeatableandauditable.

Thesoftwareintegritycontrolsdescribedin

thefollowingsectionsdonotrepresenta

minimumcontrollist,butratheraredesigned

tobeintegratedwithothersecuritypractices

andtailoredtomeetaproduct’sspecificrisk

profile.Furthermore,theyaretobeintegrated

intothevendor’ssoftwareengineeringprocess

andperformedinconjunctionwithcorporate

securityfunctions.Thesemayincludephysical

security,networksecurity,ITinfrastructure

securityandbusinesscontinuitymanagement.

SAFECodehasorganizedtheintegrity

controlslistedinthefollowingsections

bythethreekeylifecycleprocesseseach

softwarevendorhascontrolover—sup-

pliersourcing,productdevelopment,and

productdeliveryandsustainment.

Vendor Sourcing Integrity Controls

Software Sourcing• Procurement

Software Development and Testing• Environment• Personnel• Software Development

Software Delivery• Distribution• Sustainment

Duringthesourcingprocessvendors

establishcomponentspecifications,select

suppliersofcomponentsandservices

andreceivesuppliedcomponents.

Theselectionandapplicationofsoftware

integritycontrolsforuseduringsourcingis

arisk-baseddecisionandlargelyinfluenced

bythenatureoftherelationshipbetweena

vendoranditssoftwarecomponentsupplier.

Therearethreetypesofvendor-supplierrela-

tionships:First,“armslength”relationships

wherevendorAlicensesacomponentfrom

supplierB.Second,work-for-hirerelationships

wherevendorAengagessupplierBtoprovide

asoftwarecomponent.Third,work-for-hire

relationshipswherevendorAengagessupplier

Btoprovideastaffaugmentationservice.

6

Relationshipsbetweenavendorandasup-

plierbasedonlicensingfinishedcomponents

likedatabases,enterpriseresourcemanage-

mentsystems,oroperatingsystemsare

examplesofarmslengthrelationships.It

isincumbentonsuppliersthatlicensetheir

software—typicallysuppliersofcommercial-

off-the-shelf(COTS)productsorOpen

SourceSoftware(OSS)components—1)to

assurethatsecuritythreatstotheproduct

orcomponentareanticipatedandaddressed

duringitsdesign,developmentandtest-

ing;2)toassurethattheprocessesused

tosourceandcreatecomponents,andto

delivertheproducttotheircustomersare

secure;and3)theirsuppliersprovideways

fortheircustomerstodifferentiategenuine

productsandcomponentsfromcounterfeit.

Inrelationshipsbasedonwork-for-hire,the

softwaredeliveredbyasuppliertoavendor

isownedbythevendor.Theintegritycontrols

usedbythesuppliermaybethesupplier’s,

thevendor’soranycombinationthereof.

Typically,instaffaugmentationengagements

thevendor’sandsupplier’sstaffworkcollab-

orativelyonprojectsthatsharecodelibraries,

toolsandresources,andallprojectmembers

utilizethesamesoftwareintegritycontrols.

Ineachoftheaboverelationships,theven-

dorhasdifferentdegreesofcontrolover

theintegritypracticesandcontrolsused

byitssupplier.Itisthislevelofcontrol

thatguidestheselectionofthesoftware

integritypracticesandcontrolsneces-

sarytominimizesoftwareintegrityrisks.

Thenextsectiondescribesintegrity

controlsthatcanbeusedinavendor’s

sourcingprocess.

Vendor Contractual Integrity ControlsAvendor’sengagementwithasupplier

shouldbegovernedbyawrittenagree-

ment,forexamplealicenseoracontract.

Thewrittenagreementmustexplicitlystate

thevendor’sandsupplier’sexpectations,

aswellastheconsequencesofanynon-

compliancewiththetermsoftheagreement.

DefinedExpectations

• Clearlanguageregardingtherequirements

tobemetbythecodeandthedevelop-

mentenvironmentshouldbesetforth

duringthecontractingprocess.Among

otherthings,thisshouldincludecommit-

mentstoprovidesecuritytesting,code

fixesandwarrantiesaboutthesoftware

developmentanddeliveryprocessused.

Overallthishelpstosettheexpectation

ofdeliveringaproductwithintegrity.

OwnershipandResponsibilities

• Intellectualpropertyownershipand

responsibilitiesforprotectingthe

codeanddevelopmentenvironment

shouldbeclearlyarticulated.

VulnerabilityResponse

• Intoday’sworld,vendorsmustpushfor

amoreformalunderstandingofhowwell

theirsuppliersareequippedwiththecapa-

bilitytocollectinputonvulnerabilitiesfrom

7

researchers,customersorsourcesand

turnaroundameaningfulimpactanalysis

andappropriateremediesintheshort

timeframesinvolved.Thefactisthatthe

handlingofsuchvulnerabilitieswilllikely

becomeajointresponsibilityinthefaceof

downstreamvisibilitytocustomers.Noone

canaffordtobesurprisedaboutasuppli-

er’spotentialimmaturityinhandlingthese

challengesinthemiddleofasituation.

Suppliersprovidecommonterminology

forthesediscussionsbyusingnow-default

referencestowell-knownspecifications

likeCommonVulnerabilitiesandExposures

(CVE)andCommonVulnerabilityScoring

System(theCVSS).Eachpartyshould

identifycontactpersonnelandreviewtim-

ingandescalationpathsasappropriateto

bepreparedtoprovideapromptresponse.

SecurityTraining

• Anotherimportantareafordiscussion

betweentradingpartnersisassessinga

supplier’scapabilitytoeffectivelytrain

itsdevelopersonsecuredevelopment

practices.Whileitisnotnecessaryto

behighlyprescriptiveaboutaparticu-

larcurriculumorcertificationregime,a

companycannotcrediblyassertthatit

hasasecuredevelopmentframeworkor

thatitfollowsintegritypracticesifthere

isnoevidenceofanyrelevanttraining.

Thecontractsbetweencompaniesregard-

ingsoftwarehavetypicallybeenfocused

onexpectationsregardingfunctional

performance,defecthandling,licensing

issuesandotherchallengeslikeend-of-

lifesupport.Asconcernsaboutprotecting

software’sintegrityhaveescalatedalong

withreducingtheriskofcounterfeitcom-

ponentsandproducts,contractsevolved

furthertoaddressthisinlanguage.

Newlanguagethatspecificallyaddresses

theissueofintegrityandauthentic-

ityofCOTSproductcomponentsfrom

externalsuppliersthatwillbeincluded

intheultimateproductcanalsobe

explored.Thelanguagewouldasksup-

plierstoself-certifythatthesupplier’s

softwarealignswithsecuritystandards

andthatthesupplier’spracticesalign

withbestpracticesofindustrycode

securityandintegrityorganizations

likeSAFECodeoritsequivalent.

8

OpenSourceSoftware

Theuseofopensourcesoftwarepres-

entsalternativechallengesinthe

contextofsupplychainintegrity.

Whileinsomecasesacommercialentitymay

packageandsupportopensourcesoftware,

otheropensourcesoftwareismanagedbya

communitywithwhichadirectrelationship

cannotbeestablished.Inthelattercase,the

trustandaccountabilitybetweenavendor

andthecommunitysupplyingsoftwareis

different.Notably,thecontractualterms

thatvendorsestablishwithcommercialsup-

pliersdonotapplytocommunity-supplied

componentsasthereisnodirectsupplier

withwhomtoestablishanagreement.Exist-

inglicensetermsgoverningtheuseofopen

sourcesoftwarearefocusedonensuring

thatcombinationsofthesoftwarewithother

softwareareconsistentwiththecommunity’s

expectations.Thoselicensetermsmaynot

providesufficientsupportforeffortstoprotect

softwareintegrity.Othercontrolssimilarto

thosepresentincommercialvendor-supplier

agreementsmayneedtobeimplementedfor

community-suppliedsoftware.Forinstance,

asvulnerabilitiesarevisibletoanyoneand

becausetheirexploitabilitycanbereadily

assessed,opensourcecommunitiesmaycall

formoreactivevulnerabilitymanagement

andincidenthandling,andusersinthefield

mayrequestquickersoftwareupdates.

Asaresult,theprocessusedtoevaluate

andselectopensourcesoftwarecomponents

deservesconsideration.Softwareven-

dorsanalyzethereputationandrelease

engineeringpracticesofthecommunity

supportinganopensourcecomponentto

helpassessitscompetenceandreliability

indealingwithsecuritymatters.While

thevettingpracticeswillvarydepend-

ingonthespecificproductneedsandrisk

profile,meanstovalidateopensourcepack-

agesandtheirdistributionsitesneedto

beadoptedanddeveloped,respectively.

Aviableintegritycontrolforcommunity

opensourcecomponentsisforavendorto

getthesource,reviewitandbuildit.Vali-

datingthequalityofopensourcesoftware

needstohappenafteracquisitionofthe

code.Vendorsmaychoosetoincludean

opensourcecomponentorleaveituptothe

acquirertoobtainandevaluatethecompo-

nent.Forvendor-supportedOSS,anacquirer

cantransferrisktothevendorthrough

appropriatelanguageintheiragreement.

Otherwiseineithercase,proceduresmustbe

implementedfortheinspectionofsoftware

componentsforthepresenceofvulnerabilities

andfortheassessmentofthetrustworthi-

nessofthecomponent’sdistributionsite.

Ingeneral,avendormustunder-

standhoweachofitssuppliers

handlestheopensourcecomponents

thatareshippedwithitsowncode.

9

Vendor Technical Integrity Controls for Suppliers

SecureTransfer

• Deliveredcodeshouldbetransferred

securely,usingauthenticatedendpoints

andencryptedsessions.Contentbeing

deliveredshouldbeencryptedfortransit.

Thisrequiresthatsuppliersusethebest

availabletechnology,mechanismsand

procedureswhenexchangingdeliverables.

Asecureend-to-endautomatedprocess

canoftenstrengthentheprotectionthat

couldberesidentinamanualprocedure.

SharingofSystemandNetworkResources

• Thedigitalidentitiesavendorissuesto

supplierstoenableaccesstotheven-

dor’snetworkandresourcesshouldbe

establishedwithstrongcontrolsenforced

tolimitaccesstoonlythoseresources

neededtoperformthesupplier’srole.

– Eachresourcethatissharedshould

haveitsownindependentassess-

mentastowhatauthenticationand

authorizationisrequired.Forexample,

staffaccesstoavendor’sdevelopment

projectrequiresadditionalauthoriza-

tionoverandabovetheauthorization

astaffmemberreceivesinorderto

accessavendor’scorporatenetwork.

– Asupplier’saccesstodevelopment

assetsshouldexpireassoonasitleaves

theproject.Afail-safecheckshould

alsobeinplacetoendallprivileges

automaticallyatcontractexpiration

oratanotherfixedperiod.Arobust

procedureisrequiredsothatwhena

supplier’semployeeleavesthesup-

pliercompany,theformeremployee’s

credentialsimmediatelyexpire.A

combinationofautomaticdisablingand

manualnotificationisbesttoensure

completenessofprivilegeremoval.

MalwareScanning

• Suppliercontenttobetransmittedto

thevendorshouldbescannedformal-

wareusingthemostrecentmalware

signaturefilesandmorethanonecom-

mercialscanningengine.Whiletoday’s

malwarescanningtoolsaregenerallynot

designedtoidentifymaliciouscodethatis

perfectlyformed,thisstandardintegrity

controlshouldbeperformedatpointsof

exchangebetweenparties.Depending

ontherelationshipandthepracticalityof

doingso,suppliersshouldinformrecipi-

entsofthecodeastowhatscanninghas

takenplaceuptothepointoftransfer.

SecureStorage

• Sourcecodeforsoftwarecomponents

andproductsshouldbestoredsecurely

withneed-to-knowaccesscontrols

applied.Codepackagesthataretrans-

ferredshouldbemovedtoasecure

assetrepositoryassoonaspracticalso

thattheycanbemanagedmorepre-

ciselywithrespecttoaccessprivileges.

10

CodeExchange

• Processesusingdigitallysignedpack-

agesandverifiablechecksumsorhashes

shouldbeinplacetoensurethatreceived

codeiscompleteandauthentic.Verifying

thedigitalsignatureswithvalidatedtime

stampsofthesoftwarepackagesproves

authenticityandestablishesthatthe

downloadortransferprocessdeliveredan

intactversionoftheintendedpackage.

Vendor Software Development Integrity Controls

Insoftwaredevelopmentandtest-

ing,softwarevendorsbuild,assemble,

integrateandtestsoftwarecomponents

tofinalizethemfordelivery.

Softwarevendorshaveagreatdealof

experienceimplementingpowerfulman-

agement,policyandtechnicalcontrolsto

achievesoundengineeringpracticesand

intellectualpropertyprotection.Thesecure

developmentpracticesthatfocusprimar-

ilyonachievingthe“security”circleinthe

softwareassurancetriaddescribedabove

becomethebaselineforinternaldevelopment.

Withinasoftwarevendor’sorganiza-

tion,additionalsoftwareintegritycontrols

mayexistwithinthecontextofotherIT

functionssuchasbackupandrecovery,

businesscontinuity,physicalandnetwork

security,andconfigurationmanagement

systems.Thefollowingareexamplesof

controlsemployedbySAFECodemembers:

PeopleSecurity

• Itshouldbenotedthatwhilecriminal

backgroundchecksareoftenthefocus

ofpublicdebate,inpracticeSAFECode

membershavefoundthattheyarenotas

effectiveasothercontrolsandprocesses.

Focusingonorganizationalandprocess

controlsinconjunctionwithtechnology

tominimizeriskscomingfromwithinthe

companyismoreefficientandeffective.

Forthatreason,manyofthefollowing

controlstominimizetheriskfrommali-

ciousinsidersarebasedonpractices

suchasthesegregationofdutiesandthe

useofcontrolledautomatedprocesses.

• Itisimportantthatroles,responsibili-

tiesandaccessrightsareclearlydefined

indevelopmentprocessestoachievea

defense-in-depthapproach.Development

managementmustbeknowledgeableas

towhohaswhataccess.Ateamofpeople

withwell-plannedresponsibilitiesmust

maintainappropriateoperationsforguard-

ingcodeassetswhilemeetingthedemands

oftheglobalengineeringenvironment.

Software Sourcing• Procurement

Software Development and Testing• Environment• Personnel• Software Development

Software Delivery• Distribution• Sustainment

11

• Inadditiontotheexpectedtrainingin

securedevelopmentpractices,there

shouldbetraininginthesecuretechni-

calcontrolsusedbyotherintegrity

practices.Doeseachorganizationknow

howtoverifyadigitalsignaturewith

avalidatedtimestamp?Doeseach

organizationunderstandwhichhashalgo-

rithmsarebestusedinachecksum?

PhysicalSecurity

• Buildingsecurityandphysicalaccess

controlshouldbeappliedtodevelop-

mentlocationsandcoderepositoriesand

periodicallyre-assessedusingarisk-based

process.Physicalsecuritycontrolsshould

bestrongenoughtoensurethatdevel-

opmentassetscannotbeaccessedby

outsiders.Physicalprotectionofsource

codeshouldgobeyondasinglelayerof

buildingsecurityandincludeadditional

distinctphysicalaccesscontrolsthatlimit

accesstothosewitha“needtoknow.”

Forexample,additionalbadgerestricted

accessbeyondthenormalbuildingaccess

shouldberequiredforadministrators

toaccesscodeassetsprotectedina

repository.Physicalassetsandcredentials

WhileSAFECode’sDevelopmentPractices

paperdescribeshowtoidentifyandavoid

typicalcodingerrorssuchasbufferover-

flows,SQLinjection,crosssitescripting

andmore,thiscurrentworkdealswiththe

questionofpreservingtheintegrityofan

ITproduct.Theintegritypracticesserve

ascontrolstopreventunauthorizedor

inadvertentchangestothesourcecode.

Withoutpropercontrols,vulnerabilities

canbeintroducedby”goodfaith”develop-

ers.Forexample,whilefixingaproblemin

theirpartofthecodewithdependencies

elsewhere,adevelopermightinadvertently

changecodewhilemergingitwitharelated

function(e.g.,aninterface)primarilyowned

byanother.Withoutproperintegritycontrols,

thischangemightgoundetectedandcould

causeproblemselsewherebecausenobody

wasexpectingthefunctiontohavechanged.

Acombinationofgoodaccesscontrols,

testingandpeerreviewofchangescould

minimizethisrisk.Thusintegritycontrols

canaimatpreservingthewell-constructed

codefortheapprovedspecificationwhile

preventingcarelessorinadvertentchanges.

Integritycontrolsthroughoutthesupply

chainwillalsoreducetheriskofamalicious

attackerbeingabletochangecodeinten-

tionallyorperhapsdetectavirusbeforeit

spreadsintotheproductionenvironment.

Integrity Controls vs. Development Practices

12

(e.g.,keys,badges,securitytokens,

smartcards,laptops,etc.)loanedtoan

individualshouldberetrievedandveri-

fiedagainstalistofexpectedassetsas

partofamanagedterminationprocess.

NetworkSecurity

• Networksecuritystandardsshouldbe

establishedandappliedusingarisk-based

processforthecode-relatedassets.For

example,securityprotectionscouldinclude

intrusiondetectionorotherdefensive

measuresonsourcecoderepositories

withalertingtoappropriateeventsys-

temsthatwouldalarmduringanattack.

Sessiontrafficinvolvingsourcecode

shouldbeencryptedtoacceptablecom-

panyorapplicableindustrystandards.

• Accesstodeveloperworkstationsshould

becontrolled.Forexample,workstations

canbetiedtocorporateauthenticationto

ensurethatterminatedworkersareimme-

diatelydeniedfurtheraccess.Accounts

ofdepartingemployeesandotherautho-

rizedworkersshouldbeproperlydisabled

immediatelytoallowappropriatereviewof

theirwork.Itisimportanttodisable,and

notdelete,accountssothatafullforensic

analysisisstillpossibleaftertermination.

• Workstationandvirtualmachinesecurity

shouldbesecuredtostandardstomini-

mizetheopportunityformaliciouscodeto

beintroducedduringthecodingprocess.

Developersshouldhavewriteaccessto

theminimumcodenecessarytocarry

outtheirresponsibility.Accesstocode

storedonlocalmachinesshouldalsobe

controlledbasedona“need-to-know”and

“least-privilege”basistotheextentpossible

giventhegoalsoftheprojectathand.

CodeRepositorySecurity

• Allcode-relatedassetsshouldbe

housedinsourcecoderepositories

(alsoknownasconfigurationmanage-

mentsystemsorsourcecodecontrol

systems),toenableadditionalatten-

tiontosecurityandaccesscontrol.

• Theserversthathostthesourcecode

repositoriesshouldbehousedsecurely.

Inmostmajorsoftwarevendors,these

machinesarelocatedindatacenterswith

appropriatephysicalsecurity,hardened

serversecurityandbusinessdisaster

recoverycontrols.Bemindfulthatsource

codeissometimescopiedandkeptin

separatedatabasesafterbeingrunthrough

somestaticcodeanalysistools.Theconfi-

dentialityofcodefilesshouldbeprotected

inalllocations.Thisavoidsunauthorized

peoplefromseeingthecodestructure

andtestresults.Combinedaccesstosuch

informationmightenablethemtobetter

targetparticularcodefilesinalaterattack.

• The“outofthebox”defaultsofanysuch

systemmustbeexaminedandconfigured

tobesecurebydefault,ideallyaccord-

ingtoawell-understoodstandardfora

13

systemholdinganacquirer’sprecious

assetssuchasitscustomers’personal

identifiableinformation.Oneobjective

wouldbeforthesystemtooperatewithout

theriskofallowingexploitsthrougheas-

ilyinheritedsystem-levelrootprivileges.

Manydetailedsettingssuchasauthen-

ticationhandling,sessionvariablesand

externalinterfacesmustbeaddressedto

deliversecure-by-defaultdeployment.A

software’sdefaultstateshouldpromote

security.Forexample,softwareshould

runwiththeleastnecessaryprivileges

andservicesthatarenotwidelyneeded

shouldbedisabledbydefaultoronly

accessibletoasmallpopulationofusers.

• Onceenabledassecurebydefault,that

configurationstatusitselfmustbepro-

tected.Asmoresystemslikerepositories

becomecompliantwithspecificationslike

theemergingSecurityContentAutoma-

tionProtocol(SCAP)specifications,the

configurationstateoftherepositoryand

subsequentchangescanbeexpressed

andconsumedinmachine-readable

form,offeringgreaterinitialandongo-

ingprotectionsupportedbyautomation.

• Ideally,accesstosourcecoderepositories

shouldbecontrolledthroughtheuseof

corporateidentitysystems,withstrict

controlmaintainedoveraccesstoany

systemaccount.Engineeringadministra-

torsresponsibleformanagingapplication

repositoriesshouldbenameduserswith

distinctidentitiestoprovideaccountability.

Administrativepracticesshouldobserve

theseparationofdutiesprinciple,and

elevatedpermissionsshouldbesubject

tomanagementapproval.Forinstance,

projectengineeringadministratorsrequire

ahigherlevelofaccesstocodeassets

toperformtheirdutiesthannetwork

securityadministrators.Otherperson-

nelsuchasITorSecurityOperations

mayhaveresponsibilityforbase-level

configurationsandtheoverallplatform

profileincludingsecuritypatchlevels,etc.

• Withintherepositories,accessto

branches,workareasorcodesets

mustbeunderstoodbydevelopment

management,andaccessprivileges

shouldbegrantedusingtheprinciples

ofleastprivilegeandneedtoknow.

• Codesegmentscanbetiedtospe-

cificrequirementsinarequirements

management,enhancementorbug

trackingsystemthatallowsforcross

mappingoffunctionalitytocode.

• Changemanagementpracticeswithreview

andapprovalpathsshouldbeformalized

andwellunderstoodforcodelogicand

assetchanges,repositoryapplicationand

underlyingsystemconfigurationchanges.

• Changelogsforallmodificationstoa

product’scodeassetsshouldbemain-

tainedandpreservedforfutureanalysis.

Logsshouldprovidefilenames,account

nameofthepersoncheckinginthefile,

14

Acompanycanhavesourcecodepolicy

andstandardsthatproductengineer-

ingteamsareexpectedtomeetinthe

contextofprotectingsourcecodeand

productartifactsthroughouttheproduct

developmentcycle.Forexample,these

couldincludedetailedcorporateexpecta-

tionsregardingtheprotectionofsource

coderepositoriesandbuildenvironments.

Somemightbesimplerequirements,like

“SourceCodeSystemsshouldleverage

corporateidentitystoresforauthentication,”

andperhapsobviouslythat“noanonymous

accesscanbeallowedtoarepository.”

Othersaremoredetailed,suchaswhich

particularsystemsforhandlinginternal

requestandapprovalroutingforsource

coderepositoryprivilegesmustbeused

byeachengineeringteam.Settingupthe

linkagebetweensourcecoderepositories

andthesetofbuildtoolsischallenging

sinceautomationandaccountabilitymust

beblended.Apracticalapproachisneeded

suchthatthesetsoftoolscanbeconsistent

andautomated,whilestillmakingitknown

whocreatedandranthescriptedenviron-

mentthatproducedaparticularbuild.In

addition,buildscriptsneedprotectionas

criticalassets.Thisinternalstandardalso

tiesintocorporatesecuritypolicesandcon-

trolssuchasthecredentialingrequirements

forpersonnelandhandlingofdigitalidenti-

ties,akeybridgetobestpracticesaround

theprotectionofsourcecoderepositories.

Anactive,ongoingrelationshipwithengi-

neeringteamsplacestheinternalsecurity

teaminthebestpositiontoeffectongoing

improvementstotheprotectionofcode

throughoutitslifecycle.Therequirements

shouldnotdistractbysimplyattempt-

ingtoforceeveryonetouseanidentical

repository,buttosetthestandardforhow

arepositoryshouldbesetupandoperated

securely.Theapproachtakeninworking

withengineeringteamsistoassessthe

gapsthatexistbetweenwhereagroupis

todayoneachiteminthestandardandto

buildanimprovementplanforclosingthe

gapsaspartofarisk-basedapproach.

15

check-intimestamp,andthelinechanges

made.Theyshouldbekeptforasuf-

ficienttimeinaprotectedenvironment

toassistwithanyforensicsorongo-

ingsecurityimprovementinitiatives.

• Amanifestofallcodeassetscontributing

toaproduct,includingthosedeveloped

in-houseandbythirdparties,shouldbe

maintainedandmanaged,similartoaBill

ofMaterialsinthemanufacturingdomain.

• Versionsofsoftwareassetswiththeir

knownsecuritycharacteristicsshould

betrackedintherepository.Changeor

configurationmanagementshouldbe

trackedaswelltofindthebalancebetween

gettingthelatestpatchesandupdates

andhavingstable,predictablecode.

BuildEnvironmentSecurity

• Buildenvironmentsshouldbeasautomated

aspossible.Thisminimizestheopportunity

forhumaninterventionintheregularbuild

process.However,the“owners”ofthebuild

environmentshouldbefew.Thetraceability

ofactionsonbuildscriptsandofaccess

tocodefilesduringbuildshouldbehigh.

• Buildautomationscriptsshouldbetreated

inamannersimilartoothersource

codeassetsandcheckedintothecode

repository.Thismeansthatchangesto

theautomatedbuildprocesscanbeattrib-

utedtothepersoncheckinginthefile.

• Serviceaccountsthatruninanautomated

fashionbetweensourcecoderepositories

andbuildtoolsshouldbetraceableto

individualswiththeauthoritytoexecute

theautomatedscriptsorprocedures.

Peer Reviews and Security TestingOnesecurityengineeringpracticethatall

SAFECodemembersuseinconjunctionwith

theirsoftwareintegritycontrolsissecurity

testing.Sourcecodeandbinaryanalysis

tools,andsometimesmanualcodereview,

areperformedoncodetoidentifycommon

codingpatternsthatareknowntohave

beenattackedpreviously.Testingtech-

niquesarecontinuallyupgraded.Security

engineeringpracticescomplementsoftware

integritycontrolsbecausesecurityengi-

neeringpracticesrepresentanever-rising

thresholdagainstsoftwaresupplychain

vulnerabilities.Thetestingtechniquesbelow

areprimarilysoftwaresecurityengineering

practices,notsoftwareintegritycontrols.

PeerReview

• Peerreviewsandthemanualinspection

ofcodearenotoftenpopulargivenissues

ofscalability.Automatedtoolscanenable

somescalabilitybycollectingandprocess-

ingmoreartifactsinpreparationforpeers

performingafocusedreview.Also,when

teamsareassignedtoworktogetheron

codefiles,animportantdynamicispresent

wherebyreviewerscanmorereadilyiden-

tifycodethatdoesnotbelongwithinacode

set.Focusingpeerreviewersonchanged

codethatisscannedagainandawaiting

16

approvalduringatwo-stagecheck-into

therepositorycanbeaneffectiveapproach.

Anotherapproachistocouplepeerreviews

inrelationtoexercisedcodepathsinthe

contextofoverallcodecoverage.Ingen-

eral,questionsaboutthestructureand

purposeofsectionsofcodethatarisedur-

ingpeerreviewaremorelikelytouncover

intentionalmaliciouscodeorinadvertent

codeerrorsthanautomatedtestingalone.

TestingforSecureCode

• Thesizeofthecodebaseformanysoft-

wareprojectstodayrequiresautomated

codereviewandtestingtools.Additional

informationonsecurecodetestingcan

befoundinSAFECode’s“Fundamental

PracticesforSecureSoftwareDevelop-

ment”paper.Buildingtheseteststo

runinarepeatableautomatedmanner

increasestheassurancethattheywill

beperformedandanalyzedoften.

• Thelistbelowidentifiesthemostcom-

moncategoriesoftestingtoolsused:

– Staticcodeanalysistools(sourcecode)

– Networkandwebapplicationvulner-

abilityscanners(dynamictesting)

– Binarycodeanalysistools

– Malwaredetectiontools(dis-

coverbackdoors,etc.)

– Securitycompliancevalidationtools

(hardening,dataprotection)

– Codecoveragetools

Whilesecuritytestingisafundamentalpart

ofsupplychainsecurity,softwarevendors

recognizethattestingaloneisnotlikelyto

catchmaliciouscodethatisintentionally

inserted,perfectlycraftedanddisguisedto

appearaslegitimate.Duetotheselimitations,

softwaretestingmustbeaugmentedwith

theotherlistedsoftwareintegritypractices

thatcontrolaccesstodevelopmentassetsto

moreeffectivelyaddresspotentialsoftware

securityrisksinthisstageofthesupplychain.

Vendor Software Delivery Integrity Controls

Thisstageofthesoftwaresupplychain

coversnewproductdeliveryandthe

deliveryofmaintenancepatches.

Itisimportanttonotethatwhilethismay

bethelaststageofthesupplychaindirectly

underasoftwarevendor’scontrol,itisnot

alwaysthefinalstepinthesupplychainfrom

theenduser’spointofview,assoftware

vendorsoftendonotprovidetheirproducts

directlytoend-userorganizations.Inmany

cases,thesoftwarevendor’sproductsare

passedtosystemintegrators,resellersand

authorizedserviceprovidersbeforereaching

Software Sourcing• Procurement

Software Development and Testing• Environment• Personnel• Software Development

Software Delivery• Distribution• Sustainment

17

theend-user.Thus,assoftwarecomponents

leavethesupplier,softwareintegrityand

authenticitybecomeasharedresponsibil-

itybetweensupplierandcustomer.

Publishing and DisseminationThecontrolsforproductdeliveryare

similartothoseforthereceiptofcode

componentsfromsoftwaresupplierstothe

softwarevendorasdescribedintheSourc-

ingsectionofthispaper.However,additional

securityneedsariseoncethesoftware

productiscomplete.Theseincludestate-

of-the-artanti-malwarechecksandthe

availabilityofamechanismthatprovides

awayforcustomerstoassurethemselves

oftheintegrityofthedeliveredpackage.

MalwareScanning

• Productsshouldbescannedformalware

usingthemostrecentmalwaresignature

filesandmorethanonecommercialscan-

ningengine.Asmentionedearlierand

dependingonthenatureoftherelationship,

itmaybeappropriatetocommunicatewhat

scanningwasdonepriortothehandover.

CodeSigning

• Thesoftwarevendor’sproductshouldbe

stronglydigitallymarkedwiththesoftware

vendor’sidentityinawaythatcan’tbe

altered,yetmaybeverifiedbycustomers.

Delivery

• Avendor’sprocessfordelivering

productsbothonlineandthroughdis-

tributionsusingphysicalandelectronic

mediashouldbesecured.Informa-

tiononcodesigningandchecksums

shouldbeavailabletocustomers.

Transfer

• Transferproductsinsuchawaythatthe

receivercanconfirmthattheproduct

iscomingfromthesoftwarevendor.

Authenticity ControlsForalltheworkthatsoftwarevendorsdo

inensuringtheyproduceaqualityproduct

freefromvulnerabilities,thereremains

residualsupplychainriskaftertheproduct

hasbeenreleased.Millionsofcustomers

everyyearunsuspectinglyacquirecoun-

terfeitsoftware.AccordingtotheBusiness

SoftwareAlliance,overoneinfivesoftware

packagesarecounterfeitorpirated.2

Whilenotacentralfocusofthis

paper,authenticityoranti-

counterfeitingcontrolsare

oneofthethreeessential

elementsofsoftware

assuranceandthus

aretightlyintegrated

withsoftwareintegrity

controls,especiallyas

2.BusinessSoftwareAlliance,“SixthAnnualBSA-IDCGlobalSoftwarePiracyStudy,”May12,2009.

Integrity

ASSURANCE

Security

Authenticity

18

softwareispreparedfordelivery.Thus,it

isimportanttohighlightthekeyauthentic-

itycontrolsusedbysoftwarevendorsinthe

softwaredeliverylinkofthesupplychain.

Counterfeitproductsoftenlookauthentic,

buttheyposeseriousriskstocustomers.

Counterfeitsoftwarecannotbeassuredto

functionasintendedandoftencontains

maliciouscodeaimedatdatadestructionor

theft.Protectingcustomersandbusinesses

fromtherisksofcounterfeitsoftwarerequires

bothengineeringeffortsbysoftwarevendors

andawarenessandrecognitionbyacquir-

ersandendusers.Theriskofcounterfeit

softwarecanbegreatlyreducedthrough

purchasefromonlyauthorizedresellers,

carefulexaminationofproductpackagingand

media,andtechnologytonotifyuserswhen

theymaybevictimsofcounterfeitsoftware.

CryptographicHashedorDigitallySignedComponents

• Asmentionedabove,digitallysigned

componentsorchecksumhashesarean

essentialauthenticitycontroltoprove

thatcomponentsaregenuine.Withany

systemtherearecharacteristicsofthe

softwarebeingshippedthatarestable,

whiletheremaybeotheritemsthatvary

withparticularconfigurationoptions

asinstalled.Todaythe“signing”ofan

applicationprovidesacapabilitytodetect

thatanapplicationhasnotbeentam-

peredwithsincethetimeitwassigned.

Vendorsmustfindtherightbalanceand

offerproofofauthenticityforthemany

predictableaspectsofthesoftware.

NotificationTechnology

• Withavarietyofdistributionchannels

forsoftware,includingonlinedistribution,

customersoftencan’ttellthattheyhave

acounterfeitproductuntilitisinstalled

ontheircomputer.Vendorscanleverage

technologytodetectcertainaspectsof

theproduct’sintegrityandnotifytheuser

ifthesoftwareisdeemedtobecounter-

feit.Sometimesintroducedbyvendorsto

preventlicensepiracy,thistechnologyhas

evolvedintoaneffectiveintegritycontrol.

AuthenticVerificationduringProgramExecution

• Inpractice,theintegrityofanapplica-

tioncanbeverifiedwhentheapplication

isinstalledonacomputer.Additionally,

eachtimeanapplicationrunsonauser’s

computer,similartechnologycanverify

theintegrityofthefilesthatmakeupthe

application.Thehardwareandsoftware

technologyusedtoverifytheclaims

applicationsandfilesmakeabouttheir

validityandintegrityiswellunderstood,

efficientandbroadlyavailable.Software

vendorswhoalreadymakeuseofthis

technologyhaveinvestedinhardware,

software,peopleandprocess,effec-

tively“codesigning”theirapplications.

19

• Avendorwiththerighttechnology

toolscaneffectivelypre-authorizethe

programexecutionofonlyaspecific

setofapplicationsfroma“good”list,

effectivelyblockinganynewlyspawned

codethatmaynotbelegitimate.

Product Deployment and Sustainment in the EcosystemThesoftwarelifecycleextendsbeyonddelivery

oftheinitialsoftwarevendor’sproductand

intotheproduct’ssustainmentormainte-

nancephase.Asaresult,patchesandhot

fixesshouldbesubjecttothesamesoftware

integritycontrolsastheoriginalcode.

Itisimportantthatauthorizedserviceperson-

nelwithongoingaccesstogenuinepartsand

properdisposalproceduresareinvolvedin

thesustainmentprocess.Authorizedaccess

shouldconveythatthepersonactivelyworks

forthecompanyprovidingtheserviceand

thatservicepersonneldon’thavemore

privilegesontheinstalledenvironmentthan

thoseneededtocompletethetaskathand.

Allservicetransactionsshouldprovideevi-

dencethatlegitimateservicepersonneldid

thework,andevidenceshouldbeavailable

forauditandprotectedagainsttampering.

SecureConfigurations

• Wheneverpossible,softwarevendors

shouldshipproductswithasecure

configurationbeingsetasthedefault

configuration.Secureconfigurationsforthe

suppliedsoftwareshouldbedeliveredto

thecustomeralongwithanoutlineofthe

riskimplicationsoftheconfigurationstate

orchoicesdetailed.Thefutureofbroader

adoptionofmachinereadableSCAP

compliantconfigurationswillstrengthen

thisarea’scontributiontointegrity.

CustomCodeExtensions

• Softwaredesignedtobeintegratedand

extendedtodeliveradditionalfunctionality

createsanotherlinkinthesupplychain.

Assumethattheoriginalsoftwareandits

interfacesweresecure,fullyfunctional

anddeliveredwithintegrityandauthentic-

ity.Softwarecomponentsthatareadded

latertoextendthefunctionsofanIT

Systemmustbealsobetreatedwiththe

samecareasoriginallyappliedbythe

internaldevelopmentandtestingofits

supplier.Integratorsmustfollowsecure

developmentpracticesastheyextend

codefunctionalitythroughtheprovided

secureinterfaces.Inaddition,tocontinue

integrity,theircomponentassetsshould

becatalogedinarepository,accessto

coderestrictedbasedon“need-to-know”

andpeerreviewsimplemented.The

chainofcustodymustbepreservedwith

thesecontrolsasthesetsofproducts

areassembledforthesolutiontobe

deliveredtotheultimateendcustomer.

Resellersorsystemsintegratorsoften

managethislinkinthesupplychain.

20

Table1:SummaryofSAFECodeSoftwareSupplyChainIntegrityControls

Processes Controls

Softwaresourcing

Vendorcontractualintegritycontrols

•Definedexpectations

•Ownershipandresponsibilities

•Vulnerabilityresponse

•Securitytraining

Vendortechnicalintegritycontrolsforsuppliers

•Securetransfer

•Sharingofsystemandnetworkresources

•Malwarescanning

•Securestorage

•Codeexchange

Softwaredevelopmentandtesting

Technicalcontrols

•Peoplesecurity

•Physicalsecurity

•Networksecurity

•Coderepositorysecurity

•Buildenvironmentsecurity

Securitytestingcontrols•Peerreview

•Testingforsecurecode

Softwaredeliveryandsustainment

Publishinganddisseminationcontrols

•Malwarescanning

•Codesigning

•Delivery

•Transfer

Authenticitycontrols

•Cryptographichashedordigitallysignedcomponents

•Notificationtechnology

•Authenticverificationduringprogramexecution

Productdeploymentandsustainmentcontrols

•Patching

•Secureconfigurations

•Customcodeextension

21

Future DirectionsAssoftwareintegrityremainsanemerg-

ingdiscipline,thereareanumberof

areasthatSAFECodebelievesdeserve

furtherstudyandindustrycollaboration.

Theseinclude,butarenotlimitedto:

SupplierManagementandCommunicationalongtheSupplyChain

• Theworkthatthesoftwareindustryhas

undertakentoidentifyandimplement

securecodingpractices,includingthe

findingspresentedinSAFECode’s“Fun-

damentalPracticesforSecureSoftware

Development”paper,takesonnew

implicationswhenexaminedalongthe

supplychainfromonesuppliertoanother.

Thesesecuritypracticestogetherwith

normalqualitycontrolconcernscould

bereexaminedinthecontextofthe

exchangeofsoftwareandrelatedinfor-

mationfromonesuppliertoanother.

ResearchonSoftwareTesting

• Asdiscussedpreviously,automatedtest-

ingcurrentlyislimitedinitsabilityto

detectmaliciouscodethatisintentionally

insertedandwelldisguisedaslegitimate.

Essentially,todayautomatedtestingcan

onlydetectmalwarethatusecoding

patternsthathavebeenseenpreviously.

Increasingthecapabilityofsoftwaretest-

ingofsourceandbinarycodetoidentify

vulnerabilitiesisanareaworthyoffuture

researchanddevelopment.Additional

behavioralanalysisofapieceofcodemight

beapromisingnewapproachsimilarto

whatisalreadyimplementedinsomeof

today’santi-virusdetectionsoftware.

AuthenticityEaseofUse

• Whilecryptographycanbeappliedwith

checksums,digitalcertificatesandsigna-

turesandvalidatedtimestamps,theuser

experiencetoverifylegitimatesoftware

canbeconfusinganddaunting.Usersneed

fareasiermeansofvalidatingauthenticity

sothattheyarenotprimarilyfocusedon

clearingtheirscreensofanydistractions

togetonwiththetasksathand.Since

socialengineeringattackssometimescount

onusersdismissingwarningsorerrors,

ongoingworkinthisareaisimportant.

AuthenticSoftwareatRuntime

• Howcanend-usersassurethemselvesthat

allsoftwarerunningontheirmachinesis

authenticandtrustworthy?Onepromising

technologyadvancementistheTrusted

PlatformModule(TPM),ahardwarecompo-

nentthatcanbeintegratedwithasigned

operatingsystem,signedapplicationsand

signedadd-instoprovideanenduserthe

assuranceatruntimethatallcomponents

areauthentic.However,forTPMstobe

trulyeffective,allsoftwaremustbesigned.

Somevendors,bothcommunity(open

source)andproprietary,havetakensteps

toenablethistechnology.However,an

22

industry-wideeffortisnecessarytoachieve

thisvisionasthecomputersusedbyend

userscontainaneclecticcollectionof

softwaresourcedfromavastecosystemof

vendors,suppliersandcommunities.The

TrustedComputingGroup(www.trusted-

computinggroup.org)isanexampleofan

organizationactivelyaddressingthisissue.

MoreComprehensiveDataonToday’sPracticesandControls

• WhileSAFECodehasofferedthebest

thinkingofitsmembercompaniesinthis

importantemergingarea,thefieldcould

befurtheredbycapturingbroaderdata

fromalargersegmentofinformation

technologyvendorsabouttheircur-

rentorpreferredpracticessothatthe

overallcommunityisguidedbydataas

continuousimprovementsaremade.

SoftwareIntegrityandCloudComputing

• Theimpactofcloudcomputingonthe

“traditional”viewofsoftwaresupply

chainrisks,asaddressedinthispaper,

needstobeassessed.Softwarepos-

sessesmanyofthesamecharacteristics

inherentinotherformsofintellectual

property.Asaresult,issuesassociated

withjurisdiction,accessauthorizationand

complianceneedtobeassessedfortheir

impactonsoftwareintegritycontrols.

BroaderCollaborationwithSupplyChainManagementCommunity

• Whilethewell-establishedandmature

supplychainmanagementcommunity

isbecomingawareoftheseemerging

threatstotheITsystemsupplychain,

thereisroomforgreatercollaboration

aroundasharedunderstandingofthe

challenges,commonterminologyand

existingdisciplinesthatcanbeleveraged

acrossanevenbroadercommunity.

Measurement

• SAFECodeiscurrentlyexaminingitsmem-

bers’practicesonmeasuringsoftware

assurance.Asthatworkevolves,there

aresuretobeimplicationsforimprov-

ingtheexchangeofintegrity-related

measuresamongtradingsuppliers.

23

ConclusionSAFECodeviewssoftwareintegrityasa

fundamentalpillarofsoftwareassurance.

Protectingtheintegrityofsoftwarerequires

asetofcontrolsthatshouldbeimplemented

alongsidesecuredevelopmentandauthentic-

itypractices;indeed,integritypreservesand

supportssecurityandauthenticityacross

thecomplexityofasupplychain.However,

resourcesandbestpracticesforidentifying

andanalyzingsoftwareintegritycontrolsare

notyetwidelyavailable,creatingchallenges

forbothsoftwarevendorsandcustomers.

Whileasoftwarevendorisonlyonelinkin

acomplexITsolutionsupplychainandhas

alimitedabilitytoinfluencetheactionsof

theotherentitiesalongthechain,allsoft-

warevendorshaveboththeopportunityand

responsibilitytoprotecttheintegrityofthe

softwareasitmovesthroughthelinkthey

control.Thisrequirestheapplicationofsoft-

wareintegritycontrolstoavendor’ssoftware

sourcing,developmentanddeliveryprocesses.

SAFECodebelievestheindustry-wideadoption

ofsoftwareintegritycontrolshasthepotential

togreatlyimprovecustomerconfidencein

ITsystems.Ithaspublishedthiscollection

ofbestpractices,whicharebasedonthe

lessonsitsmembershavelearnedintheir

individualimplementationofthesecontrols,

inanefforttoprovideguidancetoothers

intheindustry.SAFECodeencouragesthe

softwareindustrytotailorandadoptthese

controls,aswellascontinuefurtherstudyand

analysisonadditionalpracticesandcontrols

toimprovesoftwaresupplychainintegrity.

AcknowledgmentsBradArkin,AdobeSystemsIncorporated

EricBaize,EMCCorporation

MattColes,EMCCorporation

RobertDix,JuniperNetworks,Inc.

YuecelKarabulut,SAPAG

PaulNicholas,MicrosoftCorporation

GaryPhillips,SymantecCorporation

TysonStorch,MicrosoftCorporation

KevinSullivan,MicrosoftCorporation

JanneUusilehto,Nokia

About SAFECodeTheSoftwareAssuranceForumforExcellence

inCode(SAFECode)isanon-profitorganization

exclusivelydedicatedtoincreasingtrustininfor-

mationandcommunicationstechnologyproducts

andservicesthroughtheadvancementofeffective

softwareassurancemethods.SAFECodeisaglobal,

industry-ledefforttoidentifyandpromotebest

practicesfordevelopinganddeliveringmoresecure

andreliablesoftware,hardwareandservices.Its

membersincludeAdobeSystemsIncorporated,

EMCCorporation,JuniperNetworks,Inc.,Microsoft

Corp.,Nokia,SAPAGandSymantecCorp.For

moreinformation,pleasevisitwww.safecode.org.

©2010SoftwareAssuranceForumforExcellenceinCode(SAFECode)

(p)703.812.9199

(f)703.812.9350

(email)stacy@safecode.org

www.safecode.org

SAFECode

2101WilsonBoulevard

Suite1000

Arlington,VA22201