threat modeling for secure - bitpipedocs.media.bitpipe.com/io_10x/io_101235/item_435761/...threat...

ThreatModelingforSecureEmbeddedSoftware

Asembeddedsoftwarebecomesmoreubiquitousandconnected–poweringeverythingfromhomeappliancesandcarstoaircraftandmission-criticalsystems–organizationsmusttakeadditionalstepstoensurethatthecodeproducedisbothsecureandreliable.Embeddedsoftware,however,presentsauniquesetofchallengesforapplicationdevelopmentandengineeringteams.Tocombatembeddedsoftwarethreats,teamsareturningtostrategiessuchasthreatmodeling,staticanalysisandpenetrationtestingtosecuretheirembeddedcode.

Softwaredevelopers’greatestchallengesinproducingsecureembeddedcodearerootedinthenatureofthedevicesthatrunthesoftware:

»» They are resource-constrainedandhaveless“room”tocompensateforCPU-ormemory-robbingattacks.Asaresult,theyareeasilysusceptibletodenialofserviceattacks.

»» Their performance can be slowed by cryptography.Tospeedperformance,embeddeddevelopersdonotincludesecurenetworkingprotocolsonembeddeddevicesasoftenastheydoontheirdesktopcounterparts.

»» Their fi rmware can be changed.Knowledgeableuserscanswapoutexistingembeddedfirmwareandreplaceitwithanoperatingsystemoftheirchoice.

»» They are only intermittently connected to a network.Inconsistentnetworkconnectionsreducethelikelihoodthatsecuritypatcheswillbekeptup-to-date,andincreasethechancethatthedevicewillaccessanunsecurenetwork.

»» They are easy to steal due to their small physical size.Intheory,anattackercouldswaponeembeddeddeviceforanotherandloadmaliciousinformationintoasystem.

Thispaperwillexaminethreatmodelingandexplainhowitcanbeusedinconcertwithsecuredevelopmentbestpractices,includingautomatedsourcecodeanalysis,peercodereviews,andpenetrationtestingtobothidentifyandmitigateembeddedsoftwarethreats.

SECURITYINNOVATION&KLOCWORKWHITEPAPER | JUNE2011

WWW.KLOCWORK.COM

Breaking Embedded Software News

“Google Confesses Android Security Breach, Rolls Out Fix”

“Sony Announces PS2 BankSecurity Breach”

“Microsoft Warns Xbox Live Users of Security Threat”

“RSA Offers to Replace TokensAfter Attack”

Threat Modeling for Secure Embedded Software | Klocwork White Paper | 2

ThreatModeling–ABriefOverview_ ___________________________________________________________________________

Threatmodelingisasecurityengineeringactivitythatdocumentsthekeyassetsfoundinanapplicationorsystemandpurposelyexposesriskstothoseassetsinathoroughanddisciplinedmanner.Thegoalofathreatmodelistoshinealightuponhiddensecurityrisksthatmaynotbeobviousoranticipatedbythedesignteam.Thisinformationcanthenbeusedtodevelopariskmanagementstrategyandprovidearoadmapforfuturesecurityengineeringactivities.

Byidentifyinganapplication’spotentialvulnerabilities,threatmodelinghelpsdevelopmentteamstounderstandandprioritizethearrayofrisksforwhichthesoftwareissusceptible.Withtheresultsofathreatmodelinhand,developmentteamscanensurethattheyareconcentratingtheirdesign,developmentandtestingtechniquesontherisksthatmattermost.

Benefits of Threat ModelingThreatmodelingisoneofthemostpowerfulsecurityengineeringactivitiesbecauseitfocusesonactualthreats,notsimplyonvulnerabilities.Athreatisanexternaleventthatcandamageorcompromiseanassetorobjective,whereasvulnerabilityisaweaknesswithinasystemthatmakesanexploitpossible.Vulnerabilitiescanberepaired,butthreatscanliveonindefinitelyorchangeovertime.Threatmodelingfacilitatesarisk-basedsoftwaredevelopmentapproachbyuncoveringexternalrisksandencouragingtheuseofsecurecodingpractices.

