The DITSCAP (Department of Defense Information Technology Security Certi cation and Accreditation Process) is the standard certi cation and accreditation process for the Department of Defense of the USA. It proposes a process and a management structure to certify and accredit IS, with regards to information security.
The basis statement of this research work is that this certi cation and accreditation process generally provides not comparable and inconstant results [GL07]. Moreover, the information provided is usually inadequate, and it is thus di cult for the stake- holders to understand security risks and take the right decisions. Finally, the process is generally long and needs many resources to conduct the dierent necessary activities. The objective of this research work is therefore to improve this process of certi cation and accrediation.
The result is the DITSCAP automation framework. Its objective is to be integrated, well-de ned and comprehensive with respect to the DITSCAP [LGA05]. A key compo- nent of the framework is a problem domain ontology, built from regulatory documents, aiming at explicating the requirements with the help of DITSCAP domain concepts. Each requirement is explicated based on attributes that capture the goals, scenarios, viewpoints and other domain-speci c concepts. A model is proposed to explain the relationships between security requirements and risk components, for certi cation and accreditation purpose. It is used for identifying the risk components, and map them to concepts in domain-speci c taxonomies (e.g., of threats, assets, vulnerabilities, coun- termeasures) de ned within the approach. This model is an extension of the Common
Criteria model [Com06a], including security requirements and its relationships with the risk factors required to be considered in risk assessment [LGA05, GL07].
3.1.4 The SQUARE methodology
The SQUARE (Security Quality Requirements Engineering) methodology was pub- lished in 2005 [MHI05, MS05] by the Networked Systems Survivability program at the Software Engineering Institute, Carnegie Mellon University. It is de ned as a stepwise methodology for eliciting, categorising, and prioritising security requirements for in- formation technology systems and applications. A lighter version of SQUARE called SQUARE-Lite was also developed. A CASE tool to support the SQUARE process is also currently developed.
SQUARE is based on the assumption that, in software engineering, it is largely more costly to recover errors once the system is implemented compared to tackling them during RE phases. Errors in requirements lead generally to increase the bud- get of projects, to delay the project schedule, to deliver poor-quality or non-relevant products, and even sometimes to cancel the project. Naturally, security requirements are concerned by these assumptions. Moreover, security requirements are often ig- nored during the requirements elicitation process and added later, incurring higher costs. SQUARE proposes to carry out security during the early stages of software engineering and specify security requirements in similar ways as system functional requirements.
The SQUARE methodology is based on 9 steps summarised in Table 3.1. They are generally performed by a RE team with security expertise in conjunction with stakeholders of the project:
Step (1) Agree on de nitions: the RE team and the stakeholders agree on the terminology and on the de nitions to be used during the whole process.
Step (2) Identify security goals: based on business goals, the security goals to be reached are de ned; they are required to identify the priority and relevance of security requirements.
Step (3) Develop artifacts: it is necessary to collect or create some artifacts to support the next steps and mainly the security requirements de nition, like system architecture diagrams, use/misuse cases, attack trees, etc.
Step (4) Assess risks: risks are assessed, mainly by identifying threats and vul- nerabilities of the system and evaluating the likelihood of their occurrence.
Step (5) Select elicitation technique(s): a security requirements elicitation technique should be selected, taking into account the number and expertise of stake- holders.
Step (6) Elicit security requirements: the security requirements are elicited by using the chosen elicitation technique(s); this step is considered to be the heart of
3.1 Security requirements engineering frameworks 55
the SQUARE process.
Table 3.1: The nine steps of the SQUARE process (as they appear in [MHI05]) Num.
Step Input Techniques Participant Output
1 Agree on definitions
Candidate definitions from IEEE and other standards
Structured interviews, focus group
Stakeholders, require-
ments team Agreed-to definitions
2 Identify security goals
Definitions, candi- date goals, business drivers, policies and procedures, examples
Facilitated work ses- sion, surveys, inter- views
Stakeholders, require- ments engineer Goals
3
Develop artifacts to support security re- quirements definition
Potential artifacts (e.g., scenarios, misuse cases, templates, forms)
Work session Requirements engi- neer
Needed artifacts: sce- narios, misuse cases, models, templates, forms
4 Perform risk assess- ment
Misuse cases, scenar- ios, security goals
Risk assessment method, analysis of anticipated risk against organisational risk tol- erance, including threat analysis
Requirements en- gineer, risk expert, stakeholders
Risk assessment re- sults 5 Select elicitation techniques Goals, definitions, candidate techniques, expertise of stakehold- ers, organisational style, culture, level of security needed, cost benefit analysis, etc.
Work session Requirements engi- neer
Selected elicitation techniques
6 Elicit security re- quirements
Artifacts, risk assess- ment results, selected techniques
Joint Application De- velopment (JAD), interviews, surveys, model-based analy- sis, checklists, lists of reusable require- ments types, document reviews
Stakeholders facili- tated by requirements engineer
Initial cut at security requirements
7
Categorize require- ments as to level (system, software, etc.) and whether they are require- ments or other kinds of constraints
Initial requirements, ar- chitecture
Work session using a standard set of cate- gories
Requirements engi- neer, other specialists as needed Categorized require- ments 8 Prioritize require- ments Categorized require- ments and risk assess- ment results
Prioritization methods such as Triage, Win-Win
Stakeholders facili- tated by requirements engineer Prioritized require- ments 9 Requirements in- spection Prioritized require- ments, candidate formal inspection technique
Inspection method such
as Fagan, peer reviews Inspection team
Initial selected re- quirements, docu- mentation of decision making process and rationale
Step (7) Categorize requirements: the elicited security requirements are clas- si ed based on a standard set of categories.
Step (8) Prioritize requirements: using a prioritisation technique, priorities are de ned for the security requirements, that could be based on a cost-bene t anal- ysis.
obtain accurate and veri able security requirements.
3.2 Security-oriented modelling languages
Tackling security during the early phases of RE has been motivated in Section 1.3. This study of security-oriented modelling languages thus focuses on approaches dealing with early requirements. Some existing security-oriented modelling languages are thus explicitly not considered in this work. SecureUML [LBD02] is a modelling language helping to de ne access control policies. UMLsec [J04, J02] introduces a UML pro le for security, including activity diagrams, statecharts, sequence diagrams, static struc- ture diagrams, deployment diagrams, and subsystems. Both of these UML extensions are dedicated to late-RE and mainly design phase, and hence they are out of our scope. This study is mainly focused on the modelling language part of the approaches. The process aspects are quickly overviewed, with respect to the modelling parts that are explained in greater details. As an illustration, each modelling language is presented based on (part of) the running example (Section 1.6).
3.2.1 KAOS and its security extension
The KAOS (Knowledge Acquisition in autOmated Speci cation) approach consists of a modelling language, a method, and a software environment [vLL00]. It starts in 1990 from a joint project between University of Louvain (Belgium) and University of Oregon (USA). The objectives of KAOS are [CED03]:
• to t problem descriptions by allowing to de ne and manipulate concepts relevant to problem description,
• to improve the problem analysis process by providing a systematic approach for discovering and structuring requirements,
• to clarify the responsibilities of all the project stakeholders,
• to let the stakeholders communicate easily and e ciently about the requirements. The main purpose of KAOS is to ensure that high-level goals are identi ed and progressively re ned into precise operational statements [vL03, Let01]. These are then assigned to component agents of the software-to-be and its environment, both forming the so-called (composite) system-to-be. Along this process, various alternative goals and responsibility assignments are considered until the most satisfactory solution is chosen (Figure 3.1).
The KAOS modelling language
A global KAOS model includes four models: goal, object, agent and operation models. The goal model is the driver of the language and it de nes and re nes the goals of the system-to-be until requirements attributable to agents are found. The object model declares the objects of interest in the application domain. It plays the same role as the class diagram in UML [Obj04]. Then the responsibilities of agents for goals are de ned in the agent responsibility model. Complementary to the preceding model, the agent