D.3.3 ALGORITHMS FOR INCREMENTAL ... - SecureChange

Recommendations

Info

Party 1 1..* Asset Likelihood Consequence 1 1 1 * Risk 1..* * Treatment 1..* 1 Unwanted incident * 1 1 * Threat scenario Leads to * 1..* Initiates Vulnerability 1..* Exploits * Threat Fig. 3. CORAS conceptual model The CORAS risk analysis consists of five main phases. The context establishment includes defining the target of analysis, setting the scope and focus of the analysis, and deciding the risk evaluation criteria. The risk identification is to identify, model and document risks, including the various sources of risk such as threats, vulnerabilities and unwanted incidents. The risk estimation is to determine the risk levels by estimating the consequences of unwanted incidents and their likelihood to occur. The risk evaluation is to compare the risk estimation results with the risk evaluation criteria and decide which risks need to be evaluated for treatment. The risk treatment is to identify strategies for mitigating risk, reducing them to an acceptable level. The process is typically iterative and aims at protecting stakeholders’ assets, and terminates when the residual risk is equal to or lower than the risk tolerance. 3 Conceptual Mappings SI* and CORAS models are rarely static as they may continuously evolve during their respective processes. Evolution is driven by user input in modeling environments and editors. Two types of changes can be applied to a model: atomic changes which are model updates consisting of an operation – e.g create, delete, update – and operands (model elements), or a complex sequence of such atomic operations. Thus, a change in a SI* or CORAS model can be represented as a transition of the model from a pre-state, to a post-state. The difference between the pre-state and the post-state model is called change delta (or model delta). Model manipulation operations are specified in a change request that can be proposed either by the requirement or the risk analyst. Since SI* and CORAS conceptual models evolve independently, inconsistencies between the two models can be identified only when a periodic review is conducted. Thus, to ensure bidirectional consistency, i.e. maintain mutual consistency under change, we propose a change-driven interplay between the requirement analyst and the risk analyst. The interplay is based on a set of mappings between key concepts of the SI* and CORAS conceptual models. We have mapped concepts that are used to represent assets that are critical for the achievement of organization’s strategic objectives and means to protect assets in a cost-effective manner. We have identified three conceptual mappings: ServiceToAsset, ServiceToTreatment, and TreatmentToTask. ServiceToAsset. A service that is linked to a soft goal by a protects relation denotes a resource, a task or a goal that is of value for the organization and thus needs to be
protected from harm. Since in CORAS, an asset is something of value that requires protection, we map a service protected by a soft goal in SI* to an asset in CORAS. ServiceToTreatment. A service which is related to another service mapped to an asset in a CORAS model, can be mapped to a treatment if the service reduces the likelihood or the consequence of a threat scenario damaging the asset. TreatmentToTask. A treatment is a security control that should reduce the likelihood or consequence of a threat to an asset which results in a loss of confidentiality, availability, or integrity. Thus, if a treatment is implemented, the confidentiality, integrity or availability of an asset is protected. A treatment in CORAS can therefore be mapped to a task which fulfills the soft goal which specifies the security property that has to be preserved for an asset. We have formalized the mappings in the VIATRA2 graph transformation language [29]. The VIATRA2 framework supports model-to-model transformations: a model transformation is a program that receives as input a source model that conforms to its source metamodel and produces a target model conforming to a target metamodel. The VIATRA2 transformation language consists of several constructs: graph patterns are declarative queries, that specifies constraints and conditions on models; graph transformations rules (GT) provide a declarative, high-level rule- and pattern-based manipulation language for models; abstract state machine (ASM) rules can be used to assemble patterns and graph transformation rules to specify complex model transformations. A graph transformation rule can be specified by using a left-hand side – LHS (or precondition) pattern determining the applicability of the rule, and a right-hand side – RHS (postcondition) pattern which specifies how the model should be changed at the matches of the LHS. The mappings ServiceToAsset, ServiceToTreatment, and TreatmentToTask are formalized by the graph transformation rules newAsset, potentialTreatment, and transformTreatment respectively. The rules are executed on a model space which includes a) SI* conceptual model, b) CORAS conceptual model, c) a SI* model, d) a CORAS model. The model space includes also the traceability conceptual model which specifies the structure of the traceability matrix and the traceability model storing the mappings between the elements of the CORAS and the SI* models. The traceability links are automatically created by the graph transformation rules. The newAsset rule has three parameters: SecGoal, the soft goal that has to be mapped, CModel, the CORAS model, and TraceModel, the traceability model that stores the mappings between the elements of the SI* and CORAS model. The precondition calls two patterns: secgoalProtectsAsset which checks that SecGoal is a soft goal that is linked to a service by the ”protects” relation; the negative condition pattern mappedElement which checks that soft goal SecGoal has not already been mapped to an asset in the CORAS model CModel. The postcondtion creates an asset Asset in the CORAS model CModel. The action of the rule names the asset Asset created in CModel as SecGoal and creates a traceability link in the traceability model who has as source of the mapping SecGoal and as target Asset.
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 and 18: are supported by the argumentation
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: Tactical Monitor air R controller t
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 97 and 98:
Dealing with Known Unknowns: A Goal
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?