Managing changes with legacy security engineering processes

Managing changes in Security Engineering is a difficult task: the analyst must keep the consistency between security knowledge such as assets, attacks and treatments to stakeholders´ goals and security requirements. Research-wise the usual solution is an integrated methodology in which risk, security requirements and architectural solutions are addressed within the same tooling environment and changes can be easily propagated. This solution cannot work in practice as the steps of security engineering process requires to use artefacts (documents, models, data bases) and manipulate tools that are disjoint and cannot be fully integrated for a variety of reasons (separate engineering domains, outsourcing, confidentiality, etc.). We call such processes legacy security engineering processes. In this paper, we propose a change management framework for legacy security engineering processes. The key idea is to separate concerns between the requirements, risk and architectural domains while keeping an orchestrated view (as opposed to an integrated view). We identify some mapping concepts among the domains so that little knowledge is required from the requirement manager about the other domains, and similarly for security risk manager and the system designer: they can stick to their well known (and possibly certified) internal process. This minimal set of concepts is the interface between the legacy processes. The processes are then orchestrated in the sense that when a change affects a concept of the interface, the change is propagated to the other domain. We illustrate this example by using the risk modeling language (Security DSML) from Thales Research and the security requirement language (SI*) from the Univ. of Trento.