1. Mouratidis, H., Giorgini, P., Manso, G., Philp, I., A Natural Extension of Tropos Methodology for Modelling Security, In Proc. of the Workshop on Agent-oriented methodologies, at OOPSLA (2002) 91-103.
2. Mouratidis, H., Giorgini, P., Manso, Modelling Secure Multiagent Systems, In the Proc. of the 2nd Int. Joint Conf. on Autonomous Agents and Multiagent Systems (2003) 859 – 866
Summary:
This contribution [1] introduces extensions to Tropos methodology for incorporating security concerns into the agent-oriented development process. To integrate the security concerns into the Tropos methodology, the concepts of security diagram, security constraint, secure dependency, and security goal, task, and resource is introduced.
The security diagrams contain security features of the system-to-be, the protection objectives of the system, the security mechanisms, and also the threats to the system’s security features. To model these concepts Tropos modeling notation is used and extended. The concept of softgoal is used to capture security features. Security feature receives positive contributions from different protection objectives and negative contributions from the threats. Security mechanisms contribute positively or negatively to the protection objectives. Security objectives are expressed by the goal modeling construct, and security mechanisms are modeling using the i* tasks. Threats represent circumstances that have the potential to cause loss or problems that put the security features in danger. To model threats a new modeling constructs is added to the i* modeling notation.
All secure entities are tagged with “s” to indicate these tasks, goals, and softgoals are security related. In this work, security requirements are dealt as constraints. Concept of constraint is different from the concept of a goal. By imposing security constraints to different parts of the system, possible conflicts between security and other requirements are identified. The assignment of a security constraint to a goal is indicated using a constraint link that has the “restricts” tag. In this way, the context of the constraint is defined. Using security constraints, a secure dependency introduces security constraint(s) to successfully satisfy the dependency.
In another similar work, Mouratidis et al. [2] add secure capabilities of actors to the contribution in [1]. In this work, the Secure Tropos is fitted into all phases of development: early and late requirements, and architecture and detailed design. However, the capabilities or lack of capabilities do not affect the architecture and detailed design.
Why it is good:
The proposed diagrams and the modeling notations are fitted into the Tropos methodology. The proposed modeling approach targets early and late requirements engineering phases of development. Using constraint on the goals by a contribution from the goal to the constraint, and the “restrict” relation from the constraint is intuitive. By expressing restrictions and introducing security objectives and mechanisms that satisfy the constraints, the rationale for having security objectives and mechanisms are expressed.
Problems and limitations:
In this work, all security related entities are tagged with a “s”, while distinguishing the security entities from other systems entities does not affect the result of analysis on the models.
The notion of threat introduced in the secure Tropos is limited to a visual representation. The threats are not assigned an attacker and goals and refinements of the attacks are expressed.
I still can’t think of why security constraints are not necessary. Are there cases that we need to express the negative goals? Yes, I have seen it in student assignments. They are not anti-goals (malicious), but they are goals with a negative or restricting statement in it, like the constraints that was introduced in this contribution.