D.3.3 ALGORITHMS FOR INCREMENTAL ... - SecureChange

Recommendations

Info

14 F. Massacci and L.M.S. Tran DMAN1 DMAN ATM SYSTEM AMAN AMAN1 ATM SYSTEM AMAN AMAN1 AMAN11 DMAN2 AMAN2 AMAN2 AMAN12 (a) Multi-part evolution scenario (b) Multi-step evolution scenario The left (a) exemplifies a multi-part evolution, where a big ATM system has two separated subsystems (parts), AMAN and DMAN, which may evolve independently. Meanwhile, the right (b) illustrates a multi-step scenario. After AMAN evolves to AMAN 1, it continues to evolve to either AMAN 11 or AMAN 12. Fig. 5 Complex evolution scenarios. 7 More Complex Evolution Scenarios In practice, evolutions can fall into one of two scenarios: multi-part and multi-step (or combination of these scenarios). The multi-part scenario indicates evolutions in different parts of a big enterprise model, as illustrated in Fig. 5(a). This is a case that a system comprises of several subsystems which are relatively independent. For instance, in the whole ATM system, the AMAN subsystem (Arrival Management System) is more or less independent with the DMAN (Departure Management System) subsystem even though they can exchange data. Thus AMAN can evolves independently with DMAN. We call evolution in subparts of the model as local evolution. The multi-step evolution scenario determines the case that the system is iteratively evolving. In Fig. 5(b), the AMAN subsystem of ATM, after evolving to AMAN 1 , may continue to evolve to either AMAN 11 or AMAN 12 . Suppose that the evolution of AMAN to AMAN 1 or AMAN 2 is subject to an observable rule r o1 ; and the evolution of AMAN 1 to AMAN 11 or AMAN 12 is subject to an observable rule r o2 . The global evolution of AMAN, in this case, is a 2-step evolution. Obviously, r o2 can only be effective only if r o1 happens in the first step/phase, AMAN −→ AMAN 1 . We call the relationship between r o1 and r o2 evolution-dependent relationship, which are formally defined as follows. Definition 5 (Evolution-dependent relation) Given two observable rules r o1 = S n EM p o i −→ EM i and ro2 = S j ff EM ′ p j −→ EM j ′ , the rule r o2 is evolution-dependent i to the rule r o1 , denoted as r o1 r o2 if there exists a possibility EM p i −→ EM i of r o1 such that EM’ is a subset (or equal) of EM i . r o1 i r o2 ⇔ ∃EM p i −→ EM i ∈ r o1 .EM ′ ⊆ EM i (2) To this end we define the evolutionary enterprise model that take into account all complex evolution scenarios as follows. Definition 6 (Evolutionary enterprise model) An evolutionary enterprise model eEM is a quadruplet 〈EM, R o, R c, Dep〉 where:
Dealing with Known Unknowns: A Goal-based Approach 15 – EM is the original enterprise model, – R o is set of observable evolution rules. – R c is a set of controllable rules applying to the original enterprise model and other evolved ones. – Dep ⊆ R o×R o×N is a set of evolution-dependent relations between observable rules. R o = [ j r oα = [ j ffff SM α pα i −−→ SMi α R c = [ n r cαi = [ nSM α i Dep = [ n r oα o i r oβ where SM α ⊆ EM ∨ ∃SM α′ p α′ i −−→ SMi α′ .SM α ⊆ SMi α′ oo ∗ −→ SMij α The calculation of the max belief and residual risk for a given configuration C on a given evolutionary enterprise model eEM is complicated by the need to consider both multi-part and multi-step evolutions. However, once we have defined a semantics for the basic set-up of probabilities, we can now leverage on the mathematics behind the theory or probabilities.Thus we can use the mechanisms of conditional probabilities for multi-step evolution and of independent combination of events for multi-part evolution. The max belief and residual risk of a given configuration C and an evolutionary enterprise model eEM〈EM, R o, R c, Dep〉 are defined as follows. (3) MaxB(C) max P r ∀( V α SMα −−→SM pα i i α). S α SMα i ∈SDA(C) RRisk(C) 1 − X ∀( V α SMα pα i −−→SM α i ). S α SMα i ∈SDA(C) P r ^ SM α pα i −−→ SMi α α ! ^ SM α pα i −−→ SMi α α ! (4) 8 An Incremental Algorithm to Calculate Max Belief and Residual Risk Developing an algorithm to calculate max belief and residual risk, as in Formula 4, for an evolutionary goal model is not practical. With the heuristic assumption that observable rules in different parts are independent we can efficiently eliminate recursion by transforming the model into a suitable hypegraph and use efficient hyperpath algorithms. An evolutionary goal model is converted in to an evolutionary hypergraph as follows. Definition 7 (Evolutionary hypergraph) The hypergraph G〈V, E〉 of an evolutionary goal model 〈EM, R o〉 is constructed as follows: • For each goal g, create a goal node g.
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 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 97: Dealing with Known Unknowns: A Goal
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?