D.3.3 ALGORITHMS FOR INCREMENTAL ... - SecureChange

the risk analyst identifies treatments that aim to reduce the risk to an acceptable level.
The requirement analyst has to be notified about the new treatments, so that he/she can
decide whether to implement the treatments or not. If the treatments provide sufficient
risk reduction and are cost effective, the requirement analyst updates the requirement
model with new tasks linked to the soft goal protecting the asset harmed by the threat
mitigated by the treatments.
Example 5. Due to space constraints we do not show the modeling of this example,
which in any case should be straightforward. A risk assessment is conducted that identifies
the new threat scenario Eavesdropping on ADS-B communication. The risk of
leakage of critical A/C position data due to ADS-B eavesdropping is considered as
very unlikely since this kind of data is not sensitive, but the consequence of leakage
of critical data is considered as a major consequence. The resulting risk level is therefore
unacceptable. The treatment Implement encryption of ADS-B signal is identified
for the threat scenario Eavesdropping on ADS-B communication. The addition of the
treatment Implement encryption of ADS-B signal leads to the addition of a) a new soft
goal Confidentiality of ADS-B signal which protects the resource ADS-B signal, b) a
task Encryption of ADS-B signal which contributes to the fulfillment of the soft goal
Confidentiality of ADS-B signal.
With these examples we see how the change-driven interplay works in practice. It
supports the underlying idea of separation of concern between the two domains where
the respective processes are conducted separately, yet sufficiently orchestrated to manage
the changes in a coherent way. Moreover, the interplay ensures that consistency is
maintained between the two domains and that none of the models become obsolete with
respect to the other under change.
5 Related Work
The approach presented in this paper is related to works that have investigated the problems
of orchestrating the requirement elicitation and analysis process with risk assessment
process, and to works on how to handle change propagation.
Requirements and Risk Analysis Interplay. Several requirement frameworks have
attempted to extend requirements conceptual models with security related concepts and
to include risk analysis as part of the requirement analysis. Among goal-oriented approaches,
van Lamsweerde extends KAOS by introducing the notions of obstacle [28]
and anti-goal [15] to analyze the security concerns of a system. KAOS obstacle captures
an undesired state of affairs that might harm safety goals (i.e., hazard) or threaten security
goals (i.e., threat). KAOS anti-goal captures the intention of an attacker or considers
it as a malicious obstacle. A formal framework is proposed to identify the obstacles to
a goal in a given domain properties and to generate countermeasures to those obstacles.
Liu et al. [18] proposes an extension of the i* framework [30] to identify attackers, and
analyze vulnerabilities through actor’s dependency links. In this framework, all actors
are considered as potential attackers, and therefore their capabilities are analyzed and
possible damages caused by actors are assessed. In Li et al. [16], the authors propose
a formal framework to support the attacker analysis. Similarly, Elahi et al. [8] propose