The following describes the conceptual aspects of each of the four stages of the SAAF controller’s feedback loop. Each stage is broken down into a set of activities, which rely on a set of models (i.e., knowledge) to facilitate their objectives.
3.4.1
Models (Knowledge)
Models are essential to SAAF, as they provide the perception of ‘self’ in terms of the state of the authorisation infrastructure, and the environment. SAAF
promotes the following three models to support its feedback loop.
Access Control Model
The access control model (ACM) exists to support the feedback loop with a mod- elled perception of the state of access control. It is essential for the reasoning of the runtime state of access, which ensures appropriate, consistent, and verified adaptation prior to the enactment of any change against the target system.
In essence, the ACM is a homogeneous model that conforms to a given access control methodology (e.g., RBAC). It is causally connected (Figure 3.3) to the target system’s deployed access control policies and subject privileges. As such, the homogeneous model should be capable of modelling the state of access control exhibited in many diverse implementations of a given approach to access control. For example, a PERMIS policy [31] and XACML [100] policy both conform to RBAC, yet exhibit diverse differences in terms of format, structure, and terminol- ogy. It is therefore important for an autonomic controller that seeks to manage RBAC to be capable of abstracting from these complexities.
Figure 3.3: Causal connection of access control model to target system
In addition, the ACM is holistic, whereby aspects of access control distributed across services within a target system are combined. This is essential to identify- ing emergent relationships as a consequence of the integration of services within an authorisation infrastructure. For example, several access control policies con- tained within an authorisation service describe constraints over access to protected resources. It is important to combine these constraints with assigned subject privileges contained within identity services, as to identify relationships between subjects, their privileges, and accessible resources.
CHAPTER 3. SELF-ADAPTIVE AUTHORISATION FRAMEWORK 58
Finally, given the ACM’s causal relationship with the target system, adapta- tion of the ACM should generate potential new states of access within the target system. As such, meta-information must be maintained to specify ownership (i.e., the service(s) an asset exists in), which is essential to derive the relevant access control policies or user privileges for a given service within the target system.
Behaviour Model
The behaviour model exists to provide a perception of subject activity in relation to the modelled state of access. It is essential to identifying and recording current and historic violations in subject behaviour, as to attain a view of malicious behaviour against the organisation over time.
Primarily, the behaviour model seeks to maintain a set of mutable properties for each relationship within the access control model (ACM). These properties reflect patterns of interest concerning the controller’s perception of malicious be- haviour, and are dynamically generated and updated as a result of the autonomic controller’s monitoring stage. For example, given the relationship r1 that de-
scribes a subject’s ability to access a resource with a certain privilege, a set of mutable properties may describe rates of successful or failed access attempts once the relationship has been observed.
Ultimately, properties maintained within the behaviour model are used to iden- tify malicious behaviour, based on the autonomic controller’s perception of mali- cious behaviour. As such, the identification of malicious behaviour (referred to as violations) is also recorded within the behaviour model.
Maintaining a history of violations enables the analysis of subject behaviour in regards to malicious activity over time. In this case, analysing both new and historical violations is seen as a critical factor when selecting appropriate solutions to mitigate recently detected violations.
Constraints Model
The constraints model captures an organisation’s security requirements, in terms of controlling the extent of adaptation. It is essential to providing assurances against the realisation of undesirable states of access that are a consequence of adaptation.
Unlike the access control model and behaviour model, the constraints model is static and defined at deployment time. It contains a set of constraints used as
test cases to verify any adaptation made against the access control model, prior to enactment within the target system. The non-compliance of test cases denote an undesirable state of access control, meaning a given adaptation does not conform to the organisation’s security requirements.
The type of test cases that can be defined within the constraints model is dependent on the access control model that the target system implements. For example, in the case of RBAC Core, there is a limited set of test cases that can be evaluated, as detailed in Table 3.3. The table exemplifies a set of test case types that can be verified against a modelled state of access that conforms to RBAC Core, whereby an example instantiation of the last test case would be: The printer resource should be accessible by at least one subject.
Test Case Type Description
Subject, Role Test a subject is assigned a certain role Role, Permission Test that a role can perform a permission
Role, Resource Test that a role can access all actions on a resource
Role Test a role has been assigned to a minimum set of subjects Resource Test that a resource can be accessed by a minimum set of
subjects
Table 3.3: Example adaptation constraints as test cases for RBAC core
Constraints, or even the use of a constraints model is subjective to a deploy- ment of SAAF. For example, different organisations will have their own require- ments over the criteria of access at development time, and this would be extended to reflect requirements over the criteria of access at runtime. Should no constraints exist, it is assumed adaptation is unrestricted in changing the state of access.
3.4.2
Monitoring
The monitoring stage of SAAF is comprised of three activities: change detection, the update of state of access, and update of state of subject behaviour. Figure 3.4 describes the flow between these three activities, and ultimately the initiation of the analysis stage. These activities are described as follows.
Change Detection
The first activity of the monitoring stage involves the detection and filtering of changes sent by probes within the target system and environment. Changes are
CHAPTER 3. SELF-ADAPTIVE AUTHORISATION FRAMEWORK 60
Figure 3.4: Monitoring stage (normal and exceptional flow)
filtered based on relevance to the controller’s perception of state. Changes are either relevant to maintaining a synchronised model of access (i.e., the runtime parameters of the target system), or relevant to maintaining a perception of subject behaviour.
With regards to the perception of behaviour, the monitoring stage relies on a set of heuristic based rules referred to as triggers. Triggers define the conditions for malicious behaviour, and if met, trigger the need for analysis. Each trigger rule describes a relationship that can exist within the feedback loop’s access control model, along with a set of conditions that describe malicious behaviour.
Several types of triggers can be considered. These are constrained to classifying ‘known’ patterns of malicious behaviour (defined by the deploying organisation). From the viewpoint of the organisation, any behaviour that meets trigger condi- tions is viewed as malicious. This is considered to be an ‘expert’ based approach to identifying only known malicious behaviour, where an organisation defines the extremes in behaviour. Adopting alternative approaches, such as a learning-based approach [86] present additional challenges in asserting anomalous activity as be- ing malicious. Whilst a learning-based approach (e.g., machine learning [86]) has the ability to detect unknown malicious behaviour (i.e., not defined by the organisation), it requires greater levels of confidence that detected behaviour is malicious.
In regards to detecting ‘known’ malicious behaviour, the following example trigger types are defined:
• Signature based - A specific action observed, such as access requests made from a blacklisted IP address, or a specific step in an attack.
• Pattern based - A pattern of access requests or resource activity, such as a threshold of high frequency access requests to a particular resource by a particular subject / access right / identity service.
• Transactional based - A sequence of events that should be adhered to in terms of access or resource activity, such as a subject following an applica- tion’s workflow.
• Deviation based - Thresholds that denote a measure of deviation between current behaviour and past behaviour, such as deviation of a subject’s access requests to a particular resource based on average frequency and times of day.
Modelling the State of Access
As changes to the runtime parameters of the target system are detected, it is necessary to maintain a synchronised perception of the current state of access. This refers to the causal connection between the SAAF controller’s access control model and the active access control policies and subject privileges distributed within the target system. The activity is critical in ensuring that any potential adaptation has been derived from a perception of state that is consistent with the target system. Failing this, adaptation performed cannot be seen as accurate.
The manner in which a target system defines its runtime parameters is im- portant, as it is specific to its given implementation. As such, in order to attain a modelled perception of state of access within the target system, the implemen- tation’s specific view of access must be translated / transformed into a homo- geneous representation that a SAAF controller can understand. This is not a trivial activity, as transformation must consider the diversity in format, struc- ture, terminology, and the relationship between terms, which may vastly differ in implementations of subject privileges and access control policies.
Various approaches exist to enable transformation, such as model transforma- tion [126] or the use of ontologies [84]. Ontologies have already been demonstrated by Shi et al. [129] in successfully mapping an implementation of RBAC access con- trol policies into another (e.g., the transformation of PERMIS policies [32] into XACML policies [100]).
Regardless of the approach used, the process of transformation should exhibit two necessary outcomes:
CHAPTER 3. SELF-ADAPTIVE AUTHORISATION FRAMEWORK 62
• A homogeneous model of access that the SAAF controller can understand for a given access control methodology (e.g., RBAC).
• The emergent relationships that describe a subject’s connection to protected resources, in regards to subject privileges, and defined permissions.
Without the use of a homogeneous model, any implementation of a SAAF controller becomes limited to a specific implementation of a target system. In addition, the inability to identify a subject’s relationship to protected resources severely limits the granularity of adaptation in mitigating violations (as the SAAF controller has no means to identify which privileges were used to perform viola- tions).
Modelling the State of Behaviour
As with the modelled state of access, a SAAF controller seeks to maintain a modelled state of behaviour. Maintaining a perception of behaviour is crucial to identifying the ongoing abuse of access rights. This involves measuring properties of subject activity in their use of access rights and resources in authorised sessions. The monitoring stage’s change detection activity employs a technique to dy- namically generate properties of a system at runtime. It is based on an approach of using gauges, as demonstrated by the Rainbow Framework [53]. A gauge is es- sentially a component of a self-adaptive system that can measure a specific system or environment property. In Rainbow’s case, this may be to measure the latency of a network device, or fidelity of a content delivery service.
In SAAF’s case, the scope of properties observable of subject activity is poten- tially unbounded, where a static approach to configuring such properties presents a number of limitations. For instance, one would need to hardcode every sin- gle property specific to a SAAF controller’s set of triggers, in order to identify violations in behaviour. Therefore, a dynamic approach is needed to generate properties of interest on the fly, as and when relevant subject activity is detected. To achieve this, change detection must dynamically generate a set of behaviour gauges, by interrogating the current state of access, and matching relationships of interest presented by triggers. The modelled state of access essentially presents a collection of unique relationship in which properties can exist. Triggers on the other hand express relationships of interest (within the state of access) and a set of conditions. A condition specifies a constraint on the relationship, which indicates malicious behaviour if broken.
For example, a trigger may define the relationship subject with the role of ‘staff ’ that accesses the resource ‘printer’, and a condition that states access cannot be greater than 15 requests per hour. In order to detect a violation of this trigger, it is necessary to measure the rate of access for any members of staff accessing the printer. If there are 20 members of staff that conform to the trigger relationship (i.e., subjects that can access the printer using role ‘staff’), then there are at least 20 properties to measure (i.e., the frequency of access per hour).
Figure 3.5: Gauge generation (detection of environment change)
For each change event detected by the monitor, the monitoring stage goes through the following steps (Figure 3.5) to maintain the modelled state of be- haviour:
1. Process environment change: Identify relationships within the modelled state of access in which the change event conforms to. In turn, identify the set of triggers which express an interest in conforming relationships;
2. Identify gauge: Each gauge contains a unique hash in which to match to a specific property on a relationship, derived from the gauge parent trigger. Should a set of triggers be identified as relevant for a detected change event, this step aims to identify if past gauges have already been created;
3. Create gauge: Should no gauges exist but a change event matches a set of triggers, it is necessary to create new gauges in order to evaluate conditions set out by triggers. This is akin to a subject requesting access for the first time, and in order to measure their rate of access to a printer, a gauge is created.
4. Update state of behaviour: At the end of change detection, a set of gauges have either been created or identified. In this step the change event is used to update the values measured by a gauge. The state of behaviour is
CHAPTER 3. SELF-ADAPTIVE AUTHORISATION FRAMEWORK 64
then said to be updated, given that gauges maintain properties of behaviour tied to relationships within the modelled state of access. Once a gauge becomes full (i.e., its trigger condition is met), a violation has occurred, initiating the analysis stage.
3.4.3
Analysis
The analysis stage defines three activities to analyse detected change for non- conventional states (i.e., where malicious behaviour is ongoing), and identify pos- sible solutions to respond to such states. Figure 3.7 describes the flow of activities within the analysis stage, including the analysis of behaviour, analysis of solutions, and solution verification.
Figure 3.6: Analysis stage (normal and exceptional flow)
Behaviour Analysis
Behaviour analysis seeks to analyse current and historic behaviour in order to first confirm the presence of ongoing malicious behaviour as a violation within the behaviour model, and second, to determine the impact of malicious behaviour.
This is a necessary task as a single violation by a subject may not warrant an adaptation on its own. Moreover, each violation may exhibit various consequences to the organisation, given the current state of the system. As such, it is necessary to calculate the subject impact prior to analysing potential solutions.
Calculating a subject’s impact is similar to Baracaldo and Joshi’s approach in calculating subject trust based on historical behaviour [9]. However, for SAAF it is not a matter of calculating a subject’s level of trust, but a level of impact as a consequence of a malicious subject’s actions. In turn, the level of impact will become a factor in escalating appropriate and concrete solutions (with greater
consequence) to mitigate a subject’s activity. In calculating such an impact, it is important to consider multiple dimensions of behaviour (exemplified in Table 3.4) associated with identified (malicious) subjects.
Behaviour Dimension Description
Cost of identified behaviour Artificial cost assigned to types of violations Historical behaviour Past violations caused by the subject
Rate of detections Frequency and rapidness in identified behaviour Collaborators Subjects identified in performing similar
acts of malicious behaviour
Countered adaptation Whether the identified behaviour is repetition of prior violations, previously thought to be resolved (i.e., reinstated access rights) Table 3.4: Example criteria of behaviour
For example, a level of impact against the organisation, as dictated by a par- ticular subject’s behaviour, can be calculated in terms of the sum of all costs of the subject’s identified violations, multiplied by the total number of violations the subject has caused (to escalate response to persistent attacks). This can be improved by associating a level of risk to organisational resources [9], whereby the calculation of impact considers the scope of access a subject has, and criticality of accessible resources.
Solution Analysis
Solution analysis aims to identify a preliminary set of solutions capable of miti- gating a subject’s malicious behaviour. It relies on a hierarchy of solutions (Fig- ure 3.7) that can be enacted against the state of access, where many solutions can mitigate the behaviour identified. For example, a solution S2 may seek to remove a specific privilege from a subject (subject adaptation), or a solution S4 may remove a permission assignment to a resource within an access control policy (policy adaptation).
Essentially, each solution defines a strategy to constrain / restrict an access control model, given the presence of malicious behaviour. As such, each solution is tailorable, where parameters of the solutions are populated with specific artefacts of the detected malicious behaviour (e.g., the permission abused, the source sub- ject, the privilege used, etc.). Each solution exists within a layer of the hierarchy, categorised by no adaptation (do nothing), notification (warn a subject of their
CHAPTER 3. SELF-ADAPTIVE AUTHORISATION FRAMEWORK 66
Figure 3.7: Example solution hierarchy in mitigating malicious behaviour
behaviour), subject adaptation (impacts only the subject in question), and policy adaptation (impacts many subjects in a single adaptation). These layers are con- sidered to exhibit increasing impact to the system, where a number of alternative solutions may exist within each layer.
The use of solutions is akin to a strategy based approach to adaptation, as demonstrated by Rainbow’s use of a strategy definition language [36]. A concern with this approach is that an organisation may have to configure an exhaustive set of solutions in order to handle malicious behaviour. However, given an access control model there is a minimal and finite scope of actions that can be enacted (e.g., remove role from permission, remove resource from policy).
Considering a subject’s calculated impact weighting (identified in behaviour analysis), solution analysis identifies and tailors a subset of solutions that reflect the behaviour. This is necessary as not all malicious behaviour will clearly warrant