CAIRIS

Creating a new project

The first stage of the design process involves establishing the scope of subsequent analysis. CAIRIS supports this exercise by using the Project Settings notebook.

Update project settings

fig:projectSettings

Environments

An environment might represent a system operating at a particular time of day, or in a particular physical location. Environments encapsulate visible phenomena such as assets, tasks, personas, and attackers, as well as invisible phenomena, such as goals, vulnerabilities, and threats. Environments may be identified at any time, although these may not become apparent until carrying out contextual inquiry and observing how potential users reason about their context of use.

Adding a new environment

fig:EnvironmentDialog

On-the-fly environment creation

fig:NewEnvironmentDialog

Most artifacts in CAIRIS are situated in one or more environments. When creating or updating an artifact, it is usually possible to create a new environment on the fly by right-clicking on the environment list box in the artifact dialog and selecting the New button. This opens the New Environment dialog box. In this dialog, an environment name, short code and description can be entered. When the create button is selected, a new environment is added to the CAIRIS database, and added to the environment list for the artifact.

Environmental attribute inheritence

An artifact may be situated in one or more environments, but the differences between these environments may be slight. To reflect this, it is possible for an artifact to inherit properties from another environment. To do this, right-click on the artifact’s environment list box and select the Inherit Environment option. When prompted, select the environment to inherit from, followed by the environment to situated the artifact in. In most cases, the properties of the inherited environment will be duplicated in this newly situated environment. In the case of goals and obstacles, only the immediate refinement associations are retained when inheriting properties from an environment.

Assets

Assets are tangible objects of value to stakeholders. By defining an asset in CAIRIS, we implicitly state that this needs to be secured in light of risks which subsequently get defined.

Assets are situated in one or more environments. Security properties are associated with each asset for every environment it can be found in. These security properties are Confidentiality, Integrity, Availability, and Accountability. Each of these properties is associated with the value of None, Low, Medium, or High. The meaning of each of these values can be defined in CAIRIS from the Asset Values dialog; this is available via the Options/Asset values menu.

Adding, updating, and deleting an asset

fig:AssetDialog

Asset modelling

Understanding how assets can be associated with each other is a useful means of identifying where the weak links in a prospective architecture might be. CAIRIS supports the association of assets, inconsistency checking between associated assets, and visualisation of asset models.

The CAIRIS asset model is based on UML class models. Asset models can be viewed for each defined environment. As well as explicitly defined asset associations, asset models will also contain associations implicitly defined. For example, if a task has been defined, and this task concerns within an environment contain one or more assets, then the participating persona will be displayed as an actor, and an association between this actor and the asset will be displayed. Additionally, if concern associations have been defined between goals and assets and/or associations then zooming into the model will display these concerns; the concerns are displayed as blue comment elements.

fig:AddAssetAssociation

Adding an asset association

fig:AssetInconsistency

Viewing Asset models

Asset models can be viewed by clicking on the Asset Model toolbar button, and selecting the environment to view the environment for.

fig:AssetModel

By changing the environment name in the environment combo box, the asset model for a different environment can be viewed. The layout of the model can also be replaced by selecting a layout option in the Layout combo box at the foot of the model viewer window.

By clicking on a model element, information about that artifact can be viewed.

Roles & Personas

Roles

Roles represent the abstract classes representing human agents; these also encapsulate behaviours and responsibilities. CAIRIS supports 2 types of role: stakeholder and attacker. Stakeholder roles represent human agents the system needs to be directly, or indirectly designed for. Attackers are human agents the system should not be designed for.

Adding, updating, and deleting a role

fig:RoleDialog

Responsibility modelling

Responsibility models can be viewed by clicking on the View Responsibility Model toolbar button, and selecting the environment to view the environment for.

fig:ResponsibilityModel

By changing the environment name in the environment combo box, the responsibility model for a different environment can be viewed. The layout of the model can also be replaced by selecting a layout option in the Layout combo box at the foot of the model viewer window.

By clicking on a model element, information about that artifact can be viewed.

Personas

Personas are specifications of archetypical users that the system needs to directly or indirectly cater for. The system needs to be specified for Primary Personas, but Secondary Personas cannot be ignored as their thoughts or concerns provide insight into potential usability problems.

Adding, updating, or deleting a persona

fig:PersonaDialog

Recording persona assumptions

fig:APModel

Tasks

Tasks model the work carried out by one or more personas. This work is described in environemnt-specific narrative scenarios, which illustrate how the system is used to augment the work activity.

Adding, updating, or deleting a task

fig:TaskDialog

fig:AddTaskPersona

Task traceability

fig:TraceabilityEditor

Tasks can be manually traced to certain artifacts via the Tasks dialog. A task may contribute to an asset or a vulnerability, or be supported by requirement. To add a traceability link, right click on the task name, and select Supported By or Contributes to. This opens the Traceability Editor. From this editor, select the object on the right hand side of the editor to trace to and click the Add button to add this link.

