Analysing Behaviour and Solutions (Analysis)

The implemented analyser operates on a snapshot of subject behaviour at the time a violation has been detected. To mitigate violations, the analyser relies on a set of template solutions that contain actions applicable to the ABACMM.

These template solutions, contained within a solution policy, define the type of adaptations the controller can apply to its target system.

A limitation to this approach is that the analyser requires each violation to be mitigated in order of detection, where this may lead to redundant adaptations or bottlenecks in mitigation. Future implementations of the analyser should aggre- gate detected violations, as well as operate with a fluid perception of behaviour.

Behaviour Analysis

Behaviour analysis is implemented through the assessment of current and previ- ous trigger violations. It requires a perception of behaviour, defined within the controller’s behaviour model (BhvM). The BhvM is a collection of real time prop-

erties and violations assigned to relationships within the prototype’s ABACM. It

is the product of SAAF’s monitoring and analysis stage, where properties reflect trigger conditions defined within the behaviour policy.

For example, a set of triggers within the behaviour policy drives the dynamic creation of gauges. Each gauge relates to a specific relationship within the ABACM, such as r1=hsubject .Bob, role.Researcher , resource.ElectronicLibraryi.

A gauge creates and maintains a particular property of its ABACM relationship,

such as totalDownloads, based on the conditions described within its respective trigger. Given a set of gauges, a collated set of properties are maintained, such as a tuple of properties htotalDownloads, requestsPerMin, requestsPerHour i for each instance of an applicable ABACM relationship. As trigger conditions conform to

properties, violations are stored within the BhvM, maintaining a historical view of

all violations associated to their respective ABACM relationships. It is assumed

that all relationships can be connected to a source subject, in which to derive a complete view of a subject’s behaviour and violations.

Given the BhvM, behaviour analysis must identify if a subject’s behaviour

warrants adaptation. A normalisation function is implemented to calculate the impact of a subject against the organisation’s resources, based on the number and aggregated cost of their violations. Each time a subject is detected in performing a violation, the subject’s impact (SubImpact) is calculated and normalised on a scale

of 0 to 1, where 0 represents no malicious impact, and 1 represents the highest malicious impact. Albeit simplistic, the naive approach enables the escalation of a subject’s impact, given the persistence in identified violations over time. However, beyond the proof of concept it will be necessary to consider a far wider set of factors in determining impact, over cost alone.

SubImpact =

(P vw × Vcount) − Costmin

Costmax − Costmin

As such, SubImpact is calculated as the sum of all costs of the subject’s violations

vw (derived from the corresponding triggers within the behaviour policy) multiplied

CHAPTER 4. MODEL DRIVEN SELF-ADAPTIVE AUTHORISATION 98

on a minimum and maximum cost that is set by the organisation in order to define the extreme bounds of impact a subject can exert on an organisation.

Solutions

Solutions are characterised in terms of a change to the target system’s state of access. The solution policy contains a set of template solutions, whereby each solution is described by a tuple of required minimum observed impact (i.e., before considering this solution against a violation), a set of parameterised solution ac- tions (i.e., executable operations against an ABACM), and a subset of behaviours

that a solution can mitigate (i.e., described by the behaviour policy). The mini- mum observed impact is a value between 0 and 1, defining the scope of solutions applicable to a subject’s calculated impact (calculated in behaviour analysis).

Each solution action describes a tuple of paramaterised operation and a cost weighting. The paramaterised operation is an action that adapts a particular aspect of the ABACM (e.g., lowerSubjectAccess(Subject), or removeAttributePer-

mission(Attr,Perm)). Whereas the cost weighting defines an artificial cost that describes the perceived consequence to an organisation (e.g., the potential cost lost to an organisation for completely removing a subject’s access).

For the prototype controller, the extent of solution actions are constrained to removing and lowering the scope of access, either on an individual scale (subject adaptation) or collective scale (policy adaptation), in conformance to the proto- type’s ABACMM.