Inparticular,threatmodelinghelpsdevelopmentteamsto:

»» Assesstheprobability,potentialharm,andpriorityofattacks»» Prioritizesecurityeffortsaccordingtotruerisk»» Shapeanapplicationdesigntomeetsecurityobjectives»» Identifywhereadditionalsecurityresourcesarerequired»» Weighsecuritydecisionsagainstotherdesigngoals»» Improvethesecurityofanapplicationbyimplementingeffective

countermeasures»» Understandattackvectorsforpenetrationtesting»» Understandtheconditionsunderwhichanattackmaybesuccessful

Byhelpingdevelopmentteamstoidentifyandunderstandpotentialthreats,threatmodelingprovidestheessentialinformationneededtoplananembeddedsoftwaresecuritystrategy.

Caveat to Threat ModelingItisimportanttonotethatthreatmodelingisnotanattackplan,atestplan,aformalproofofsystemsecurity,oradesignreview.Threatmodelinginformsthoseplansandreviewsbyofferingdeepinsightintothemethodsattackerscouldusetomanipulateembeddedsoftware.Threatmodelingisthereforeakeycontributortodesignreviewandtestplanning,butshouldnotbeconsideredasubstituteforthoseactivities.

CreatingaThreatModel_____________________________________________________________________________________________

Developingathreatmodelisateameffort,butworksbestwhenthemodelingexerciseisledbyadesignerwithsecurityexpertise.Thefollowingactivityoverviewoutlinesanefficientandrepeatableprocedureformodelingthreatstoembeddedsoftware.

Step 1: Identify Security ObjectivesFirst,theteammustclarifythedesiredlevelofsecurity.Isthegoaltopreventanyandallsecuritybreaches?Arecertainattackspermissible?Preventingeverypossibleattackmaynotbepossibleorcost-effective,soitisimportanttodeveloprealisticobjectivesthatbalancesecurity,costandeffort.

“By helping development teams to identify and understand potential threats, threat modeling provides the essential information needed to plan an embedded software security strategy.”

Threat Modeling for Secure Embedded Software | Klocwork White Paper | 3

Step 2: Create a System OverviewOnceitssecurityobjectivesareclear,thedevelopmentteamshouldexamineitssoftwareapplicationandidentifyeachassetofvalue.Assetsofvaluearecomponentsthatanattackerwouldvalueandwhichthereforeneedtobeprotected.Examplesinclude:

»» Dataassetssuchascreditcardnumbers»» TechnologyassetssuchasintellectualpropertyorcontentunderDigital

RightsManagement»» Softassetssuchasbusinessreputationandcustomertrust.Certain

attacks,suchasdefacement,canhaveaminorimpactonhardassetsbutcandramaticallyreducecustomerconfidenceinanorganization’sabilitytodevelopareliable,trustworthyproduct.

Step 3: Isolate and Decompose the Device’s Software DesignWhileproductdevelopersarenormallyconcernedwithusecases,athreatmodelencouragestheteamtothinkaboutabusecases.Anabusecaseisanattackscenarioinwhichamalicioususerwishestoabuse,ratherthanuse,asystem.Thethreatmodelingprocesshelpstogenerateabusecasesby“decomposing”adevice’ssoftwaredesigntoisolatetheareasmostsusceptibletoabuse.

Whenbrainstormingonabusecases,consider:

»» Thedata on the deviceanddatainsystemsthatcanbeaccessedbythedevice.

»» Theinput sourcesthatcouldbeusedtoattackthedevicesoftware.Thesecouldincludenetworkdatastreamstothedeviceoperatingsystem,installedapplications,GPSsignals,andcellularvoice/dataentry.

»» Physical challengesthatcouldariseifthedevicefindsitswayintothehandsofanattacker.Forinstance,howwouldyouprotectsensitivedataifthedeviceisstolen?

Afterenumeratingtheassetsofvalueanddecomposingthedevice’ssoftwaredesign,adevelopmentteamcangenerateathoroughlistofthreatsthatcouldnegativelyimpactthedeviceorsystem.