Manual traceability links can be removed by selecting the View/Traceability menu option, to open the Traceability Relations dialog. In this dialog box, manual traceability relations be removed from specific environments.

Visualising tasks

Task models can be viewed by clicking on the Task Model toolbar button, and selecting the environment to view the environment for.

fig:TaskModel

By changing the environment name in the environment combo box, the task model for a different environment can be viewed. The layout of the model can also be replaced by selecting a layout option in the Layout combo box at the foot of the model viewer window.

By clicking on a model element, information about that artifact can be viewed.

Domain Properties

Domain Properties are descriptive properties about the statement world. Domain Properties may be either hypothesis or invariants.

Adding, updating, and deleting a domain property

fig:DomainPropertyDialog

Goals, Requirements, and Obstacles

In CAIRIS, a requirements specification is analogous to a safety case. In a safety case, a system is only considered safe if its safety goals have been satisfied. In a similar manner, requirements are leaf nodes in a goal tree and satisfying stakeholder needs is only possible if the high-level goals – stipulated by stakeholders – can be satisfied.

We define goals as prescriptive statements of system intent that are achievable by one or more agents. Goals can be refined to requirements, which are achievable by only agent. Goals and requirements may also be operationalised as tasks. Alternatively, we may decide to specify tasks and ask what goals or requirements need to hold in order that a given task can be completed successfully.

To satisfy a goal, one or more sub-goals may need to be satisfied; satisfaction may require satisfying a conjunction of sub-goals, i.e. several AND goals, or a disjunction of sub-goals, i.e. several OR goals.

Goals or requirements may be obstructed by obstacles, which are conditions representing undesired behaviour; these prevent an associated goal from being achieved. By progressively refining obstacles, we can obtain the origin of some undesired behaviour; this may be reflected as a vulnerability or a threat, and contribute to risk analysis.

Adding, updating, and deleting a goal

fig:GoalsDialog

fig:GoalDialog

fig:AddGoalRefinement

Goal Modelling

Goal models can be viewed by clicking on the Goal Model toolbar button, and selecting the environment to view the environment for.

fig:GoalModel

By changing the environment name in the environment combo box, the goal model for a different environment can be viewed. The layout of the model can also be replaced by selecting a layout option in the Layout combo box at the foot of the model viewer window.

By clicking on a model element, information about that artifact can be viewed.

Goal models can also be filtered by goal. Applying a filter causes the selected goal to be displayed as the root goal. Consequently, goals are only displayed if they are direct or indirect leafs of the filtered goal.

Goals can also be refined from the goal model, albeit only for the environment being modified. To refine a goal, right-click on the goal in the model viewer, and select And-Goal, or Or-Goal based on the refinement desired. An simplified version of the Add Goal dialog box is displayed and, when all the necessary information has been added, a new goal will be added to the database, complete with the desired refinement. Please note, the model view needs to be refreshed to view the goal. Goals may only be refined to other goals in the model viewer; for anything more elaborate, the usual goal refinement association procedure needs to be followed.

Adding, updating, and deleting an obstacle

fig:ObstacleDialog

Obstacle Modelling

Obstacle models can be viewed by clicking on the Obstacle Model toolbar button, and selecting the environment to view the environment for.

fig:ObstacleModel

In many ways, the obstacle model is very similar to the goal model. The main differences are goal filtering is not possible, only the obstacle tree is displayed, and obstacles refine to obstacles, as opposed to goals.

Adding, updating, and deleting requirements

Requirements are added and edited using the Requirements Editor in the main CAIRIS window. Each requirement is associated with an asset, or an environment. Requirements associated with assets may specify the asset, constrain the asset, or reference it in some way. Requirements associated with an environment are considered transient, and remain associated with an environment only until appropriate assets are identified.

Requirement history

Every time a requirement is modified, a new version of the requirement is created. To view the requirement history, right click on the requirement to view the Requirement History dialog. This dialog contains the details of each version of the requirement stored in the database.

Searching requirement text

It is possible to search for a requirement with a particular text string, by selecting the Requirement Management/Find menu option, to open the Find Requirement dialog. This Find dialog is very similar to the Find dialog found in many WYSIWYG applications. This search function only works for requirements which are currently loaded in the Requirements editor.

Requirements traceability

Normally requirements traceability is synonymous with adding a goal refinement association but, requirements may also contribute to vulnerabilities (as well as tasks), or be supported by assets or misuse cases. Consequently, requirements can be manually traced to these artifacts in the same manner as tasks.

Requirement association

A requirement associated to an environment can be associated with an asset, or a requirement associated with an asset can be associated with another asset. To re-associate a requirement, right click on the requirement, select Asset re-association, and select the asset to re-associate the requirement with.

