D.3.3 ALGORITHMS FOR INCREMENTAL ... - SecureChange

3 Orchestrating Requirements and Risk
Assessment processes
Changing requirements might give rise to potential security risks that in turn require
some treatments to ensure and maintain an acceptable security risk level. Or treatment
options that result from risk assessment may lead to new security requirements that
should be included in the requirement model. Moreover, the requirement changes may
involve new assets the risk level of which needs to be assessed. Thus, there is the
need to trace changes to security knowledge such as assets, attacks and treatments to
stakeholders' goals and security requirements and vice versa.
Current industrial software/system engineering processes are supported by artifacts
(documents, models, data bases) that are disjoint and cannot be fully integrated for a
variety of reasons (separate engineering domains, outsourcing, confidentiality, etc.).
Thus, the collaboration between risk analyst and requirement analyst in such
processes is sometimes difficult, especially when a change occurs and they have to
interact to keep the risk and the requirement models mutually consistent under change.
The papers in Appendix A and B propose a possible solution to change propagation
that is based on the orchestration of the requirement engineering and risk assessment
processes. The orchestration relies upon mappings between key concepts of the
requirement and the risk conceptual models.
In section 3.1, weinstantiate the requirement and risk conceptual models, to SI* and
CORAS respectively. However, alternative approaches to requirement engineering and
risk analysis with similar underlying conceptual frameworks can be orchestrated by
following the same approach. Indeed, the concepts that are mapped in the former --
such as goal, resource, and task -- are in common to other goal-oriented approaches
to requirement engineering. The same holds for asset and treatments that are key
concepts in other risk analysis approaches. In section 3.2 we show that the same
approach can be applied to SI* and Security DSML [19], which is a language and a tool
developed to conduct security risk analysis in industry.
In section 3.3 we also illustrate how argumentation analysis can be orchestrated with
risk assessment.
3.1 Orchestrating SI* and CORAS concepts and
processes
We have mapped concepts in SI* and CORAS 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
which 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
D.3.3 Algorithms for Incremental Requirements Models
Evaluation and Transformation| version 1.19 | page 11/136