Step 4: Identify ThreatsThegoalofthethreatmodelingexerciseistoidentifyasmanythreatsaspossible.Todothis,developmentteamsshouldusethe“CIAmethod”andconsidertheeventsthatwouldimpacttheConfidentiality,Integrity,orAvailabilityofeachasset.

Manydevices,forexample,revealgeographicinformationabouttheuser.The“GoogleLatitude”functiononasmartphonecanrevealauser’sphysicallocation,andalogof“cardholderpresent”creditcardtransactionscanidentifyauser’smovements.Deviceswithembeddedsoftwareoftenlogaccesstosystemresources.Whencompromised,thisinformationcanprovideablueprintofinterestingandvaluableinformationonthedevice.

Onceadevelopmentteamhasidentifiedanyandallthreatsthatcouldcompromisetheconfidentiality,integrityandavailabilityofitsassets,itmustconsiderthetypeofattacksthatcouldbeusedtorealizeeachthreat.Themostefficientwaytoidentifypotentialattacksistodevelopan“attacktree”foreachthreat.

Anattack treeisavisualtoolthatdocumentsthreatsandattacksforanasset,asshowninFigure2.Thethreatisdocumentedatthetopofthetreeanditisfollowedbyasetofbranchesthatrepresentpotentialattackmethods.Thesebranchesarethenfurthersubdividedtoidentifytheconditionsortechniquesthatcouldbeusedinasuccessfulattack.

“While product developers are normally concerned with use cases, a threat model encourages the team to think about abuse cases.”

Threat Modeling for Secure Embedded Software | Klocwork White Paper | 4

Intheaboveexample,thethreattreenotonlyidentifiesthetypeofattacksthatarepossiblewhenanattackerimpersonatesauser,italsoliststheconditionsandtechniquesunderwhichasuccessfulattackcouldtakeplace.Thisinformationcanbeusedinthenextstepofthethreatmodeltoidentifythespecificvulnerabilitieswithintheembeddedcode.

Step 5: Identify VulnerabilitiesAgoodthreattreewilllistalloftheconditionsunderwhichanattackcouldbesuccessful.Imaginethatathreatmodelhashighlightedthatcreditcardinformationcouldbeobtainedfromthesystemviaa“man-in-the-middleattack”onacommunicationchannel.Inthiscase,theattacktreewouldshowthattheattackcouldbesuccessfulifcreditcardinformationistransmittedoverthedatachannelincleartext.Ifthedevelopmentteamfindsthatthisconditionismetinitssystem,itshoulddevelopamitigationstrategytoblocktheattack.Ifthatconditionisnotmet,anattackisnotpossibleandtheteamcanconcentrateitseffortselsewhere.

Attheendofthisprocess,thethreatmodelwillcomprisealistofvulnerabilitiesthatcanbeusedtoplananattackmitigationstrategy.

Step 6: RepeatThreatmodelsareorganicdocumentsandshouldberevisitedfrequently.Conditionschange,designschange,andthethreatlandscapechanges.TheDVDworld,forexample,providesanexcellentexampleoftheneedforcontinuousthreatmodeling.WhenDVDplayerswerefirstcreated,thekeysforDVDDigitalRightsManagement(DRM)wereincludedintheactualDVDplayerhardware.Hardwareplayerswereinitiallytamper-proof,buttheintroductionofsoftwareDVDplayersmadeitmucheasierforattackerstoreverse-engineerthekeysandbreaktheencryption.

TheoriginalthreatmodelforanearlyDVDplayerwouldhavelistedonlytheoriginalthreat:“DVDContentisStolen”,anditsmitigation:“DVDcontentisencrypted,encryptionkeysarestoredintamper-proofhardware”.Withtheintroductionofsoftwareplayers,thethreatmodelhadtobeupdatedtoidentifyandmitigatethenewrisks.

Figure 2 | Sample Attack Tree for an impersonation threat

Client/UI Threat #4:Attacker

