D.3.3 ALGORITHMS FOR INCREMENTAL ... - SecureChange

Recommendations

Info

Figure 6. SI* Model after the introduction of the AMAN and SQM 3.3 Orchestrating Argumentation and Risk Assessment Processes Argumentation analysis is one of the main steps of the SecMER methodology. Arguments provide a way to structure the system artifacts involving the concepts in the SecMER conceptual model. The requirements analysis uses the SecMER requirement model to sketch informal arguments for the security goals of the system which will be affected by the proposed change. In this section we orchestrate argumentation with risk assessment. We introduce RISA approach to risk-based argumentation for evolving security requirements proposed in [5], and its application to the ATM case study. In the paper attached in Appendix A, RISA is applied to another case study, the PIN Entry Device (PED) system. The change scenario in the paper is the introduction of variant PED systems, and the main security properties are confidentiality and integrity of PIN. 3.3.1 Overview of the approach Haley et al. [6] have shown that argumentation provides an appropriate framework for demonstrating that a given software system satisfies its security requirements. They separate arguments into two kinds. An outer argument is a formal proof that the software (S), within a world context (W), satisfies the security requirements (R): W, S |- R. Statements about the software and the world context are called behavioural premises, the correctness of which is critical for system security. In order to demonstrate their correctness, these statements are challenged and counterchallenged by means of inner arguments. The diagram in Figure 7 summarises the main steps of the proposed approach, named RISA (RIsk assessment in Security Argumentation), extending the framework of Haley et al [6]. As indicated in the diagram, Steps 1 to 3 of the proposed approach are the same as the first three steps of the framework of Haley et al. Steps in shaded boxes D.3.3 Algorithms for Incremental Requirements Models Evaluation and Transformation| version 1.19 | page 16/136
are supported by the argumentation tool OpenArgue [7], developed in the SecureChange project. In Step 1 (Identify Functional Requirements), functional requirements of the system and the system context are identified. These requirements may be derived from the higher-level goals of the system. In Step 2 (Identify Security Goals), assets that need to be protected, and security goals are identified. In Step 3 (Identify Security Requirements), security requirements are derived from security goals, and are expressed as constraints on the functional requirements identified in Step 1. Figure 7. Overview of the RISA approach Unlike the fourth step of the Haley et al. framework, only the outer arguments for security requirements, excluding the inner arguments, are constructed in Step 4 (Construct Outer Arguments) of RISA. These outer arguments are formal, and they make use of domain properties, correctness of which is examined by inner arguments. Behavioral premises used in the outer arguments may contain risks, which are identified as part of risk assessment in RISA. In Step 5 (Identify Risks), behavioral premises in outer arguments are analyzed in terms of potential risks that rebut the premises. For instance, in the PED example, there could be a behavioral premise about the confidentiality of the PIN entered using the PED keypad. Public security catalogues are then searched to find known security weaknesses and attack patterns regarding the confidentiality of PIN entered by consumers using a keypad. In Step 6 (Classify Risks) the catalogue entries related to risks identified in the previous step to (i) find appropriate security mechanisms for mitigating them and (ii) classify D.3.3 Algorithms for Incremental Requirements Models Evaluation and Transformation| version 1.19 | page 17/136
Page 1 and 2: D.3.3 ALGORITHMS FOR INCREMENTAL RE
Page 3 and 4: 1.14 19 January Final 1.15 23 Janua
Page 5 and 6: Index DOCUMENT INFORMATION 1 DOCUME
Page 7 and 8: 1 Introduction This deliverable pre
Page 9 and 10: (Clause 6.4.3) processes of ISO/IEC
Page 11 and 12: 3 Orchestrating Requirements and Ri
Page 13 and 14: grey. The ADS-B introduction requir
Page 15: The security risk manager identifie
Page 19 and 20: ADS-B Manage ADS-B signal ADS-B sig
Page 21 and 22: the stagnation suite (i.e. obsolete
Page 23 and 24: 5 A framework for modeling and reas
Page 25 and 26: sectors. And there is 42% of probab
Page 27 and 28: SDA(C) = {DA 2 , DA 4 , DA 8 , DA 1
Page 29 and 30: application contexts is saved if th
Page 31 and 32: Figure 14. ATM model state after qu
Page 33 and 34: References [1] Yudis Asnar, Fabio M
Page 35 and 36: Managing Changes with Legacy Securi
Page 37 and 38: Failure in the provisioning of corr
Page 39 and 40: propagated to the system designer a
Page 41 and 42: APPENDIX B D.3.3 Algorithms for Inc
Page 43 and 44: is sometimes difficult, especially
Page 45 and 46: Tactical Monitor air R controller t
Page 47 and 48: protected from harm. Since in CORAS
Page 49 and 50: CModel. The postcondtion checks the
Page 51 and 52: of ADS-B signal and Availability of
Page 53 and 54: extensions to i* to model and analy
Page 55 and 56: 3. Bzivin, J., Dup, G., Jouault, F.
Page 57 and 58: APPENDIX C D.3.3 Algorithms for Inc
Page 59 and 60: steps. Section V demonstrates the R
Page 61 and 62: that should be mitigated by the sys
Page 63 and 64: CPU value PINconfirmed(PIN, card-de
Page 65 and 66: TABLE IV PRIORITIZATION OF RISKS FO
Page 67 and 68:
context. We believe that the Common
Page 69 and 70:
Managing Evolution by Orchestrating
Page 71 and 72:
1.1 The Contribution of this Paper
Page 73 and 74:
Fig. 3. Integrated Change Managemen
Page 75 and 76:
The requirement analysis is an iter
Page 77 and 78:
Table 1. Conceptual Interface Requi
Page 79 and 80:
Legend: Goals surrounded by dashed
Page 81 and 82:
Table 5. Test Suite for GP-2.2 Tran
Page 83 and 84:
6. P. K. Chittimalli and M. J. Harr
Page 85 and 86:
Noname manuscript No. (will be inse
Page 87 and 88:
Dealing with Known Unknowns: A Goal
Page 89 and 90:
Page 91 and 92:
Page 93 and 94:
Page 95 and 96:
Page 97 and 98:
Page 99 and 100:
Page 101 and 102:
Page 103 and 104:
Page 105 and 106:
Page 107 and 108:
Page 109 and 110:
Page 111 and 112:
Page 113 and 114:
Understanding How to Manage Require
Page 115 and 116:
Chatzoglou et al. [4] conducted a s
Page 117 and 118:
Evolution Elicitation Probability E
Page 119 and 120:
Table 2. Participants Background Pa
Page 121 and 122:
for the defined success criteria. O
Page 123 and 124:
Fig. 3. Codes Coverage ATM systems,
Page 125 and 126:
The feedbacks provided by the ATM e
Page 127 and 128:
3. P. Carlshamre, K. Sandahl, M. Li
Page 129 and 130:
Quick fix generation for DSMLs Ábe
Page 131 and 132:
• extensibility: the supported li
Page 133 and 134:
Fig. 7. Overview of the Quick fix g
Page 135 and 136:
Fig. 9. Evaluation results (|V(M I
show all

D.3.3 ALGORITHMS FOR INCREMENTAL ... - SecureChange

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?