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
“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,qualityandmaintainabilityofcomplexcodebases.Usingprovenstaticanalysistechnology,Klocwork’stoolsidentifycriticalsecurityvulnerabilitiesandqualitydefects,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