Impersonates User

Spoof authentication token/transaction

ID

Bypass the client application/UI to create

transaction

Modify the audit trail so that it appears that a

different user conducted the transaction

Attempt to intercept credentials during their

transmission

Attempt to discover credentials left in

memory

Attacker discovers another user’s

credentials

Threat Modeling for Secure Embedded Software | Klocwork White Paper | 5

Threat Modeling - Activity Summary TableInput Step Output

• Businessrequirements• Securitypolicies• Compliancerequirements

Step 1: Identify security objectives

• Keysecurityobjectives

• Deployment diagrams• Use cases• Functional specifications

Step 2: Create a system overview

• Whiteboard-style diagram with end-to-end deployment scenario

• Key scenarios• Roles• Technologies• Application security

mechanisms

• Deployment diagrams• Use cases• Functional specifications

Step 3: Isolate and decompose your device design

• Trust boundaries• Entry points• Exit points• Data flows

• Common threats Step 4: Identify threats

• Threat list

• Common vulnerabilities Step 5: Identify vulnerabilities

• Vulnerability list

Figure 3 | Threat Modeling Activity Summary Table

PuttingitintoPractice:Identifying&MitigatingVulnerabilitiesinCode_ ___________________________

Whilethreatmodelingcanuncoverthebroadthreatsandvulnerabilitiesofanembeddedsystem,itcannotmitigatethosethreats.Todoso,developmentteamsmustpracticedefensivecoding,engageinfrequentcodereviews,andperformpenetrationtesting.

Code DefensivelyDefensivecodingisaformofdesignthataimstoensurethecontinuingfunctionofsoftwareandsourcecodeinspiteofmisuseorabuse.Whileathreatmodelcanidentifyvulnerabilitiesduetodesign,acertainpercentageofvulnerabilitieswillalwaysresultfromcodingflaws.

Developersoftenfindthatmanyofthevulnerabilitiesidentifiedinthethreatmodelresultfromonlyahandfulofcodingerrors.Onesimpleinsecurecodingtechniquethatisperformedrepeatedlycancontributetodozensofvulnerabilities.Hackersfrequentlyexploitthebest-knownvulnerabilities,sodevelopersthatcodedefensivelyandeliminatethemostcommoncodingflawscansubstantiallyreducetheriskofasuccessfulattack.

Moreover,threatmodelingoftenuncoversthreatsthatcanonlybemitigatedthroughgoodcodingpractices.If,forexample,anorganizationhasidentifiedathreatthatrequiresacentralizedinputanddatavalidationstrategy,itwillrequirecode-levelfixestoaccomplishthevalidation.Theseprinciplesmightincludevalidatingallinputforlength,range,formatandtype.

Byfollowingdefensivecodingpractices–mostnotably,theuseofautomatedtoolstoidentifyweakcodingpracticesanduncovervulnerabilities–developmentteamscandramaticallyreducethefrequencyandimpactofbadcode.

Threat Modeling for Secure Embedded Software | Klocwork White Paper | 6

Automated Source Code AnalysisAutomatedsourcecodeanalysis(SCA)toolsprovideahighreturnoninvestmentforanysoftwaredevelopmentorganizationbyhelpingtoeliminatebugsearlyinthedevelopmentcycle.Industryestimatesholdthatthecostofaddressingacodedefectafterabuildis10timeshigherthanaddressingitduringdevelopment.Whileautomatedprogramsdonotremovetheneedformanualcodetesting,theycandramaticallyreducethetimespentoncodereviewsandfocusmanualtestsonthemostimportantand“hardest-hitting”issues.

Staticanalysistools,forexample,canidentifyhundreds–ifnotthousands–ofcodingproblems.Theseinclude:

»» Common vulnerabilitiessuchasbufferoverflows,uninitializeddata,useofdanglingpointers,injectionflawsandknowninsecureAPIsandlibraries.

»» Secure coding guidelinessuchasCWE,CERT,DISAandOWASP,aswellasanycustomchecksorguidelinesthatwouldbeuniquetoyourcodebase.