Security Patterns

Security Patterns are solution structures, which prescribe a solution to a security problem arising in a context. Many components and connectors in secure system architectures are instances of security patterns but, in many cases, the reasoning for a given pattern’s inclusion is not always clear. The requirements needed to realise these patterns are also often omitted, making the job of reasoning about the consequences of situating the pattern difficult. Moreover, security patterns may be described in a context, but not all collaborating assets in a security pattern may be evident in all possible contexts of a system’s use. The following sections describe how CAIRIS treats security patterns and deals with these weaknesses.

Security Patterns in CAIRIS consist of the following elements:

Before a security pattern can be defined in CAIRIS, template assets – which represent the collaborating asset classes – need to be first defined.

Before a security pattern can be situated in CAIRIS environments, the environments themselves need to be first created.

Create a template asset

fig:TemplateAssetDialog

Template assets can be best described as context-free assets. When they are created, template assets do not form part of analysis unless they are implicitly introduced. This ‘implicit introduction’ occurs when a security pattern is situated.

The Template Patterns dialog can be opened by selecting the Options/Template Assets menu option.

The process for creating, updating, and deleting a template asset is almost identical to the processes uses for normal assets. The only difference is the lack of environment-specific properties. Security properties are only defined once for the asset.

To situate an asset in an environment, right click on the template asset name in the Template Assets dialog box, select the Situate option, and specify the environments to situate the template asset in. After a template asset is situated within an environment, these properties should be revised in the assets generated on the basis of these. This is because the values associated with the template asset properties may not be inline with assumptions held about Low, Medium, and High assets in the specification being developed.

Create a security pattern

fig:SecurityPatternDialog

Situate a security pattern

fig:SituatePatternDialog

Template assets will be instantiated as assets, and situate in the stipulated assets. Requirements associated with the pattern, will be introduce and associated with the stipulated assets in the pattern definition. These assets will be ordered based on the order of definition in the pattern structure.

Vulnerabilities

Vulnerabilities are weaknesses of a system, which are liable to exploitation.

Create a vulnerability

fig:VulnerabilityDialog

Importing a vulnerability

fig:ImportVulnerabilityDialog

The CAIRIS database is pre-loaded with a database of template vulnerabilities based on the Common Criteria. To import one of these, select Import from the Vulnerabilities dialog to open the Import Vulnerability dialog. When a vulnerability is selected, the Vulnerability dialog is opened, and pre-populated with information from the template.

fig:ImportedVulnerabilityDialog

Attackers

Attackers launch attacks in the form of threats. Attackers are similar to personas in that fulfil one or more roles, and can be personalised with additional information.

Certain capabilities and motivations may be associated with attackers. CAIRIS is pre-loaded with a selection of these, but these can be modified, or new capabilities and motivations created by selecting the Options/Capabilities or Options/Motivations menu options.

Adding, updating, and deleting an attacker

fig:AttackerDialog

Threats

Threats are synonymous with attacks, and can therefore only be defined if an associated attacker has also been defined. Like vulnerabilities, threats are associated with one or more assets. However, threats may also target certain security properties as well, in line with security values that an attacker wishes to exploit.

A threat is also of a certain type. CAIRIS is pre-loaded with a selection of these, but these can be modified, or new threat types created by selecting the Options/Threat Types menu option.

Adding, updating, and deleting a threat

fig:ThreatDialog

Importing threats

fig:ImportThreatDialog

The CAIRIS database is pre-loaded with a database of template threats based on the Common Criteria. To import one of these, select Import from the Threats dialog to open the Import Threat dialog. When a threat is selected, the Threat dialog is opened, and pre-populated with information from the template.

Risks

Risks are defined as the detriment arising from an attacker launching an attack, in the form of a threat, exploiting a system weakness, in the form of a vulnerability. Associated with each risk is a Misuse Case. A Misuse Case describes how the attacker (or attackers) behind the risk’s threat exploits the risk’s vulnerability to realise the risk.

The current status of Risk Analysis can be quickly ascertained by viewing the Risk Analysis model. This displays the current risks, the artifacts contributing to the risk, and the artifacts which potentially mitigate it.

Adding, updating, and deleting a risk

fig:RiskDialog

fig:MisuseCaseDialog

Risk Analysis model

Risk Analysis models can be viewed by clicking on the Risk Analysis Model toolbar button, and selecting the environment to view the environment for.

fig:RiskAnalysisModel

By changing the environment name in the environment combo box, the risk analysis model for a different environment can be viewed. The layout of the model can also be replaced by selecting a layout option in the Layout combo box at the foot of the model viewer window.

By clicking on a model element, information about that artifact can be viewed.

The risk analysis model can also be filtered by artifact type and artifact type. Filtering by type displays only the artifacts of the filtered type, and its directly associated assets. Filtering by artifact name displays only the filtered artifact, and its directly associated artifacts.

