Table of Contents

Security Requirements Engineering

Among the research topics of the Security Group we focus on here on the design and validation of a methodology for security engineering that starts from the elicitation of socio-technical requirements down to the identification of security controls. Within the main stream project we covered a number of themes.

Compliance with Regulations

The approach started from the Toronto i* goal modelling language which included the notions of goals and dependencies among actors. In the course of the project we refined it by introducing notion of actors’ relationship and goals focusing on permissions, entitlements, risks, and mitigation. With these concepts we could capture legal and compliance requirements, map them into a goal-based organizational model, and then refine it to a standard business process. A key issue in this respect is the ability to provide Compute Aided Support to decision makers, as the model in itself is not important: what we need is algorithms which take the model as input, distill the complexity of the model to bring new information to the human decision maker. If a construct doesn't bring a new algorithm, and the possibility for the decision maker to make a different decision, it is not worth adding it to the models.

The figure below from a multidisciplinary journal paper with SAP Researchers, and a law researcher on the integration of modeling for legal compliance describes how different stake-holders should interact with a level of details that is suitable for them.

Evolving Security Requirements

Requirements evolution are unavoidable for any life-long system due to changes in business objectives, regulations, standards, environment or threats. In many cases, these changes are not completely unknown. For instance, the ongoing discussion in a standard body might feature two or three proposals, albeit might not be clear which one will finally win. A possible solution to the challenges of requirements evolution is to choose a good design alternative that could still work when evolution happens to minimize the risk and maximize the benefit.

While many approaches have been proposed to perform the management or consistency checking on requirements evolution, there has been less effort on delivering an explicit modeling and reasoning framework to assist decision managers select a good design alternative. We need to capture what Loucopoulous and Kavakli [ER-99] identified as the knowledge about “what the current state is”, “where the desired state to-be is in the future”, and “alternative designs” for the desired future state. In this respect it is important to provide a sound quantitative analysis, which is one of the current weaknesses identified by Dalal et al. [CACM-04] of many existing approaches.

We are working on a generic approach which tackles the fundamental issue of modeling and reasoning about requirements evolution to aid such decision making. The modeling support represents requirements evolution in terms of controllable and observable rules in which probability estimates can be accounted by using game-theoretic semantics. The reasoning support provides three quantitative metrics to identify which requirements must be implemented to guarantee the best chances of success (Max Belief) or minimize the risk of wasting money (Deferral Risk and Max Disbelief).

People

The following is a list of people that has been involved in the project at some point in time.

Projects

This activity was supported by a number of project

Publications

2013

2012

2011

Earlier papers

Talks and Tutorials

Software