Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
CSCI1800CybersecurityandInterna4onalRela4ons
SecurityThroughSo;wareEngineeringJohnE.Savage
BrownUniversity
Outline
• Securitymodelingincludingaccesscontrol• Federalsecurityregula4onsandstandards• So;warevulnerabilityassessments• Microso;’sSecurityDevelopmentLifecycle• Introduc4ontoThreatAnalysis
Lect234/24/17 ©JESavage 2
Policy,ModelsandTrust
• Tohavesecuresystems,engineersneedclear– Securitygoals– Effec4veimplementa4onstrategy
• Asecuritypolicyputsconstraintsonac4onsthatcantakenbyactorsonobjectsinthesysteminordertoachievesecuritygoals.
Lect234/24/17 ©JESavage 3
SecurityPolicyComponents
• Actors– Individualorgroupagentsinterac4ngwithasystem.
• Objects– Informa4onal/computa4onalresourcesaffectedbypolicy.
• Ac4ons– Possiblemodifica4onstoobjects,e.g.read,edit,copy,remove
• Permissions– Rulesconstrainingac4onsthatactorsmaytakeonobjects.
• Protec4ons– Featuresofpolicy,e.gconfiden4ality,availability,anonymity.
Lect234/24/17 ©JESavage 4
SecurityModel
• Asecuritymodelisanabstrac4onprovidingconceptuallanguagetospecifysecuritypolicies.– E.g.Unclassified(U),Confiden4al(C),Secret(S),TopSecret(TS)
– Specialcompartmentsforspecialcompartmentalizedinforma4on(SCI),suchashumanintelligence(HUMINT),satelliteobserva4ons(GEOINT)
Lect234/24/17 ©JESavage 5
TwoModelsofAccessControl
• Discre4onaryaccesscontrol– Ownermayspecifypermissionsonfiles– Amorerelaxedformofcontrol
• Mandatoryaccesscontrol– Administratorfixespermissionsinadvance.– Morestrictcontrol
• Ruleshavesubjects(par4esreques4ngaccess)andobjects(thosethingsbeingaccessed).
Lect234/24/17 ©JESavage 6
Bell-LaPadula(BLP)AccessControlModel
• Appliestoconfiden4ality–datesfromthe1970s• ObjectxanduseruhavesecuritylevelsL(x)&L(u)– Examplesofsecuritylevels:U,C,S,TS
• Forusersuandv,vhashigherclearancethanuifL(u)≤L(v).ucanpassinfotovbutnotviceversa.
• No“readup”(usercan’tseemoresecuredata)– UserucanreadxonlyifL(x)≤ L(u)
• No“writedown”(usercan’tusemoresecuredata)– UserucanwritetoobjectxonlyifL(u)≤L(x).
Lect234/24/17 ©JESavage 7
BLPAccessControlModel
Lect234/24/17 ©JESavage 8
v
u
L(u)≤L(v)
Noreadup
Nowritedown
BLPmodelweakness:onlyhandlesconfiden4ality
KenBiba(‘77)AccessControlModel
• GoalofBiba’smodelistomaintaindataintegrity:– theaccuracyandconsistencyofdataoveritslife-cycle.
• Letl(x)andl(u)betheintegrityofuseru&objectx– ThehigherisI(u)orI(x),themoretrustworthyoraccuratetheuseruorobjectxis.
• Don’tcorruptdatabyreadingfromlowerintegritylevel,don’twritetohigherintegritylevel.
• UserucanreadobjectxonlyifI(u)≤I(x).• UserucanwritetoobjectxonlyifI(x)≤I(u).
Lect234/24/17 ©JESavage 9
Role-BasedAccessControl
• Components:users,roles,permissions,sessions– Aroleisacollec4onofusers.– Asessionisaninterac4onforaperiodof4me.
• Rolehierarchyisdefined,asinacorpora4on.– PresidentIsAmanagerIsAemployee– Higherroleuserinheritspermissionsoflowerone– Whenisthisnotagoodidea?
• Roleconstraintsmaybeimposed– Example:avoidconflictsofinterest.
Lect234/24/17 ©JESavage 10
USGSecurityStandards
• TrustedComputerSystemEvalua4onCriteria,akaOrangeBook–issuedbyDoDin1983,1985– DivisionA:systemhasaformalprocessforverifica4onofsecurity
– DivisionB:mandatoryaccesscontrol– DivisionC:discre4onaryaccesscontrol– DivisionD:minimalprotec4oncriteria
Lect234/24/17 ©JESavage 11
USGSecurityStandards
• CommonCriteriaforInforma4onTechnologySecurityEvalua4on–anISOstandard– ItsubsumestheOrangeBook– Defineskeyconceptsrelatedtosecurityevalua4ons– Frameworkfordocumen4ngsecuritygoals– Notacer4fica4onvouchingforproductsecurity.
Lect234/24/17 ©JESavage 12
GovernmentRegula4ons&Standards
• FederalInforma4onProcessingStandards(FIPS140-2)– Standardsfordesigning/handlingofcryptographicmodulesbyUSgovernmentorganiza4ons
– Lastupdatedin2002• Securitylevels:
1. Nophysicalsecurity,canrunmodulesonopenmachine2. Somephysicalsecurity,e.g.tamper-evidentcoa4ngs,some
role-basedauthen4ca4on,trustedOS3. Preventphysicaltampering,iden4ty-basedauthen4ca4on
insteadofrole-basedauthen4ca4on4. Tighterphysicalsecurity,allkeysandmessagesdestroyed
whenunauthorizedapemptstobreaksecurityaremade.
Lect234/24/17 ©JESavage 13
GovernmentRegula4ons&Standards
• HIPAA(1996)– Setsprivacystandardsonpa4entrecordsforhealthcareprovidersandemployers.
• FamilyEduca4onalRightsandPrivacyAct(FERPA)(‘74)– Requiresprotec4onofprivacyofeduca4onalrecordsinUS
• FederalInforma4onSecurityManagementAct(FISMA)– Revisedin2014–providesgovernmentinforma4onsecurity.– Itrequiresfederalagenciestoimplementprocessesandcontrolsdesignedtoensuretheconfiden4ality,integrity,andavailabilityofsystem-relatedinforma4on.
– MustfollowFISMAandNISTstandards,andlegisla4verequirements,suchasthePrivacyActof1974.
Lect234/24/17 ©JESavage 14
So;wareVulnerabilityAssessment
• Theproblem:so;warecanbeenormous– MacOSX10.4has>86millionlinesofcode!– Codecanhavebothperformance&securitybugs
• “Avulnerabilityisasecurityexposurethatresultsfromaproductweakness…theproductdeveloperdidnotintendtointroduceandshouldfixonceitisdiscovered.”*
• Howmanyerrorsper1,000linesofcode(KLOC)?– Es4matesvaryfrom5-50defectsperKLOC– Someopen-sourcehavebugdensityof.4bugs/KLOC!†
Lect234/24/17 ©JESavage 15†Measuringso;warequality,hpp://www.coverity.com/library/pdf/open_source_quality_report.pdf*Microso;defini4on
So;wareVulnerabilityAssessment
• Approachestovulnerabilityassessment:– Black-boxanalysis• Penetra4ontest(pentest)donewithoutknowledgeofinnards.
• Pentestslookforsecurityvulnerabili4es– White-boxanalysis• Samebutwithfullknowledgeofhardware/so;ware,networkenvironment,etc.
Lect234/24/17 ©JESavage 16
CodeAnalysisforPrivacy/Security
• Problem:Cybercrimeisheretostay.• Goal:Findandremoveprivacy/securityhazards.– Sta4ccodeanalysisstudiesnon-runningprograms.
• Thisiswhite-boxtes4ngofnon-runningcode.E.g.– Dynamicanalysisexaminesrunningprograms.
• Goodanalysisrequirestrainingandinvestment– So;wareengineersgenerallynoteducatedonthis.– Microso;’sSecurityDevelopmentLifecycle(SDL)representsabigstepforward.
• Benefits:Improvedsecurity,privacyandreliability.
Lect234/24/17 ©JESavage 17
ComponentsofSta4cCodeAnalysis*
• DataFlowAnalysis– Basedonanalysisofbasicblocks,sec4onsofcodeinwhichcontrolstayswithinablockduringexecu4on
• Controlflowgraph(CFG)– Showsallpossiblecontrolpaths
• Taintanalysis– Itiden4fiesvariablestouchedbyusersor“tainted”– InfluenceoftaintedvariablesontheCFGandac4ons
Lect234/24/17 ©JESavage 18
*hpps://www.owasp.org/index.php/Sta4c_Code_Analysis
ExampleofaBasicBlock• 1.$a=0;• 2.$b=1;• 3.• 4.if($a==$b)• 5.{#startofblock• 6.echo“aandbarethesame”;• 7.}#endofblock• 8.else• 9.{#startofblock• 10.echo“aandbaredifferent”;• 11.}#endofblock
Lect234/24/17 ©JESavage 19
Note:#startsacomment
ExampleofDataFlowGraph
Lect234/24/17 ©JESavage 20
DynamicCodeAnalysis
• Goodanalysisexploresallimportantpaths– Requiresgoodchoiceoftestdata– Incompletetes4ngcanresultincatastrophicfailure
• “Fuzzing”canrevealhiddenerrors• Malwaremaydetectitisbeingruninavirtualenvironmentandnotac4vate
• Manytoolsexistfordynamicso;wareanalysis
Lect234/24/17 ©JESavage 21
TopIncidentsin2016VerizonReport*
Incidentsrepresen4ngmorethan90%ofdatabreaches:1. Insiderandprivilegemisuse2. Cyber-espionage–apacksbyexternalactorshun4ngfordata&trade
secrets3. Webapplica4onapacks4. Crimeware–malwareincidents,typicallyopportunis4cand
financiallymo4vatedinnature(e.g.,bankingTrojans,ransomware).5. Point-of-sale(POS)Intrusions6. Denialofservice(DoS)Apacks7. Paymentcardskimmers–tamperingofATMsandfuelterminals.8. Physicalthe;andlossofdataorIT-relatedassets.9. Miscellaneouserrors–anerrordirectlycausingdataloss.
Lect234/24/17 ©JESavage 22
*VerizonDataBreachDigest,2015,hpp://www.verizonenterprise.com/verizon-insights-lab/data-breach-digest/2017/
Microso;’sSecurityDevelopmentLifecycle(SDL)
• BillGatesinauguratedMicroso;’sTrustworthyCompu4ngIni4a4vein2002.– Successwithmajornewcorporateini4a4veso;enrequiressupportfromtopmanagement.
• Everyproductthatimpactsprivacyormaybeusedbychildrenneedssecurityanalysis.– Thismeansalmostallhardware/so;wareproducts
• Averagecostoffixingasecuritybugwas$300K!– CitedbyAberdeenGroup,December2010.
• Microso;codeisnowamongthemostsecure!
Lect234/24/17 ©JESavage 23
Microso;’sSDL
• Personnelmustbetrained.• Securityrequirements,riskassessmentneeded• Mustdothreatmodeling(STRIDE)andreduceapacksurface.
– Spoofing,Tampering,Repudia4on,Informa4onDisclosure,Denialofservice,Eleva4onofprivilege.
• Implementa4onrequiresgoodtoolstoprotectagainstapacks• Mustplanforpost-releasehandlingoferrors• Verifica4onneededviadynamicanalysisincludingfuzzing.
Lect234/24/17 ©JESavage 24
ModelingSystemThreats
• Dataflowanalysispreferabletoexploringassetsormo3va3onsofa6ackers.
• Groupcomponentsbytrustboundaries
25
WebBrowser
WebServer
BusinessLogic Database
Corporatedatacenter Offsitestorage
Lect234/24/17 ©JESavage
Informa4onSecurityApributesTheCIATriad
• Confiden.ality:Accesstoinforma4onislimitedtothosewithproperauthoriza4on.
• Integrity:Maintainingtheconsistency,accuracyandtrustworthinessofdataduringitslifecycle.
• Availability:Reliableaccessismaintainedtoresourcesbyauthorizedpar4es.
26Lect234/24/17 ©JESavage
STRIDEThreats*
• S–Spoofing• T–Tampering• R–Repudia.on• I–Informa.onDisclosure• D–DenialofAccessorService• E–Eleva.onofPrivilege
27
*Microso;’smnemonicfortypesofso;warethreats
Lect234/24/17 ©JESavage
STRIDEExplained
• S–pretendingtobeanotherpersonorthing• T–modifyingsomethingoneshouldnot• R–falselyclaimingnottohavetakenanac4on• I–exposinginforma4ontothoseunauthorized• D–denyingusersaccesstoaservice• E–acquiringaccessatanelevatedlevel
28Lect234/24/17 ©JESavage
STRIDEElaboratedThreats Objec.ves
Spoofing Authen4city
Tampering
Integrity
Repudia4on Non-Repudia4on
Informa4onDisclosure Confiden4ality
DenialofService Availability
Eleva4onofPrivilege ProperAuthoriza4on
Lect234/24/17 ©JESavage 29
Op4onstoAddressThreats(META)
• Mi4gateathreat– Increasetheworktoexploitit
• Eliminateathreat– Usuallyrequireselimina4onoffeatures
• Transferofathreat– Letsomeothersystemelementcopewithit
• Acceptathreat– Riskacceptancemaybelesscostlythanothersteps
30Lect234/24/17 ©JESavage
SourceMaterial
• ThreatModeling:DesigningforSecuritybyAdamShostack,JohnWiley&Sons,2014.
• Wri3ngSecureCode:SecondEdi3on,HowardandLeBlanc,Microso;Press,2009
31Lect234/24/17 ©JESavage
IsOpenSourceSo;wareaPanacea?
• So;wareisavailableformodifica4onunderliberalcopyrightpolicy.
• Domanyeyeballsonthecodemakeitsecure?– “…inrealitythatdoesn’thappen”Cowan2002.
• Russiabelievesit–avoidsUSso;ware.– Pu4nordersRussiangovernmenttomovetoOpenSourceSo;wareby2015.(12/28/2010)
• Problems:Noincen4vetofindbugs.Codersnottrainedtofindthem.Itishard!– SeeSo;wareSecurityforOpen-SourceSystems*,2003
Lect234/24/17 ©JESavage 32
*Seehttp://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=7425509061C29FEDE840C8C4F9F69089?doi=10.1.1.12.8679&rep=rep1&type=pdf
Review
• Securitymodelingincludingaccesscontrol• Federalsecurityregula4onsandstandards• So;warevulnerabilityassessments• Microso;’sSecurityDevelopmentLifecycle• Introduc4ontoThreatAnalysis
Lect234/24/17 ©JESavage 33