Project topics and materials
Get Complete Project Material File(s) Now! »
A Posteriori Access Control
The a posteriori access control can be classified as a deterrent and detective access control at the same time [195]. It is deterrent because it picks up where prevention leaves off. It allows access without imposing prevention constraints, which may lead to possible or successful attempts of violation. Moreover, the a posteriori access control deploys a monitoring mechanism to detect illegitimate accesses; hence, it is detective since the inspections are applied after-the-fact rather than in real-time.
In order to not block users in particular cases (e.g., emergency) [157], and to allow them to access the resource they need, a « break-glass » mode is adopted which leaves the access relatively « open ». Thus, the user is allowed to override the access restriction voluntarily, with or without the intervention of the administrator. Nevertheless, these accesses are traced and audited afterward. Although in legal terms the « harm is constituted », these accesses are made with full knowledge of the user of the potential consequences. He has been warned previously and yet, still performed these accesses without a delegation. Moreover, if the user could not prove the legitimacy of his actions after being questioned, he is held responsible and should be sanctioned by enforcing the fact that he was warned.
In contrast, decisions are taken by consulting the security policy that usually defines the access requests that must be authorized. On the other hand, log files record « What happened? When did it happen? And by whom » in the system. Therefore, it is referenced for diagnostic, audit trail, and investigative purposes in case of malicious activities, system attacks, or security breaches [152]. It can also be used for accounting purposes as it is obviously a trusted source that offers accurate data when considering that all accesses are logged. Therefore, logs constitute the basis on which the a posteriori access control lies to proceed in the investigations and provide proofs, and the security policy takes the role of the judge as it defines the rules that permit accesses. We can thus designate the a posteriori access control as an alliance between the logs and the security policy. After what has been discussed, the a posteriori access control was defined in the literature as composed of three stages: log processing, log analysis, and accountability [38, 48, 10]. The first step is meant to extract relevant information from logs. This latter is then analyzed in the second step to determine whether there has been a violation or not. Thus, the investigator can obtain evidence demonstrating that the user did not violate the security policy and that the problem was caused by external malice or a system error, or that there was effectively a violation. When abuse of privilege is assumed, the circumstances under which the user performed such action are studied to see if the access was harmful. Finally, the last step is about assigning responsibility by applying sanctions and remedies once the violation decision is made. This coupling between logging and auditing attends to assimilate the a posteriori access control to intrusion detection. Although these two resemble, they are still not the same. So what is the difference?
Difference between the A Posteriori Access Control and Intrusion Detection
As the volume of logged activity increases quickly, automated tools are being developed and used to reduce human tasks and help in carrying out auditing. One class of these tools is known as Intrusion Detection systems [58], which can be classified as passive or active. Passive systems [124] analyze the audit data offline and bring possible intrusions or violations to the attention of the auditor who then takes appropriate actions, while active systems [96] analyze audit data in real-time. In addition to alerting the auditor of the violations, these systems may take immediate protective response on the system. However, when the detection is passive, the distinction between the a posteriori access control and intrusion detection can be confusing as in both cases the goal is to detect violations.
Intrusion detection systems can be based on different approaches such as Threshold-Based approach [161], Anomaly-Based approach [112], Rule-Based approach [97], etc. Each approach is used to detect a specific type of violation. For instance, threshold-based systems define abnormal use concerning pre-specified acceptable thresholds (e.g., number of login attempts), while anomaly-based systems define abnormal use as a use that is significantly different from what normally observed (e.g., statistical measures). As for the Rule-based approach, it describes what is suspicious based on known past intrusions. It is generally enforced by the encoded knowledge of security experts of properties characterizing past intrusion events.
Log Processing
To have a correct log analysis, pertinent information should be extracted from log files. One problem to be addressed when analyzing logs, is the multiple log file formats that are due to the variety of log sources. These logs keep traces of all the established events in the information system, and these events differ from one logging source to another. Moreover, sometimes a log format may differ between the versions of the same source. For instance, the format and content of an application log are usually determined by the developer of the software program.
The key point in log analysis is that it needs to interpret messages within the context of an application or system, and map varying terminologies from log sources [3]. It turns them then into a uniform terminology to produce clear reports and statistics.
While it is acceptable to keep the log formats as « they are » in some cases, the a posteriori access control requires having log information in terms of the security policy to facilitate the violation detection, as mentioned earlier. Therefore, one might think that to be able to converge log formats and the security policy, it is required to transform these various formats into some common format. This process of unifying the different logs is called « log normalization ». Several efforts have been made to standardize log formats and make normalization obsolete [193, 46, 98]. Unfortunately, these efforts added variations to the format instead of reducing it, allowing event normalization on very different levels of detail. Therefore, the necessity of dealing with the differences of formats persisted, and further processing to obtain relevant information is still needed. This was the core motivation behind log normalization. In this respect, we review in the following some common log normalization methods that can be observed on the market and the research community.
Popular Log Normalization Methods
Regular Expressions The use of regular expressions (regex) is one of the classical approaches of log normalization. It is based on extracting data from log sources, by applying several regexes until a match is found, that is then transformed to the normalized output data [74]. In practice, regexes’ runtime requirements make them unsuitable for large classes of applications, especially in enterprise environments with a large log volume. To solve this problem, two different approaches were proposed: the traditional one is to hardcode parsers for each log format that is very important or requested by a user, and the alternative is to use advanced data structures suitable for fast parsing. However, their processing remains intensive and wasteful in terms of memory.
Policy Representations
As it has been shown in Section 2.1.1, the security policy can be formally represented according to different access control models, as well as their extensions and variants [25, 129, 139, 114, 1]. This formalization allows the proof of properties on the security provided by the access control system being designed. However, given the complexity and the scope in which the definition of the security policies is involved, it is essential to have a framework to reason about these policies. It is fundamental to unify the interpretation of access policies throughout the organization to make the whole system simpler and less error-prone. This is particularly important in the a posteriori access control where users’ rights may need to change in order to cope with specific contexts such as emergencies.
A lot of researchers have spent a few decades focusing on the representation of policies and policy rules. For instance, the eXtensible Access Control Markup Language (XACML) [81] and the Security Assertion Markup Language (SAML) [88] are XML based frameworks that enforce access control based on attributes. XACML was defined by OASIS, and it includes languages for expressing authorization rules and for access decisions. It has been known as a key standard that implements ABAC since its language specifies access control requirements using rules, policies, and policy sets, expressed in terms of subject (user), resource, action (operation), and environmental attributes and a set of algorithms for combining policies and rules. Therefore, attributes are a very important part in XACML and are evaluated by the rules in order to determine whether some restriction is applicable or not. Moreover, XACML proposes an authorization system that consists of five conceptual units: the Policy Enforcement Point (PEP), the Policy Decision Point (PDP), the Policy Administration Point (PAP), the Policy Information Point (PIP), and the Context Handler (CH). PEP performs access control by requesting an access decision to PDP, which uses the policies made available to it by PAP and the additional attributes sent by PIP to render its decision. The PEP communicates with the PDP and PIP through the CH that is an adapter between the XACML components and the protected application. As for the rules, they are integral to the functioning of XACML and form the core element in the hierarchy to make access decisions. A rule has target information, an effect, and a condition. The target is formed of a set of conditions that must be fulfilled to apply a policy or a rule on a given request. The rule’s effect is to deny or permit access. The condition is optional, and its role is to refine the applicability of the target. Finally, rules must be part of a policy and can be evaluated separately.
Table of contents :
Abstract
Résumé
Acknowledgments
List of Figures
List of Tables
1 Introduction
1.1 Context
1.2 Problem Statement
1.3 Contributions
1.4 Thesis Outline
2 State of The Art
2.1 A Priori vs A Posteriori Access Control
2.1.1 A Priori Access Control
2.1.2 A Posteriori Access Control
2.2 A Posteriori Access Control Steps
2.2.1 Log Processing
2.2.2 Log Analysis
2.2.3 Accountability
2.3 Policy Representations
2.4 SemanticWeb Technologies
2.4.1 RDF(S) and OWL
2.4.2 SPARQL
2.4.3 SWRL and SQWRL
2.5 Conclusion
3 Extracting Log Information Using Semantic Mediation
3.1 Introduction
3.2 What is a Semantic Mediator?
3.3 Semantic Mediation For Access Control
3.4 Semantic Mediation in the a Posteriori Access Control
3.4.1 Semantic Mediator Setup
3.4.2 Query Rewriting Process
3.4.3 Policy Reconciliation
3.5 Example Scenarios
3.5.1 Scenarios
3.5.2 Synthetic Logs Generation
3.5.3 Mediator Implementation
3.5.4 Query Rewriting Applied in the Scenarios
3.6 Discussion
3.7 Conclusion
4 A Posteriori Violation Detection with a Static Policy
4.1 Introduction
4.2 Materials
4.2.1 Multi-Agent System Definition
4.2.2 Motivation of Using a Multi-Agent System
4.2.3 Criticality of Policy Temporal Compliance
4.2.4 Event Calculus
4.3 Modelling the Security Policy with ABAC and OWL
4.4 Multi-Agent Based Policy Temporal Compliance Framework
4.4.1 Multi-Agent System Architecture
4.4.2 Multi-Agent System Functioning
4.5 Use Case
4.6 Implementation And Evaluation
4.6.1 Implementation
4.6.2 Evaluation
4.7 Related Work
4.8 Conclusion
5 A Posteriori Violation Detection with an Evolutive Policy
5.1 Introduction
5.2 Motivation of Considering Policy Evolution
5.3 Administrative Models for ABAC
5.3.1 GURA
5.3.2 ADABAC
5.3.3 AMABAC
5.4 Evolutive Policy Compliance
5.4.1 Getting Access Time Valid Rules
5.4.2 Monitoring Administrative Actions
5.4.3 Detecting violations
5.5 Use Case
5.6 Implementation
5.7 Experimentation
5.8 Conclusion
6 Accountability in the A Posteriori Access Control
6.1 Introduction
6.2 Accountability: a Requirement and a Mechanism
6.2.1 Accountability as requirement
6.2.2 Accountability as a mechanism
6.3 Conclusion and Future Work
7 Conclusions and Perspectives
7.1 Perspectives
7.1.1 Log Analysis with Incomplete Information
7.1.2 Policy Conflict Resolution
7.1.3 Combining a Priori and a Posteriori Access Control
7.1.4 Contextualizing the Exception Policy
7.1.5 Considering Usage Control Requirements and Obligations
7.2 Raising Awareness Among Organizations
7.2.1 Context
7.2.2 The Organization’s Business
7.2.3 Use Cases
7.2.4 Discussion and Perspectives
A French Summary: Analyse a Posteriori des Logs et Détection des Violations des Règles de Sécurité
A.1 Introduction
A.2 Extraction d’Informations des Logs à l’aide de la Médiation Sémantique
A.3 Détection a Posteriori des Violations
A.3.1 Architecture Multi-Agents
A.3.2 Le Cas d’une Politique Statique
A.3.3 Le Cas d’une Politique Evolutive
A.4 L’Imputabilité dans le Contrôle d’Accès a Posteriori
A.4.1 L’Imputabilité en tant qu’Exigence
A.4.2 L’Imputabilité en tant que Mécanisme
A.5 Conclusion
List of Publications
Bibliography
Bibliography