»» Reliability-related concernssuchasmemoryleaks,memoryallocation,resourcemanagementandmore.

»» Long-term maintainability concernssuchasarchitecturalviolations,deadcode,unusedlocalvariables,andothercodingstylebestpractices.

Byincorporatingautomatedstaticanalysistoolsorganizationscansimplifyexistingpeerreviewprocessesandautomateanumberofcodereviewactivities.Moreover,byrunningthisanalysisearlyinthesoftwaredevelopmentprocess,developerscaneliminatesimplemistakesbeforetheymakeitintothecodestream.

Infact,staticanalysistoolsareidealforeducatingdevelopersaboutthecodingproblemslistedabove.Mostdevelopersarenotsecurityexperts,butsourcecodeanalysistoolscanhelptoinformandeducatedevelopersofthemostcommonsecurityissues.Byexaminingstaticanalysisresults,developerscanidentifythefrequentproblemsand,overtime,makeimprovementsintheirprocessestoavoidthem.

Itisimportanttonote,however,thatstaticanalysiscanonlyidentifyspecificcodingproblems.Itisuptothedevelopmentteamtodecidewhetherthoseproblemsneedtobeaddressed.Thatdecisiondependsonestablishedtrustboundariesandthecosts/benefitsassociatedwiththerepairs.Developmentteamscanspeedthesedecisionsbyconsultingthethreattreesestablishedduringthethreatmodelingprocesstodeterminewhetherthevulnerabilitiesrepresenttruethreatstothesystem.

Engage in Frequent Code ReviewsSecuritycodereviewsarecriticalinthedevelopmentofsecurecode.Theyunveilvulnerabilitiesthataredifficulttodiscoverthroughtestingprocessessincetheyexaminethesourcecodedirectlyandreviewcodepathsdeepinsideanapplication.Throughafocusedanditerativeapproachtocodereviewthatconsistsofbothmanualandautomatedinspection,codereviewscanbeperformedasoftenaseverycheck-intodiscoverbugsbeforetheymakeitintothebuild.Thesefrequentcodereviewsnotonlyidentifyadditionalvulnerabilities,theyalsoallowdeveloperstogainexperienceandlearncollectivelyfromtheirmistakes.

Toperformaneffectivecodereview:

1. Identify code review objectives.Consultthethreatmodeltoprioritizerisksandidentifythemostimportantvulnerabilities.

2. Perform a preliminary scan.Usebothcontrolflowanddataanalysestostepthroughlogicalconditionsinthecode,understandtheconditionsunderwhicheachblockwillbeexecuted,andtracedatafromthepointsofinputtothepointsofoutput.

“Most developers are not security experts, but source code analysis tools can help to inform and educate developers of the most common security issues.”

Threat Modeling for Secure Embedded Software | Klocwork White Paper | 7

3. Review for common issues.Scanembeddedcodeforcommonvulnerabilitiesarounddataaccess,inputanddatavalidation,authentication,physicalpossessionandreplayattacks.

4. Review for unique issues.Consultthethreatmodelandscanembeddedcodeforvulnerabilitiesthatmaybeuniquetotheparticularsystem,deviceorapplicationinquestion.

Codereviewshouldbestartedearlyinthesoftwaredevelopmentprocessandrepeateduntiltheteamissatisfiedwiththeresultsoruntilapre-establishedtimelimithasbeenreached.Attheendofthisprocess,thedevelopmentteamwillhaveasetofprioritizedvulnerabilitiesandinspectionquestionsinhandthatitcanusetomakefuturereviewsevenmoreeffective.

Perform Security TestingSecuritytestingshouldbeoneofthefinalstepsperformedinanembeddedsoftwaresecurityproject.Throughapenetration test,developmentteamscangainconfidencethattheirearlierdesignreview,threatmodelingandcodereviewactivitieshavehardenedthesoftwareagainstattack.Ifteamshavefollowedthesecuritybestpracticesoutlinedinthiswhitepaperthroughoutthedevelopmentlifecycle,theproblemsthattheywillidentifyduringthisfinalstagewilltypicallybeminorandsimpletoremedy.

