D.3.3 ALGORITHMS FOR INCREMENTAL ... - SecureChange

Recommendations

Info

these mechanisms, and indirectly the risks associated with them, according to whether the system or the context should mitigate the risks. In Step 7 (Mitigate Risks), only the risks with mitigations assigned to the system are considered. It involves the consolidation of mitigations reoccurring in several risks. It consists of (1) numbering mitigations, (2) assigning to each of them a list of risks it rebuts, and (3) updating their description to comply with all these risks, if applicable. Some of these mitigations, themselves, could introduce new risks and therefore should be assessed in a new round of inner argumentation. In the last step (Prioritize Risks), risks are prioritized on the basis of their severity as indicated by the public security catalogs (arrow from catalogs to Step 8). These risks affect the priority of requirements to be satisfied (arrow from Step 8 to Steps 1–4). When the residual risks are deemed to be acceptable given the limitation of development resources, the system has reached the level of good-enough security. 3.3.2 Application to the ATM case study We now briefly illustrate the application of the RISA approach to the (Automatic Dependent Surveillance-Broadcasting) ADS-B introduction scenario of the ATM case study. The purpose of the discussion is to briefly highlight how the approach will be applied to the evolutionary ATM scenario used in the report by presenting the main input and output from the steps. Step 1 (Identify Functional Requirements): We begin by developing the after change requirement model. In the case of ADS-B introduction, the functional requirement (or the goal) is to manage surveillance data. As shown in the diagram in Figure 8, the “Manage Surveillance data” goal can be decomposed further into two subgoals in the after model. Step 2 (Identify Security Goals): One overall security/soft goal is to ensure the availability of surveillance data. This is a system level goal that has to be decomposed into a number of requirements for various parts of the system. The main assets after the change are Surveillance data, ADS-B signal and Radar signal, as shown in Figure 8. Another security goal is the integrity of ADS-B signal, which is not discussed further here. Step 3 (Identify Security Requirements): Applying the security goal of “Availability to surveillance data” to the functional requirements gives a new security requirement, that is ensuring the “Availability of ADS-B surveillance data”. Step 4 (Construct Outer Arguments): The main argument for the availability of ADS-B surveillance data in the after change scenario will take of the following form: P1, P2, P3 → P4 where P1 is “Planes are fitted with ADS-B devices”, P2 is “GPS signals are available”, P3 is “Ground surveillance system is fitted with ADS-B receivers” and P4 is “ADS-B surveillance data is available”. (See Appendix C for formalisation of arguments.) <strong>D.3.3</strong> Algorithms for Incremental Requirements Models Evaluation and Transformation| version 1.19 | page 18/136
ADS-B Manage ADS-B signal ADS-B signal Apply MD5 checksum r + Availability of surveillance data De Integrity of ADS-B signal Surveillance data Radar Manage ADS-B signal Manage radar signal AND Manage surveillance data ADS-B signal AND Radar signal + + De Gather aircraft position Availability of ADS-B signal Availability of radar signal AND RDPS Availability of surveillance data Run fault tolerant MRT Figure 8. Requirement model for ADS-B Introduction Step 5 (Identify Risks): There are several risks associated with each of the behavioural premises (P1, P2 and P3). For instance, GPS signal availability may be at risk due to several forms of attack, such as ADS-B signal jamming and the ADS-B system turn off. Here the method user can adopt an appropriate risk identification technique such as the one proposed by CORAS. Step 6 (Classify Risks): ADS-B signal jamming is a risk that may be transferred to the context, whilst the ADS-B system turn off is a risk that may be transferred to the system. Step 7 (Mitigate Risks): The risk of ADS-B signal jamming may be mitigated by ensuring that there is no 1090 MHz jamming near ground stations, for instance. The risk of ADS-B system turn off may be mitigated by providing no in-flight turn off functionality. Step 8 (Prioritize Risks): Domain experts help prioritizing the risks: in this case, they are both identified as critical risks. Again, CORAS or another appropriate risk prioritization technique can be used to prioritize these risks. <strong>D.3.3</strong> Algorithms for Incremental Requirements Models Evaluation and Transformation| version 1.19 | page 19/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 and 16: The security risk manager identifie
Page 17: are supported by the argumentation
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

Create successful ePaper yourself

Delete template?

Save as template?