KAOS and its security extension

The KAOS (Knowledge Acquisition in autOmated Specication) 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 dene 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 eciently about the requirements. The main purpose of KAOS is to ensure that high-level goals are identied and progressively rened 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 denes and renes 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 dened in the agent responsibility model. Complementary to the preceding model, the agent

3.2 Security-oriented modelling languages 57

Figure 3.1: The goal-driven requirement elaboration process (as appears in [Let01])

interface model declares which objects are monitored and controlled by each agent. Finally, the operation model denes the state transitions in the application domain [Let01]. We illustrate KAOS goal and operation model through some snapshots relative to @rchimed (Figure 3.2). We focus on the goal model, since it is the most relevant for early requirements, and complement it with the operation model to have a more complete view of our example. On these two diagrams, we also introduce some key elements of the agent and object models. More information about the dierent kinds of models in KAOS can be found in [Let01].

Figure 3.2 illustrates the dierent concepts of the KAOS modelling language on the running example and more specically on the establishment of structure calcu- lation by the study oce. In KAOS a goal is a prescriptive assertion that cap- tures an objective that the system-to-be should meet. In Figure 3.2, examples of goals are Achieve[BuildingValidated], Avoid[StructureCalculationModified- ByCrook], and Avoid[LoginInformationKnownByCrook]. A goal can belong to one of four patterns: maintain, avoid, achieve and cease, which declare the temporal be- haviour categories corresponding of a goal change [Let01]:

• Achieve goals: goals requiring that some property eventually holds • Cease goals: goals requiring that some property eventually stops to hold • Maintain goals: goals requiring that some property always holds

• Avoid goals: goals requiring that some property never holds

In addition, goal categories provide a further goal classication helping in goal acqui- sition, denition and renement (e.g., Satisfaction goals are Achieve goals concerned with satisfying agent wishes; Safety goals are Maintain goals concerned with avoiding hazardous states; Security goals are Maintain goals concerned with avoiding threats to the system, etc.).

Figure 3.2: Fragment of the goal and operation model for the study oce of @rchimed

A goal can be rened through G-renement, which relates it to a set of subgoals whose conjunction, possibly together with domain properties, contributes to the satis- faction of the goal. For example, in Figure 3.2 the goal Achieve[BuildingValidated] is rened to two subgoals PerformStructureCalculation, Avoid[StructureCalculation- ModifiedByCrook], and one domain property ParametersAreReliable. A goal can have alternative G-renements (e.g., Avoid[StructureCalculationModifiedByCrook]), which result in dierent designs of the system-to-be.

An object (e.g., DatabaseOfParameters) is a (kind of) thing(s) of interest in the system1_{. Its instances can be distinctly identied and may evolve from state to state.}

Objects have attributes (e.g., Materials, Surfaces, etc.), which characterise the states of the system-to-be.

An agent (e.g., Engineer) plays a role towards a goal's satisfaction by control- ling object behaviour. Goals are rened until they are assigned to individual agents. A goal eectively assigned to a software agent (in Figure 3.2: PerformStructure- Calculation) is called a requirement. A goal eectively assigned to an environment agent is called an expectation.

3.2 Security-oriented modelling languages 59

An operation (in Figure 3.2: EnterBuildingInformation, LaunchCalculation, and SelectContextParameters) is an input-output relation over objects. Operations are characterised textually by domain (DomPre, DomPost) and required (RegPre, Re- qTrig, and ReqPost) conditions [MHO06]. Whenever the required conditions hold, performing the operations satises the goal. If a goal is operationalised and has a responsible agent (e.g., PerformStructureCalculation), the latter performs the op- erations.

KAOS extended to security

Figure 3.3: Fragment of the anti-goal and attack method model for the study oce of @rchimed

In KAOS, the concept of obstacle was rst introduced [vLL00]. An obstacle to some goal is dened as a condition whose satisfaction may prevent the goal from being achieved. However standard obstacle analysis approach has been assessed as too

limited to deal with malicious obstacles [vL04]. An interest has been highlighted to clearly show the goals underlying malicious obstacle, and to model attacker agents, their capabilities, and the vulnerabilities of the system-to-be. The reasoning behind building such intentional models about malicious goals has also been evaluated as relevant in order to be more exhaustive in the analysis [vL04].

KAOS extended to Security (KeS) has thus been introduced in [vL04]. Security of the system-to-be is dened in the traditional goal model using security goals, which concern sensitive objects. In the example (Figure 3.2) Avoid[LoginInformation- KnownByCrook] concerns DatabaseOfParameters that could be threatened if the goal is not respected. To identify the goals of the attacker, an anti-model composed of anti- goals is built showing the attacker's own goals (Figure 3.3). An attacker is dened as a malicious agent in the environment. Examples of anti-goals are Achieve[Login- InformationKnownByCrook] and Achieve[PasswordLearntByTheUser]. Anti-requi- rements which are terminal anti-goals assigned to the attacker (e.g., Achieve[UseSocial- EngineeringToFindThePassword]) and vulnerabilities (represented as domain proper- ties) assigned to the attackee (e.g., EmployeesNotSecurityAware) are also identied. Associated object and agent anti-models can be built too.

Once the intentional anti-goal model has been built, the next step is to consider countermeasures to the identied anti-requirements and vulnerabilities. Categories of countermeasures are for example goal substitution, agent substitution, goal weakening, goal restoration, anti-goal mitigation, anti-goal prevention, vulnerability protection, or vulnerability avoidance [vL04]. The selected countermeasure decisions yield new se- curity goals to be integrated in the models. For example, countermeasures for the example in Figure 3.3 include vulnerability avoidance: the following security goals Avoid[EmployeesAreNotSecurityAware] shall be added (not represented in Figure 3.2). The new security goals need to be rened until requirements and expectations are reached. A new anti-model may be further created for new emerging security goals, if necessary.