Whenanapplicationisreadyforapenetrationtest,leveragethethreatmodeltoimprovethetestplan.Usethethreatmodeltodetermineattackvectorsandconditionsunderwhichtheattacksmaybesuccessful.Securityvulnerabilitiescanbesubtle,sobesuretoconsiderallsignsofasuccessfulattack,suchasanunexpectedchangetoafilesystem,orunexpectednetworktraffic.

Likeacodereview,asecuritytestcanalsousebothautomatedandmanualtools.AutomatedSCAtoolscanbeusedtospeedanalyses,andmanualtestingtechniquescanbeemployedtobothdiscoverandaddresselusivevulnerabilities.

TheImportanceofThreatModeling____________________________________________________________________________

ModernembeddedsystemsareapproachingthecomplexityofatraditionalPCwhileintroducingadditionalcomplexitiesrelatedtoconnectivityandresourceconstraints.Throughtheuseofkeysecurityengineeringactivitiesincludingthreatmodeling,codereviews,codingbestpractices,andsecuritytesting,developmentteamscandetectandaddresssecurityvulnerabilitiesintheirembeddedcodequickly,efficientlyandpriortoproductrelease.

AboutKlocworkandSecurityInnovation_____________________________________________________________________

Klocwork®offersaportfolioofsoftwaredevelopmentproductivitytoolsdesignedtoensurethesecurity,reliabilityandmaintainabilityofcomplexcodebases.Usingprovenstaticanalysistechnology,Klocwork’stoolsidentifycriticalsecurityvulnerabilitiesandreliabilitydefects,optimizepeercodereview,andhelpdeveloperscreatemoremaintainablecode.Klocwork’stoolsareanintegralpartofthedevelopmentprocessforover850customersintheconsumerelectronics,mobiledevices,medicaltechnologies,telecom,militaryandaerospacesectors.Visitwww.klocwork.comtolearnmore.

SecurityInnovationisanestablishedleaderinthesoftwaresecurityandcryptographyspace.Foroveradecadethecompanyhasprovidedproducts,trainingandconsultingservicestohelporganizationsbuildanddeploymoresecuresoftwaresystemsandprotecttheirdatacommunications.VisitSecurityInnovationatwww.securityinnovation.com.

IN THE UNITED STATES:15 New England Executive ParkBurlington, MA 01803

IN CANADA:30 Edgewater Street, Suite 114Ottawa, ON K2L 1V8

t: 1.866.556.2967f: 613.836.9088www.klOCwOrk.COm

AppendixA:ThreatModelingChecklist______________________________________________________________________

1) Create a Threat Model»» IdentifySecurityObjectives»» CreateaSystemOverview»» IsolateandDecomposetheDevice’sSoftwareDesign»» IdentifyThreats»» IdentifyVulnerabilities

2) Code Defensively»» Lookfor“traditional”vulnerabilitiessuchasbufferoverflows,uninitialized

data,useofdanglingpointers,injectionflawsandknowninsecureAPIsandlibraries.

»» Scanforquality-relatedconcernssuchasmemoryleaks,memoryallocation,resourcemanagementandmore.

»» Examinelong-termmaintainabilityconcernssuchasarchitecturalviolations,deadcode,unusedlocalvariablesandothers.

»» Identifypoorcodestylesandstandards.»» Uncoverlayoutissues.

3) Perform Effective Code Reviews»» Identifycodereviewobjectives»» Performapreliminaryscan»» Reviewforcommonissues»» Reviewforuniqueissues

© Copyright Klocwork Inc. 2011 · All Rights Reserved

CORPORATE HEADQUARTERS:187 Ballardvale Street, Suite A195Wilmington, MA 01887

BRANCH OFFICE:1511 3rd Ave #400Seattle, WA 98101

t: 1.877.694.1008f: 1.978.694.1666

© Copyright Security Innovation 2011 · All Rights Reserved

www.SeCurItyInnOvatIOn.COm