Modelling access policies using roles in requirements engineering

Abstract

Pressures are increasing on organisations to take an early and more systematic approach to security. A key to enforcing security is to restrict access to valuable assets. We regard access policies as security requirements that specify such restrictions. Current requirements engineering methods are generally inadequate for eliciting and analysing these types of requirements, because they do not allow complex organisational structures and procedures that underlie policies to be represented adequately. This paper discusses roles and why they are important in the analysis of security. The paper relates roles to organisational theory and how they could be employed to define access policies. A framework is presented, based on these concepts, for analysing access policies. q

Deriving security requirements from crosscutting threat descriptions

“…It would be useful to have some traceability between constraints and the threat(s) they counter; we are looking at the representation Rashid et al propose in [24] and at an adaptation of the multi-dimensional concerns matrix proposed by Ossher and Tarr in their work describing ondemand application remodularization [22]. Better integration with some of our colleagues' research, such as the organizational access control work of Crook [4] and the abuse analysis work of Lin [17], is desired. As noted in the related work section, the expressive powers of this approach and o [15]) need to be better understood.…”

Secure information systems engineering: a manifesto

“…However, information systems engineering and security engineering research communities traditionally work independently. On the one hand, information systems engineering techniques and methodologies do not consider security as an important issue, although they have integrated concepts such as reliability and performance and they usually fail to provide precise enough semantics to support the analysis and design of security requirements and properties (Crook et al, 2003;Mouratidis, 2004). On the other hand, security engineering research has mainly produced formal and theoretical methods, which are difficult to understand by non-security experts and which, apart from security, they only consider limited aspects of the system.…”

“…In addition, Van Lamsweerde (2004) defines also the notion of antimodels, models that capture attackers, their goals and capabilities. Similarly, Crook et al (2003) introduce the notion of antirequirements to represent the requirements of malicious attackers. Antirequirements are expressed in terms of the problem domain phenomena and are satisfied when the security threats imposed by the attacker are realised in any one instance of the problem.…”

“…In particular, Devanbu and Stubblebine (2000) state on their roadmap on information systems engineering for security "security concepts must inform every phase of software development, from requirements engineering to design, implementation, testing, and deployment". Similarly Crook et al (2003) state "our vision is that we will be able to model these [security] concepts and integrate them into the requirements engineering process". In line with these statements, Mouratidis et al (2005) argued that security should be considered from the early stages of the development process and security requirements should be defined alongside with the system's requirements specification.…”

Secure Interaction Models for the HealthAgents System

“…Without the context of accomplishing one or more tasks in different privilege levels, information access makes no sense. The rational of using a combined multilevel and multilateral model is further supported by the fact that a job responsibility is determined by the level of authority and the division of work [14]. The former prevents information flow downwards and the latter prevents information flow across, being concerned about workgroup membership and job speciality under our further refinement.…”