View
217
Download
0
Category
Preview:
Citation preview
Risk and Argument: A RiskRisk and Argument: A Risk--basedbased Argumentation Method for Practical SecurityArgumentation Method for Practical Security
VirginiaVirginia N. L. N. L. FranqueiraFranqueira, , TheinThein Than Than TunTun, , YijunYijun Yu, Yu, RoelRoel WieringaWieringa and and BasharBashar NuseibehNuseibeh
Trento Trento -- 02 September 2011 02 September 2011
AgendaAgenda
1/20
ProblemProblem Solution Solution DirectionDirection
WalkWalk--through through of RISA methodof RISA methodusing PED using PED
exampleexample
Engineering of secure systems is Engineering of secure systems is bound by practical limitationsbound by practical limitations
UncertaintiesUncertainties
Incomplete informationIncomplete information
Limited resourcesLimited resources
Unnoticeable, hardly Unnoticeable, hardly measurable evidencemeasurable evidence
2/20
Consequence & Solution DirectionConsequence & Solution Direction
Our solution: Our solution:
RISARISA ––
RIsk assessmentRIsk assessment in in Security ArgumentationSecurity Argumentation
In practice:In practice: No absolute securityNo absolute security
No 100% security requirements satisfactionNo 100% security requirements satisfaction
Way forward:Way forward: Good enough security satisfactionGood enough security satisfaction
As low as possible level of security riskAs low as possible level of security risk
3/20
From Haley et al. framework to RISA methodFrom Haley et al. framework to RISA methodKey steps from Haley et al. frameworkKey steps from Haley et al. framework
1. Identify1. IdentifyFunctionalFunctional
RequirementsRequirements
3. Identify3. IdentifySecurity Security
RequirementsRequirements
2. Identify2. IdentifySecuritySecurity
GoalsGoals
4. Construct4. ConstructOuterOuter
ArgumentArgument
Steps for risk assessment in RISASteps for risk assessment in RISA
good good enough enough securitysecurity
8. Prioritize8. PrioritizeRisksRisks
7. Mitigate7. MitigateRisksRisks
6. Classify6. ClassifyRisksRisks
5. Identify5. IdentifyRisksRisks
Public SecurityPublic SecurityCataloguesCatalogues
4/20
5. Construct Inner Argument5. Construct Inner Argument
Formal logicFormal logic
Structured ArgumentationStructured Argumentation
PIN Entry Devices (PED) examplePIN Entry Devices (PED) example
S.Drimer, S.J.Murdoch, and R.Anderson, Thinking Inside the Box: S.Drimer, S.J.Murdoch, and R.Anderson, Thinking Inside the Box: SystemSystem--Level Failures of Tamper Level Failures of Tamper Proofing, in SPProofing, in SP’’2008, IEEE Press, pp. 2812008, IEEE Press, pp. 281--295, 2008.295, 2008.
5/20
RISA step 1: RISA step 1: Identify Functional RequirementsIdentify Functional Requirements
functional goalfunctional goal
Provide convenient payment option at PointsProvide convenient payment option at Points--OfOf--Sale to consumersSale to consumers
functional requirementfunctional requirement
Allow consumers to pay at PointsAllow consumers to pay at Points--OfOf--Sale with PINSale with PIN
88 77 66 55Cat.Cat.
11 3322 44
6/20
RISA step 2: RISA step 2: Identify Security GoalsIdentify Security Goals
valuable assetsvaluable assets
PINPIN card detailscard details transaction valuetransaction value design characteristicsdesign characteristics smartcard itself smartcard itself cryptographic keyscryptographic keys
security goalsecurity goal
Protect the PINProtect the PIN
88 77 66 55Cat.Cat.
11 3322 44
7/20
RISA step 3: RISA step 3: Identify Security RequirementsIdentify Security Requirements
security requirementssecurity requirements
confidentiality of PINconfidentiality of PIN
integrity of PINintegrity of PIN
security functionssecurity functions
enclosure of PED components provides enclosure of PED components provides tamper detection & tamper detection & responseresponse mechanisms to resist physical attacksmechanisms to resist physical attacks
encryption/decryption of PINencryption/decryption of PIN ensures that the PIN is ensures that the PIN is encrypted within the PED immediately after PIN entryencrypted within the PED immediately after PIN entry
system context diagramsystem context diagram
88 77 66 55Cat.Cat.
11 3322 44
8/20
RISA step 4: RISA step 4: Construct Outer ArgumentConstruct Outer Argument
Formal proof that Formal proof that behaviorbehavior
of PIN related to confidentiality is satisfiableof PIN related to confidentiality is satisfiable
Outer argument for confidentiality of PIN:Outer argument for confidentiality of PIN:
((BehavioralBehavioral
premises) P1, P2, P3, P4, P5, P6 premises) P1, P2, P3, P4, P5, P6 ├├
confirmationconfirmation--transactiontransaction
cardcardbankbank
consumerconsumer
CPUCPU cardcard--readerreader
displaydisplay keypadkeypad
PEDPED
P4P4
P3P3
P2P2
P1P1
P6P6P5P5
confirmationconfirmation --transactiontransaction
88 77 66 55Cat.Cat.
11 3322 44
9/20
PINPIN
Risk assessment steps of RISA are supported Risk assessment steps of RISA are supported by the CAPEC & CWE public cataloguesby the CAPEC & CWE public catalogues
http://capec.mitre.org/http://capec.mitre.org/ http://http://cwe.mitre.orgcwe.mitre.org//
88 77 66 55Cat.Cat.
11 3322 44
10/20
RISA step 5: RISA step 5: Identify RisksIdentify Risks
Structured argumentationStructured argumentation used to challenge used to challenge behavioralbehavioral premises in premises in practice via risk assessmentpractice via risk assessment
PIN reacheskeypad
claimclaim
Challenged Risk Reference
Premise P2 R1.6: PIN is revealed if sent unencrypted within the PED and the PED enclosure can be tampered
CWE-311 &CAPEC-436
PIN leaveskeypad
PIN reachescard-reader
Premise P2
groundground claimclaim
…
R1.1R1.2…
rebuttalrebuttalR1.6R1.7…
rebuttalrebuttal
Consumerenters PIN
Premise P1
groundground
Correct PINsare accepted
by keypad
warrantwarrant
88 77 66 55Cat.Cat.
11 3322 44
11/20
RISA step 6: Classify Risks RISA step 6: Classify Risks
Risks are classified in terms of:Risks are classified in terms of:
risks transferred to system contextrisks transferred to system context
risks to be mitigated by the systemrisks to be mitigated by the system
Possibilities:Possibilities:
risk to be completely mitigated by the PEDrisk to be completely mitigated by the PED
risk to be completely mitigated by the PED contextrisk to be completely mitigated by the PED context
risk to be partially mitigated by bothrisk to be partially mitigated by both
88 77 66 55Cat.Cat.
11 3322 44
13/20
RISA step 7: Mitigate RisksRISA step 7: Mitigate Risks
Mitigations restore the satisfaction of security requirements byMitigations restore the satisfaction of security requirements by rebutting rebutting risksrisks
Risk Mitigation
R1.6 & R1.7 & R1.8
M2.4: Any transmission of PIN should use well-vetted encryption algorithms & recommended key sizes
88 77 66 55Cat.Cat.
11 3322 44
System System behavioralbehavioral premisespremises
RisksRisks
MitigationsMitigations
14/20
RISA step 8: Prioritize Risks RISA step 8: Prioritize Risks
Empirical data about typical severity of risks or likelihood of Empirical data about typical severity of risks or likelihood of exploit can exploit can also be found in the cataloguesalso be found in the catalogues
Risk Mitigation Typical risk severity
R1.6 & R1.7 & R1.8
M2.4: Any transmission of PIN should use well-vetted encryption algorithms & recommended key sizes
Low to very high
Interpretation of risk severity Interpretation of risk severity depends on many factorsdepends on many factors
88 77 66 55Cat.Cat.
11 3322 44
16/20
RISA recursion RISA recursion
Other rounds of argumentation may follow Other rounds of argumentation may follow
recursion stops when the system security is considered goodrecursion stops when the system security is considered good--enough enough and/or resources for analysis of security have been used and/or resources for analysis of security have been used
18/20
8. Prioritize8. PrioritizeRisksRisks
7. Mitigate7. MitigateRisksRisks
6. Classify6. ClassifyRisksRisks
5. Identify5. IdentifyRisksRisks
Public SecurityPublic SecurityCataloguesCatalogues
1. Identify1. IdentifyFunctionalFunctional
RequirementsRequirements
3. Identify3. IdentifySecurity Security
RequirementsRequirements
2. Identify2. IdentifySecuritySecurity
GoalsGoals
4. Construct4. ConstructOuterOuter
ArgumentArgument
good good enough enough securitysecurity
Opportunities for future workOpportunities for future work
Addressing Addressing residual risksresidual risks
Improvement to Improvement to estimation/prioritization of risksestimation/prioritization of risks
Tool supportTool support
for the method: for the method: OpenArgueOpenArgue
tool to be adaptedtool to be adapted
ValidationValidation
in the field with industrial case studiesin the field with industrial case studies
Addressing impact of Addressing impact of transferred riskstransferred risks
in terms of system mitigationsin terms of system mitigations
Support to Support to search cataloguessearch catalogues
for risk identificationfor risk identification
19/20
Conclusion: Mutual benefits Conclusion: Mutual benefits
Satisfaction analysis (SA) benefits from risk assessment (RA)Satisfaction analysis (SA) benefits from risk assessment (RA)
RA provides systematic input for security argumentation in SARA provides systematic input for security argumentation in SA
RA allows prioritization of arguments and security requirements RA allows prioritization of arguments and security requirements from prioritization of risksfrom prioritization of risks
RA scales the process of argumentation with breadthRA scales the process of argumentation with breadth--first first approachapproach
Risk assessment (RA) benefits from satisfaction analysis (SA)Risk assessment (RA) benefits from satisfaction analysis (SA)
SA provides systematic description of system context: source of SA provides systematic description of system context: source of risksrisks
SA provides top structure for RASA provides top structure for RA
SA argumentation organizes several rounds of RA & facilitates SA argumentation organizes several rounds of RA & facilitates traceabilitytraceability
20/20
franqueirav@ewi.utwente.nlhttp://wwwhome.ewi.utwente.nl/~franqueirav/
virginia.franqueira@gmail.com
C. Haley, R. Laney, J. Moffett, and B. Nuseibeh, C. Haley, R. Laney, J. Moffett, and B. Nuseibeh, Security Requirements Engineering: A Framework for Security Requirements Engineering: A Framework for Representation and AnalysisRepresentation and Analysis, IEEE Transactions on Software Engineering, 34(1), pp. 133, IEEE Transactions on Software Engineering, 34(1), pp. 133––153, 2008.153, 2008.
S.ToulminS.Toulmin, , R.RiekeR.Rieke, and , and A.JanikA.Janik, , An Introduction to ReasoningAn Introduction to Reasoning, Macmillan, 1979., Macmillan, 1979.
Questions?Questions?
Recommended