Likewise to SAAF’s behaviour policy, the solution policy is also defined using a proprietary XML schema specific to SAAF. The solution policy’s specification, along with a complete list of implemented solution actions are described in Ap- pendix A.7.

Solution Analysis

Once violations have been detected and analysed, a set of applicable solutions are identified. Given the calculated impact of detected violations, solution analysis filters applicable solutions based on violation impact meeting the solution’s min- imum impact threshold. This enables the controller to scope a set of solutions that mitigate the violation, based on the varying impact and persistence of a sub- ject’s malicious behaviour. For example, given a subject persistently identified as causing violations, solutions with greater consequence to the subject are chosen.

Figure 4.7 depicts a partial view of the SAAF controller, capturing the process of analysis, and providing the planner component with a set of solutions (as adapted ABAC models). Here the analyser has analysed a subject’s malicious behaviour, and identified a set of solutions, denoted as {S1_{, S}2_{, S}3_{}. Each solution}

is tailored in terms of populating the required parameters for each solution action, either from the ABACM, or from the attributes of the detected violations. These

tailored solutions are then used to adapt a snapshot of the current access control model, resulting in a set of adapted ABAC models, exemplified by {ABACM1,

ABACM2, ABACM3}.

Figure 4.7: SAAF controller model verification

In some cases, where verification has been incorporated (i.e., to verify against an organisation’s set of security requirements), these adapted models can be veri- fied using the rbacDSML model verification component1_{. Depending on a positive}

output of the verification tool (if applicable), the adapted ABAC models are col- lated into a set of verified models, and sent to the planning component.

Solution Verification

For enabling verification, the prototype utilises a standalone version of rbacDSML, by Montrieux [88]. Providing the prototype’s target system conforms to the RBAC standard, any adapted ABAC model can be verified using rbacDSML.

Each adapted ABAC model represents a new state of access within the au- thorisation infrastructure, essentially iterating changes in the design of access. It

1_{Verification is limited to only RBAC compliant variants of SAAF’s ABAC}

M, as rbacDSML

CHAPTER 4. MODEL DRIVEN SELF-ADAPTIVE AUTHORISATION 100

is therefore necessary to obtain assurances that the new design will not conflict with any of the organisation’s security requirements. For example, ensuring that all resources are accessible by at least one subject. An organisation’s security re- quirements are defined in SAAF’s constraints model, which is a static UML model expressed in rbacDSML’s own proprietary UML profile.

The standalone version of the rbacDSML tool achieves verification of an access control model via the execution of OCL constraints. Each security requirement, defined as a rbacDSML scenario within SAAF’s constraint model, has a context : a stereotype on which the scenario applies. The verification process evaluates each OCL constraint on every instance of its context stereotype present in the adapted ABAC model. For example, an RBAC static separation of duties (SSoD) constraint’s context is the rbacDSML’s User stereotype (synonymous to subject ). If there are 20 subjects within the adapted ABAC model, the SSoD constraint will be evaluated 20 times, once for each subject.

Figure 4.8: Transformation of ABAC to rbacDSML

For the prototype controller to make use of the rbacDSML verification tool, the constraints model and adapted ABAC model have to be transformed into an rbacDSML compliant UML model of RBAC. This is achieved by invoking an ATL model transformation program: ABAC+CON2RBACDSML, as shown in Figure 4.8. The transformation program combines the adapted ABAC model (ABACM) and the constraints model (ConstraintsM), and outputs the rbacDSML

model (rbacDSMLM).

Upon completion of the transformation, the model is verified against the con- straints now woven within adapted ABAC model, in order to evaluate the model against the organisation’s security requirements. The result is either a list of vio- lated security requirements, together with their context elements. For example, if the RBAC SSoD constraint has been violated for subject Bob, rbacDSML returns WF SSoD, Bob as an element of the list. If no constraints have been violated,

rbacDSML returns an empty list.

Each of the prototype’s generated adapted ABAC models undergoes model verification. Should all of the adapted models return violations, the prototype assumes there are no candidate solutions that can mitigate the detected violations. The failure to handle an adaptation is logged by the controller for further action to be taken by human administrators.