D.3.3 ALGORITHMS FOR INCREMENTAL ... - SecureChange

of ADS-B signal and Availability of Radar signal. The introduction of the ADS-B actor
may affect the risks due to the introduction of the new soft goals. In particular, the soft
goal Integrity of ADS-B signal is mapped to a corresponding asset in the CORAS model
for which a risk assessment is conducted. As ADS-B is prone to data spoofing, this
issue is addressed and identified as an unacceptable risk with respect to integrity. The
treatment Apply MD5 checksum is considered, and leads to the addition of a new task
Apply MD5 Checksum fulfilling the soft goal Integrity of ADS-B signal in the SI* model.
The new soft goal Availability of ADS-B signal is also mapped to the CORAS model as
a new aspect of the more general asset Availability of surveillance data. The risk analyst
decides not to decompose this asset with respect to ADS-B and radar when assessing
the impact of the ADS-B. A new threat scenario Loss of ADS-B signal is identified, but
the overall risks with respect to availability of surveillance data do not increase; rather,
the likelihood of the threat scenario Failure of A/C tracking decreases from likely (cf.
Figure 2 (b)) to possible.
ServiceToTreatment-TreatmentToTask. The interaction between the requirement analyst
and the risk analyst can also be triggered when a new service is added to the requirement
model. If the service is related to another service which is mapped to an asset
in the risk model, and the former service reduces the likelihood or the consequence of
a threat scenario damaging the asset, the service can be considered as a potential treatment.
By a service related to an asset we mean a goal or a task that consumes the asset
or a resource that is part of the asset. The execution of the graph transformation rule
potentialTreatment (see Listing 1.2) is triggered and, thus, a potential treatment is suggested
to the risk analyst, who evaluates which is the impact of it on the risk profile. The
introduction of the treatment might not reduce sufficiently the risk associated with the
mitigated threat scenario, and thus the risk analyst decides to not update the risk model
with the new treatment; or it can lead to the removal of another treatment because the
new treatment reduces the level of risk of a threat scenario which was mitigated by the
treatment. In this case, the requirement analyst needs to be informed about the removal
of a treatment because it has to remove from the requirement model the task that is
mapped to the treatment.
Example 4. The ADS-B introduction increases the availability of surveillance data.
Thus, the likelihood of the threat scenario Failure of A/C tracking in the CORAS model
is reduced. Consequently, the risk analyst determines that the treatment Run fault tolerant
MRT is no longer needed and therefore removes it from the CORAS model. This
treatment is mapped to the corresponding task in the requirement model since it protects
the soft goal Availability of radar data, and hence the more general soft goal Availability
of surveillance data. Therefore, the removal of treatment Run fault tolerant MRT in
the CORAS model leads to the removal of the mapped task Run fault tolerant MRT. In
Figure 4 the removal of elements is indicated by the diagonally striped elements.
TreatmentToTask. The interaction between the risk analyst and the requirement analyst
is also required when the likelihood or the consequence scale changes or new
threats emerge. For example, when a new security incident is reported, the risk analyst
has to consider new threat scenarios for the damaged asset, and evaluate the risk associated
with them. If the level of risk associated with the new threat scenarios is high,