Charles B. Haley, Robin Laney, Jonathan D. Moffett, and Bashar Nuseibeh, Security
Requirements Engineering: A Framework for Representation and Analysis, (to appear in)
Transactions on Software Engineering (IEEE) (2007)
Summary:
Haley et al. propose a security requirement engineering framework for expressing
and analyzing security requirements as constraints on functional requirements. The paper
is based on three main contributions: definition of security requirements, considering
assumption and specially trust assumption about the system context, and finally,
satisfaction arguments.
This proposed framework distinguishes the security goals and security requirements.
Security goals aim to assets from harm, and operationalized into security requirements,
which are constraints on the system’s functional requirements. The framework introduces
four main activities to move from functional goals to final arguments that if the security
requirements are satisfied. The activities start with identifying functional requirements. In
the second step, security goals are identified, then, security requirements are identified,
and finally, satisfaction arguments are constructed. A set of security requirements core
artifacts is introduced that are developed during the activities, which mainly consists of
documenting application and security goals, assets, management control principles,
functional, quality, and security requirements, and system architecture.
While security goals is in form of a desire, such as confidentiality, security
requirements are in form of restricting statements such as “The system shall provide
service X only to authorized personnel”. Once the security requirements are gathered,
one must validate that security requirements satisfy the security goals, using the
satisfaction arguments. Satisfaction arguments consist of a formal outer argument and an
informal inner argument. The outer argument uses claims about the system behavior to
show that security requirements are satisfied. The inner argument uses Toulmin argument
approach to support claims and capture relationship between domain properties, by
developing a tree-like structure, where the leaf nodes of argument tree are unsupported.
Such statements are trust assumption about the behavior or properties of the world that
the system lives within.
Why it is good:
Considering trust assumptions, security policies and management control principles,
and security goals in the security requirements engineering are strong points of the
framework. They claim the proposed framework designs the system to determine its
requirements which is an interesting approach. The arguments, which check if the
security requirements are feasible in the contexts of the system, is a reason that they
claim they design the system and analyze requirements iteratively.
Problems and limitations:
However, the impact of possible attacks in the context of the system is missed in the
proposed framework. Assets and the harms that compromising the asset may pose is
considered to elicit the security constraints. However, potential attacks and their impact
on the functional and non functional requirements are not analyzed explicitly. In contrast
to several approaches that focus on attacks, the proposed framework does not related the
security goals to any threatening attacks and attackers. In addition, system vulnerabilities,
such as buffer overflow and password losses, are not considered in satisfaction
arguments.
The proposed framework deals with security requirements as constrains on the
functional requirements is intuitive. However, this constraint needs to be transformed to
an operationalization. However, it is not studied if designing and implementing
requirements in form of a constraint is more intuitive or functional representation of the
security requirements, like “the system should first authenticate the users to provide the
service” is more useful.
A typical security requirement would be like “The system shall provide service X
only to authorized personnel”. Then, it is left to the designer to find a solution to satisfy
this requirement. The designer choice might be password-based authentication, while this
introduces new vulnerabilities and potential attacks against the system, and consequently,
the designer needs to introduce new solutions to protect the password which may affect
other functional and non-functional (including security) requirements. Although the
authors of the framework points to the use of Twin Peak model in the proposed
requirements engineering approach, the framework does not explicitly deal with the
iterative impact of requirements, design, and attacks in each other.