Risk Responses

A risk can be treated in several ways.

By choosing to Accept a risk, we indicate that we are prepared to accept the consequences of the risk being realised. Accepting the risk comes with a cost, and responsibility for accepting a risk must fall on one or more roles.

By choosing to Transfer a risk, we acknowledge that dealing with a risk is out of scope for this project. It may still, however, have a cost associated with it and, by accepting the risk, the risk must become the responsibility of one or more roles.

By choosing to Mitigate a risk, we may either Prevent, Deter, Detect, or React to a risk. For detective responses, the response must detect the risk before, during, or after the risk’s realisation. For reactive responses, the response must be associated with an countermeasure asset derived from a detective response.

Adding, updating, and deleting a response

fig:ResponseDialog

Generating goals

A goal can be generated from a response by right clicking on the response name in the Responses dialog box, and selecting Generate Goal from the speed menu. This causes a goal to be generated in each of the environments the response is situated in. The goal name corresponds to the name of the response.

Countermeasures

After a response goal has been generated, goal modelling continues until one or more countermeasure requirements have been defined and associated with their parent goals. Following this, a countermeasure can be defined. Defining a countermeasure also has the effect of satisfying a response goal and resolving any obstacles associated with the underlying risk’s threat or vulnerability.

Countermeasures target a risk’s threat, vulnerability, or both. Countermeasures also have a level of effectiveness. This effectiveness level determines how much the countermeasure reduces the likelihood of the associated threat, or severity of the associated vulnerability.

Countermeasures are associated with roles, who may be responsible for developing, maintaining or using the countermeasure. Consequently, countermeasures are also associated with tasks and, when defining a countermeasure, it is also necessary to indicate how much the countermeasure helps or hinders the properties of associated tasks.

Adding, updating, and deleting a countermeasure

fig:CountermeasureDialogSecurity

fig:CountermeasureDialogUsability

Generating countermeasure assets and security patterns

By right clicking on a countermeasure in the Countermeasures window, an associated asset can be generated. If defined, this will retain the same security properties associated with the countermeasure. The asset will be situated in whatever environments the countermeasure was situated in. In the asset model, a << safeguard >> association is added between the countermeasure asset and any assets threatened or exposed by the risk the countermeasure helps mitigate.

Assets can be generated directly based on the countermeasure properties, or on the basis of a pre-existing template asset. It is also possible to situate security patterns based on a countermeasure, rather than an asset. To do this, select Situate Pattern from the speed menu, select the security patten, followed by the countermeasure environments to situate the pattern assets in.

Security Patterns can be imported into the tool by using the Import/Import Security Patterns option, and selecting the XML based patterns catalogue to import. An example catalogue file, schumacher.xml, which incorporates a number of patterns from the Security Patterns text book by Schumacher et al is included in the cairis/sql directory.

Associating countermeasures with pre-existing patterns

By right clicking on a countermeasure in the Countermeasures window, you can also associate a countermeasure with a pre-existing security pattern by selecting the ‘Associate with situated Countermeasure Pattern’ option. However, a list of possible security patterns to choose from will only be displayed if the components of the security pattern are present in ALL of the environments the countermeasure is situated for.

Weaking the effectiveness of countermeasures

Countermeasures mitigate risks by targetting its risk elements, i.e. its threats or vulnerabilities. However, when one or more assets are generated from these countermeasures, several factors may weaken the effect of the countermeasure.

First, situating assets may cause you to look at the environments where the assets are situated in a different light. Changing properties of assets, or existing threats or vulnerabilities could increase the potency of the risk, thereby weakening the effect of the countermeasure.

Existing threats or vulnerabilities can also explicitly weaken countermeasures. If a countermeasure asset is associated with a threat or vulnerability then, when either artifact is created or modified, CAIRIS allows users to override the effectiveness of the related countermeasure. The detail associated with the risk scores in the Risk Dialog box will indicate cases where countermeasures have been weakened by threats and/or vulnerabilities.

Mitigating weakening effects

If a countermeasure is weakened, the weakness by removed by generating a new countermeasure which targets the weakening threat or vulnerability. If this is carried out, the detail associated with the risk score in the Risk Dialog box will indicate cases where, although the effectiveness score for the countermeasure holds, this is by virtue of a countermeasure targetting the weakening threat or vulnerability.

Countermeasures cannot, however, be simply defined on the fly. They arise as the result of rational risk analysis, so risks need to be defined based on the weakening threats or vulnerabilities.

Generating Documentation

The current contents of the CAIRIS database can be generated as a requirements specification by selecting the Generate Documentation toolbar button. After the sections to be included are selected in the Generate Documentation dialog box, the target directory is prompted, following which the specification is generated as HTML, RTF, or PDF, based on the output options selected.

fig:GenerateDocumentationDialog