N V Narendra Kumar

R K Shyamasundar
email: shyamasundar@gmail.com

FlowConSEAL: Automatic Flow Consistency Analysis of SEAndroid and SELinux Policies

SELinux/SEAndroid policies used in practice contain tens of thousands of access rules making it hard to analyse them. In this paper, we present an algorithm for reasoning about the consistency of a given policy by analysing the information flows implied by it. For this purpose, we model SELinux policy rules using the Readers-Writers Flow Model (RWFM). Using this model, our method identifies all possible indirect flows due to a given policy that could lead to inconsistency. One of the main features of the method is that it not only identifies inconsistencies in the policy but also traces the rules that lead to inconsistency. To distinguish between benign and vulnerable indirect flows, we further categorise the indirect rules that directly contradict neverallow rules in the policy and hence have a high potential for information leak. We further rank the rules and domains based on the number of policy violations they cause. We have also implemented a tool FlowConSEAL based on the above method and have applied it on various SELinux/SEAndroid policies for providing a succinct feedback to the user.

We thank Asokan N, Elena R and Filippo B for their invaluable insights on SE-Android policy analysis and for sharing SEAndroid policies in early stages of the work.

Introduction

In this digital era, protecting data from intentional and unintentional misuse has become a major concern. Security of Operating System (OS) plays a vital role in data protection and privacy. With Linux kernel forming the core of a wide range of computing devices ranging from mobile phones to supercomputers, its security is of paramount importance. Over the years, several efforts have been made to enhance the security of Linux, SELinux [START_REF] Loscocco | Integrating flexible support for security policies into the linux operating system[END_REF] being a prominent example.

Traditionally, Linux supports Discretionary Access Controls (DAC) where access decisions are taken based on the user identity and the permission bits of the object. It is well known that DAC alone is not powerful enough to effectively protect the system because of its inherent weaknesses.

SELinux introduced Mandatory Access Controls (MAC) to overcome DAC's drawbacks and enhance security through fine-grained access control. It does so by labeling every entity in the system such as files, sockets, processes etc. and specifying a policy to control accesses based on the labels of subjects and objects involved in actions. In addition to providing better protection against unauthorized accesses, SELinux also helps in confining the attack in case of a breach. From Android 4.3 onward SELinux is also being used in Android (referred to as SEAndroid) to provide better application sandboxing and finegrained access control 3 .

In SELinux systems, a well-written policy is the key to protecting the system resources against security threats. However, as these policies get larger and complex, assuring the consistency of all the rules and information flows allowed by them becomes difficult. Currently, the tools [START_REF] Eaman | Review of existing analysis tools for selinux security policies: Challenges and a proposed solution[END_REF] used for writing and analysing these policies are not sufficient for detecting information leaks in them. In this paper, we describe a method to analyse information flows implied by a given SELinux policy, and verify their consistency with respect to the accesses in the given policy. The main contributions of the paper are:

1 Automatically analysing consistency of SELinux policies via implied information flows (IF), enabling the policy writers in preventing IF leaks. 2 Identifying and producing evidence for indirect IFs which violate neverallow rules specified by the policy. 3 Identifying security critical rules and domains (group of processes). 4 Implementation of the tool FlowConSEAL to demonstrate the effectiveness of our approach by applying it on various real-life policies.

In the rest of the paper, background is provided in section 2, followed by the need for IF analysis of SELinux policies in section 3. Our approach and experimental analysis are given in section 4 and section 5 respectively. Discussion on related work is presented in section 6. Conclusions are presented in section 7.

Background

SELinux

SELinux is a MAC system implemented using Linux Security Module (LSM) framework [START_REF] Wright | Linux security modules: General security support for the linux kernel[END_REF]. LSM modules work on top of Linux's built-in DAC and enhance its security. In an SELinux system, every subject (active entities like processes) and object (passive entities like files,sockets etc.) is assigned a label which consists of four fields corresponding to SELinux user, role, type and an optional level and it is denoted as user:role:type[: level]. The third field type represents the logical grouping to which the entity belongs (type of a subject is commonly referred as a domain). Although SELinux supports policies based on both type field (Type Enforcement policy) and level field (MLS, MCS policies), Type Enforcement (TE) policies are the most commonly used. The analysis presented in this paper is focused on SELinux TE policies. TE policy supports several types of rules. In this paper we are concerned with two predominant rulesallow and neverallow. Every time a subject attempts to perform an action on an object, a request is sent to the SELinux module. Access decision is taken based on the subject and object's label. By default, every access is denied. allow rules are used to explicitly grant access permission. Unlike allow, the neverallow rules are used at policy compilation time to ensure that there are no corresponding allow rules. The general syntax of these rules is rule source target:class permissions where rule represents the rule name, source represents the type of the subject requesting the access, target represents the type of the object which is being accessed, class represents the category of the object (such as file, pipe etc.) and permissions denote actions associated with the object class.

Readers-Writers Flow Model (RWFM)

In a MAC system, we can ensure information flow security by employing a suitable formal information flow model and ensuring that the MAC policy conforms to the model. In this paper, we use RWFM [START_REF] Kumar | A complete generative label model for lattice-based access control models[END_REF] model to capture the information flows in a given SELinux policy. RWFM is a powerful lattice-based information flow model based on Dennings model [START_REF] Denning | A lattice model of secure information flow[END_REF]. It can be used to provide both confidentiality and integrity. It supports dynamic labeling and declassification. Also, it can capture several well-known models like BLP [START_REF] Bell | Secure computer systems: Mathematical foundations[END_REF], Biba [START_REF] Biba | Integrity considerations for secure computer systems[END_REF] etc. Its labeling and access rules are described below.

Labeling: Let S and O be the set of subjects and objects in the system respectively. An RWFM label, also called as RW Class is defined as a triplet (s, R, W ). Where s ∈ S denotes the owner of the information in the class. R ∈ 2 S denotes the set of subjects which can read the objects of the class. W ∈ 2 S denotes the set of subjects which can write or which have influenced the class.

Access Rules: Let owner(x), R(x) and W (x) be the functions mapping S ∪ O to the owner, readers and writers components of the label respectively. Under the above labeling model, access rules of RWFM are specified as follows:

-A subject s is allowed to read an object o if owner(s) ∈ R(o) and R(o) ⊇ R(s) and W (o) ⊆ W (s) -A subject s is allowed to write an object o if owner(s) ∈ W (o) and R(s) ⊇ R(o) and W (s) ⊆ W (o)

Consistency Problem of SELinux Policies

In this section, we explain the indirect and contradictory rules and the associated security concern. Consider the following set of rules R:

1 neverallow mozilla t security t:file write; 2 allow mozilla t user home t:file write; 3 allow sysadm sudo t user home t:file read;

4 allow sysadm sudo t security t:file write;

The second rule in R permits mozilla t to write to user home t:file. The third rule allows sysadm sudo t to read from user home t:file, and the last rule allows sysadm sudo t to write to security t:file. When actions permitted by the last three rules are performed in that sequence, mozilla t can write some data into user home t file, and sysadm sudo t can then read this content and write it into a security t file. As a result, mozilla t can indirectly write to a security t file which the policy writer intended to prevent using Rule 1.

SELinux enforcement of the policy fails to prevent such accesses because it only controls individual accesses, and does not take the information flows caused by these actions into account. Whenever a subject performs an action on an object, the action results in an information flow between them. The direction of such flow depends on the nature of the action. In case of a read, information flows from the object to the subject, whereas in case of a write, flow is from the subject to the object. When multiple actions are performed, the resulting information flow lead to unintended accesses.

The main objective of this paper is to identify all potential indirect accesses caused by chaining legal accesses of a policy. However, not all of them necessarily lead to a security breach. We focus only on the set of indirect accesses which have corresponding neverallow rules in the policy similar to the the indirect access resulted due to rules 2-4 in R which contradicts rule 1. Such rules allow the accesses explicitly denied by the policy writers and hence are obviously a security concern and need to be further analysed. We call such rules as contradictory rules and study their impact on security. Our analysis provides useful feedback to policy writers which can be used to better understand the impact of their rules and develop flow secure policies.

SELinux Policy Analysis: Our Approach

Our approach has five main steps that are described in detail below:

Step 1: Canonicalization of rules In practice, a rule may contain sets of domains, types, object classes and permissions. In such cases, a single rule corresponds to multiple accesses, one for each (domain, type, class, permission) combination in the rule. To understand the effect of each individual access on the information flow, it is necessary to consider each such combination as a separate rule. So we canonicalize rules such that each resulting rule corresponds to a single access. It will help us extract precise information such as the rules responsible for an indirect flow, number of indirect rules caused by each domain and so on. Further, to clearly differentiate between objects of same type but different object classes, we use both type and class to uniquely identify such combinations. In the rest of the paper we use the term "object type" to refer to this combination unless specified otherwise. We define a function canonicalize() which takes a policy as input and returns the set of corresponding canonicalized rules.

Consider the following simplified policy P consisting of set of domains D = {d1, d2}, set of object types T = {t1, t2}, and permissions r and w which correspond to read and write operations respectively. Policy Rules in P 1 allow d1 t1 {r, w} 2 allow d2 t2 {r, w} 3 allow d1 t2 {w} Canonicalized Rules of P 1 allow d1 t1 r 2 allow d1 t1 w 3 allow d2 t2 r 4 allow d2 t2 w 5 allow d1 t2 w

Step 2: Extraction of labels of object types In our analysis, we consider information flows between domains and object types in terms of RWFM rules. For this, we first need to assign RWFM labels to the domains and object types. Since we are working at the granularity of domain/object types, we ignore the owner field of the RWFM label. Thus the labels are of the form (R, W), where R stands for readers and W for writers/influencers.

For extracting readers and writers of any object type, we need to find the set of domains which have read and write permissions for that object type respectively. We do this by iterating over all the allow rules in the policy. For each allow rule of the form allow d t r, we add d to R(t) and for allow d t w, we add d to W (t). This procedure is described in Algorithm 1.

At present, we focus only on read and write permissions in the policy since they are the high bandwidth channels. Other permissions can be mapped into either read or write depending on whether they cause outward or inward information flow. Our implementation is generic and can use such mappings to consider any permission of interest.

On applying Step 2 on the set of rules obtained from Step 1, t1's label will be ({d1}, {d1}) and t2's label will be ({d2}, {d1, d2}).

Algorithm 1: LabelObjectTypes Data: Canonicalized policy rules Result: Labels (Lot) of all the object types in the policy

foreach t ∈ T do R(t) = W (t) = {} end foreach rule "allow d t perm" do if perm = r then R(t) = R(t) ∪ d else if perm = w then W (t) = W (t) ∪ d end end
Algorithm 2: LabelDomains Data: Canonicalized policy rules and Lot Result: Labels (L d )of all the domains in the policy

foreach d ∈ D do R(d) = W(d) = D end foreach t ∈ T do foreach d ∈ R(t) do R(d) = R(d) ∩ R(t) end foreach d ∈ W(t) do W(d) = W(d) ∩ W(t) end end
Step 3: Extraction of labels of domains Once the labels of object types are obtained, we use them to derive labels for domains in the policy. Algorithm 2 describes this procedure. Here we start with the universal set of domains for reader and writer sets. For each object type t which contains d in its reader set, we update the R(d) as the intersection of R(t) and R(d). Since read operation causes information flow from object to subject, as per RWFM rule, the label of the domain (subject) should dominate the label of the type (object). For this, R(d) ⊆ R(t) should hold. Hence we update R(d) as R(d) ∩ R(t). Similarly, when a domain d is in writer set of an object type t, we update W (d) as W (d) ∩ W (t). On applying this algorithm on the sample policy, label of d1 will be ({d1}, {d1}) and label of d2 will be ({d2}{d1, d2}).

Step 4: Identification of indirect accesses Once we have the labels for all the object types and domains in the policy, we apply the following RWFM access checks on each allow rule in the policy:

d ∈ R(t) ⇒ (R(t) ⊇ R(d)) ∧ (W (t) ⊆ W (d))
(1)

d ∈ W (t) ⇒ (R(d) ⊇ R(t)) ∧ (W (d) ⊆ W (t)) (2)
These checks help us verify whether the information flows caused due to the accesses respect the permissions specified in the policy. Algorithm 3 describes the procedure used for the checks. With the label derivation methods described in Step 2 and 3, we can say that the conditions R(t) ⊇ R(d) in (1) and W (d) ⊆ W (t) in (2) will always be satisfied. Hence, we check only the remaining conditions. Failure to satisfy these conditions imply the presence of indirect flows. i.e if the condition W (t) ⊆ W (d) fails in [START_REF] Loscocco | Integrating flexible support for security policies into the linux operating system[END_REF], then all the domains in (W (t) -W (d)) can indirectly write to all the types that d can write. Similarly, if (R(d) ⊇ R(t) in the above condition fails, that means that all the domains in (R(t) -R(d)) can read everything that d can read. We construct allow rules corresponding to these indirect accesses and store them in IndirectRulesSet. Applying these checks to our sample policy will show that the check fails at rule 5. Here R(d1) ⊇ R(t2). Hence d2 can read t1 even though there is no rule granting this permission.

The steps described above can detect only one level of indirection i.e indirect flows via a single pair of subject and object. However, there can be multiple levels of indirect flows. For example, if we add rules allow d3 t3 {r, w} and allow d2 t3 {w} to our example policy, it would lead to a two level indirection. To find multi-level indirect flows, we first need to add the first level indirect rules identified i.e rules in IndirectRuleSet to our policy rules and repeat Step 2 to

Step 4. We do this until there are no more indirect flows caused by the rule set. Algorithm 4 describes this procedure.

L d = LabelDomains(RuleSet, Lot) IndirectRuleSet = AccessRuleChecks(RuleSet, Lot, L d ) if IndirectRuleSet is ∅ then consistent = True else RuleSet = RuleSet ∪ IndirectRuleSet end end
For each rule in the RuleSet, along with the rule components, we store the iteration number in which the rule was generated (Iteration), set of rules causing the rule (Cause), and whether the rule is contradiction or not (Contradiction).

Step 5: Extraction of crucial information In this step we extract the following information by using the data collected in the previous step: Analysing individual rules: Here we try to understand the impact of each policy rule on flow security. We count the number of contradictions caused by each rule in the policy. Higher the number for a rule, larger is its potential to cause harm. Analysing Domains: Here we study each domain in the policy and count the contradictions caused by them. The domains are then ranked based on this count. This information helps the system developers to understand the priorities that should be given while developing the processes in those domains. Analysing indirect accesses: As seen in the earlier sections, a one-level indirection between a subject-object pair is caused by chaining of 3 accesses. For each such indirection, we store the rule corresponding to the second access as the causing rule. This helps in generating the complete sequence of rules causing a particular indirection. We can use this procedure recursively to determine a complete sequence of original policy rules causing any multi-level indirection. Remarks: Given a general access matrix model [START_REF] Harrison | Protection in operating systems[END_REF] along with the assertion that a certain subject s can acquire a right 'x' on object o, it is of interest4 to generate a command/rule sequence that could lead to the new state from the original state of the access matrix. From the given access rules, FlowConSEAL generates the new rights acquired by processes along with the sequence of rules required for realizing that right.

Experimental Analysis and Illustration

We have implemented FlowConSEAL using Python 2.7. Our implementation and experiments are performed on Ubuntu 16.10 running on a virtual machine configured with 64GB RAM. We demonstrate the effectiveness of FlowConSEAL on two policies, the Reference policy (refpolicy-2.20170805) 5 which is the base policy used by all the Linux distributions for developing their SELinux policies and the SEAndroid policy provided as part of the Android Open Source Project (AOSP) tree in Android 7 6 .

Analysis of Policies by FlowConSEAL

Here we provide a brief 7 analysis of the above two polices obtained through FlowConSEAL as depicted in Table 1. Number of types, object classes and permissions: SELinux doesn't have any predefined types whereas object classes and associated permissions are predefined. Policy writers define types based on the resources and services they want to confine and the overall security goals. Larger number of types help specifying fine-grained rules. But with increase in types, associated rules also increase drastically and the policy management becomes difficult. As general purpose Linux systems provide comparatively large number services and resources, naturally, SELinux Reference policy contains larger number of types, object classes and permissions than Android's AOSP policy. Number of canonicalized allow and neverallow rules: Our tool parses the policy only once and stores the canonicalized allow and neverallow rules separately. All further processing is done on these rules. Hence performance of the tool depends on the number of allow and neverallow rules. single level of indirection. However, note that the Reference policy contains two levels of indirection.

Number of indirect and contradictory rules:

The tool identifies all possible indirect information flows. As we can see in the table for both the policies, these rules are in hundreds of thousands in number. In order to avoid false positives and reduce these rules to a manageable subset, we consider only the contradictory rules. Larger the number of contradictions, weaker is the security of the policy. From the table, the Reference policy has lower number of contradictions even though it has large number indirect flows.

Percentage of indirect allows that are contradictions: This factor indicates the extent to which indirect rules can be exploited to cause policy violations. Theoretically, for perfect security, this number should be zero. The Reference policy with only 0.665% of its indirect allows causing contradiction, prove to be much more stronger against policy violations using indirect allows.

Percentage of neverallows that are contradictions: This factor indicates the extent of potential policy violations. Larger the percentage, weaker is the security. From the table, we can notice that in case of the AOSP policy only 0.486% of neverallows can be violated using the indirect rules. Hence comparatively, this is a well written policy with respect to information flow.

Execution time: From the table, we can see that the execution time especially that for the Reference policy is considerably high. However, considering the large size of the policy and the size of the meta data being generated (10 GB in case of the Reference policy), and the fact that this analysis is performed only once, we can say the tool is quite useful.

Number of contradictory rules generated by each rule: This is useful for understanding the impact of each rule on the flow security. Tables 2 and3 show the top 3 allow rules along with the number contradictions that they cause (Ctd r Count) in the Reference and AOSP policy respectively. Domain Ranking: Here the number of contradictions caused by each domain is counted. Using this, we can get the domains which have high potential to be exploited to gain an unauthorized access. Therefore subjects in these domains need to be designed and implemented carefully. From our experiments, we noticed that high ranking domains are mostly system processes and daemons which are trusted by the system. However, considering the large number of policy violations that we have observed, it is important that these contradictions are carefully analysed, and the processes running in these domains are thoroughly verified to be safe against any attacks leading to those contradictions.

Algorithm 3 :

 3 AccessRuleChecks Data: Canonicalized policy rules and labels of object types (Lot) and labels of all domains (L d ) Result: Set of rules corresponding to indirect flow IndirectRulesSet = {} foreach rule "allow d t perm" do if perm = r AND W (t) ⊆ W (d) then foreach d1 ∈ (W (t) -W (d)) do foreach t1 which has d ∈ W (t1) do IndirectRulesSet = IndirectRulesSet ∪ {allow d1 t1 w } end end else if perm = w AND R(d) ⊇ R(t) then foreach d1 ∈ (R(t) -R(d)) do foreach t1which has d ∈ R(t1) do IndirectRulesSet = IndirectRulesSet ∪ {allow d1 t1 r } end end end end

Algorithm 4 :

 4 SELinuxPolicyConsistencyCheckData: SELinux policy P Result: Set of all possible indirect allows consistent = False RuleSet = Canonicalize(P) while not consistent do Lot = LabelObjectTypes(RuleSet)

Table 1 .

 1 Experimental analysisNumber of iterations: Number of iterations required to generate all possible indirect rules indicates the levels of indirect flows present in the policy. AOSP policy conforms to RWFM check in its second iteration i.e., it contains only

	Reference Policy AOSP Policy

Table 2 .

 2 Ctdr count (Reference Policy)

	Allow Rule in the RuleSet	Ctdr Count
	systemd tmpfiles t device t:lnk file write	468
	udev t device t:lnk file write	468
	getty t devlog t:sock file read	146

As SELinux and SEAndroid policies have the same syntax, our approach is applicable to both families.

Note that it is a specific problem instance rather than the 'safety problem'

Ctdr Count init cgroup:dir read 5166 init urandom device:chr file read 5166 system server cgroup:dir read 927 Table 3. Ctdr count (AOSP Policy) [START_REF] Bell | Secure computer systems: Mathematical foundations[END_REF]

Related Work

Preventing unauthorized information flows (IF) is crucial for ensuring security. Uzun et al. [START_REF] Uzun | Preventing unauthorized data flows[END_REF] propose a method for preventing unauthorized IF in access matrix model based DAC systems. They identify one-step transitive flows and eliminate them by revoking necessary permissions; FlowConSEAL not only identifies multi-level indirections, but also provides a sequence of rules that lead to each indirect flow.

Over the years, several tools have been developed to understand and analyse SELinux policies [START_REF] Eaman | Review of existing analysis tools for selinux security policies: Challenges and a proposed solution[END_REF]. SETools [START_REF]TresysTechnology: Setools: Policy analysis tools for selinux[END_REF] is one of the commonly used collection of tools. It provides several tools for searching rules, comparison of policies and, IF analysis which is limited to listing all the flows between domains specified by the user. Unlike FlowConSEAL, it does not support verification of flows against a security model or checking if the indirect flows are contradicting any neverallow rules. PAL [START_REF] Sarna-Starosta | Policy analysis for security-enhanced linux[END_REF] is a logic programming tool that supports SELinux policies by first translating them into a logic program. The user needs to construct appropriate queries to analyse the policy. Thus, the onus is on the user to come up with properties as queries which is not an easy task. In comparison, FlowCon-SEAL yields the possible indirect flows, contradictions etc., without any user intervention.

Gokyo [START_REF] Jaeger | Analyzing integrity protection in the selinux example policy[END_REF] analyses integrity of the "Example policy" using manually specified high integrity types as Trusted Computing Base (TCB). The tool considers only one level indirection between TCB types and non-TCB types, and checks for conflicts between the integrity goal and the policy rules. Similarly, SCIA-Tool [START_REF] Zhai | SCIATool: a tool for analyzing selinux policies based on access control spaces, information flows and cpns[END_REF] also analyses integrity conflicts between TCB and non-TCB entities using colored Petri-nets.

Several visualization-based SELinux policy analysis tools [START_REF] Gove | V3SPA: A visual analysis, exploration, and diffing tool for selinux and seandroid security policies[END_REF][START_REF] Marouf | SEGrapher: Visualization-based SELinux Policy Analysis[END_REF][START_REF] Clemente | SPTrack: visual analysis of information flows within selinux policies and attack logs[END_REF] have been developed to help policy writers to better understand the policies. Gove [START_REF] Gove | V3SPA: A visual analysis, exploration, and diffing tool for selinux and seandroid security policies[END_REF] presents a tool for understanding and comparing SELinux/SEAndroid policies by creating graph representations. SPTrack [START_REF] Clemente | SPTrack: visual analysis of information flows within selinux policies and attack logs[END_REF] helps visualize SELinux policies as well as its attack logs to track IF. SEGrapher [START_REF] Marouf | SEGrapher: Visualization-based SELinux Policy Analysis[END_REF] generates cluster-based focus-graphs of policies based on clustering.

Several tools have been developed specifically for SEAndroid policy analysis. [START_REF] Reshetova | Characterizing SEAndroid policies in the wild[END_REF], analyses SEAndroid policies from Android 5.0 devices from a number of OEMs and identify patterns of common problems. SELint [START_REF] Reshetova | Selint: An seandroid policy analysis tool[END_REF] is an extensible tool built to help policy writers in writing secure SEAndroid policies. It's built-in plug-ins mainly focus on making a policy more compact and readable and identify potentially dangerous rules by assigning a risk score to each rule. The risk score of a rule is computed based on the risk level and trust level of the rule components whose values are policy-dependent and need to be manually configured by the policy writers. A semi-automated tool to identify potential SEAndroid policy misconfigurations is presented in [START_REF] Chen | Analysis of SEAndroid Policies: Combining MAC and DAC in Android[END_REF]. EASEAndroid [START_REF] Wang | EASEAndroid: automatic policy analysis and refinement for security enhanced android via large-scale semi-supervised learning[END_REF] analyses SEAndroid policies using large-scale semi-supervised learning.

To sum up, FlowConSEAL provides a succinct analysis of SELinux policies and enables the user to decide on benign and vulnerable indirect flows. One distinct characteristic of FlowConSEAL is that it works like a "pushbutton" tool unlike others that need user supplied abstraction of queries/properties.

Conclusions

In this paper, we have presented an efficient method and a tool FlowConSEAL to analyze information flows in SELinux/SEAndroid policies. Our method verifies the consistency of the policies in terms of indirect flows and helps in identifying potential vulnerabilities. Furthermore, we also rank the policy rules and domains based on their potential to misuse information. The tool enables the policy writers to understand the security loopholes in the policy and handle them appropriately to protect systems against flawed and malicious applications. The experimental results demonstrate the effectiveness of the method. One of the distinct advantage of using RWFM model is its capability to capture all the influencers succinctly.


Nawaf Alhebaishi

Lingyu Wang
email: wang@ciise.concordia.ca

Sushil Jajodia
email: jajodia@gmu.edu

Anoop Singhal
email: anoop.singhal@nist.gov

Modeling and Mitigating the Insider Threat of Remote Administrators in Clouds

As today's cloud providers strive to attract customers with better services and less downtime in a highly competitive market, they increasingly rely on remote administrators including those from third party providers for fulfilling regular maintenance tasks. In such a scenario, the privileges granted for remote administrators to complete their assigned tasks may allow an attacker with stolen credentials of an administrator, or a dishonest remote administrator, to pose severe insider threats to both the cloud tenants and provider. In this paper, we take the first step towards understanding and mitigating such a threat. Specifically, we model the maintenance task assignments and their corresponding security impact due to privilege escalation. We then mitigate such impact through optimizing the task assignments with respect to given constraints. The simulation results demonstrate the effectiveness of our solution in various situations.

Introduction

The widespread adoption of cloud leads to many unique challenges in terms of security and privacy [START_REF]Security guidance for critical areas of focus in cloud computing v 3[END_REF]. As the cloud service market becomes more and more competitive, cloud providers are striving to attract customers with better services and less downtime at a lower cost. The search for an advantage in cost and efficiency will inevitably lead cloud providers to follow a similar path as what has been taken by their tenants, i.e., outsourcing cloud maintenance tasks to remote administrators including those from specialized third party maintenance providers [START_REF] Bleikertz | Secure cloud maintenance: Protecting workloads against insider attacks[END_REF]. Such an approach may also lead to many benefits due to resource sharing, e.g., the access to specialized and experienced domain experts, the flexibility (e.g., less need for full-time onsite staff), and the lower cost (due to the fact such remote administrators are shared among many clients).

However, such benefits come at an apparent cost in terms of increased security threats. Specifically, the remote administrators must be provided with necessary privileges, which may involve direct accesses to the underlying cloud infrastructure, in order to complete their assigned maintenance tasks. Armed with such privileges, a dishonest remote administrator, or an attacker with the stolen credentials of an administrator, can pose severe insider threats to both the cloud tenants (e.g., causing a large scale leak of confidential user data) and the provider (e.g., disrupting the cloud services or abusing the cloud infrastructure for illegal activities) [START_REF] Claycomb | Insider threats to cloud computing: Directions for new research challenges[END_REF]. On the other hand, cloud providers are under the obligation to prevent such security or privacy breaches caused by insiders [START_REF]Top threats to cloud computing[END_REF], either as part of the service level agreements, or to ensure compliance with security standards (e.g., ISO 27017 [START_REF]Information technology-Security techniques-Code of practice for information security controls based on ISO/IEC 27002 for cloud services (DRAFT)[END_REF]). Therefore, there is a pressing need to better understand and mitigate such insider threats.

Dealing with the insider threat of remote administrators in clouds faces unique challenges. First, there is a lack of public access to the detailed information regarding cloud infrastructure configurations and typical maintenance tasks performed in clouds. Evidently, most existing works on insider attacks in clouds either stay at a high level or focus on individual nodes instead of the infrastructure [START_REF] Bleikertz | Secure cloud maintenance: Protecting workloads against insider attacks[END_REF][START_REF] Li | Mycloud: Supporting user-configured privacy protection in cloud computing[END_REF][START_REF] Sze | Hardening openstack cloud platforms against compute node compromises[END_REF] (a more detailed review of related work will be given in Section 6). Second, cloud infrastructures can be quite different from typical enterprise networks in terms of many aspects of security. For instance, multi-tenancy means there may co-exist different types of insiders with different privileges, such as administrators of a cloud tenant, those of the cloud provider, and third party remote administrators. Also, virtualization means a more complex attack surface consisting of not only physical nodes but also virtual or hypervisor layers. To the best of our knowledge, there is a lack of any concrete study in the literature on the insider attack of remote administrators in cloud data centers.

In this paper, we take the first step towards understanding and mitigating such insider threats. Specifically, we first model the maintenance tasks and their corresponding privileges. We then model the insider threats posed by remote administrators assigned to maintenance tasks by applying the existing k-zero day safety metric as follows; remote administrators possess elevated privileges due to the assigned maintenance tasks, and those privileges correspond to initially satisfied security conditions, which are normally only accessible by external attackers after exploiting certain vulnerabilities. Such model allows us to formulate the mitigation of the insider threats of remote administrators as an optimization problem and solve it using standard optimization techniques. We evaluate our approach through simulations and the results demonstrate the effectiveness of our solution under various situations. In summary, the main contribution of this paper is twofold:

-To the best of our knowledge, this is the first study on the insider threat of remote administrators in cloud infrastructures. As cloud providers leverage third parties for better efficiency and cost saving, our study demonstrates the need to also consider the security impact, and our model provides a way for quantitatively reasoning about the tradeoff between such security impact with other related factors. -By formulating the optimization problem of mitigating the insider threat of remote administrators through optimal task assignments, we provide a relatively effective solution, as evidenced by our simulation results, for achieving the optimal tradeoff between security and other constraints using standard optimization techniques.

The remainder of this paper is organized as follows. Section 2 presents a motivating example and discusses maintenance tasks and privileges. In Section 3, we present our models of task assignment and insider threat. Section 4 formulates the optimization problem and discusses several use cases. Section 5 gives simulation results. Section 6 discusses related work. Section 7 concludes the paper.

Preliminaries

This section gives a motivating example and discusses maintenance tasks and privileges.

Motivating Example

A key challenge to studying security threats in cloud data centers is the lack of public accesses to detailed information regarding hardware and software configurations deployed in real cloud data centers. Existing work mainly focus on either high level frameworks and guidelines for risk and impact assessment [START_REF]Cloud Computing Service Metrics Description[END_REF][START_REF] Saripalli | Quirc: A quantitative impact and risk assessment framework for cloud security[END_REF][START_REF] Luna | A security metrics framework for the cloud[END_REF], or specific vulnerabilities or threats in clouds [START_REF] Dahbur | A survey of risks, threats and vulnerabilities in cloud computing[END_REF][START_REF] Shaikh | Security threats in cloud computing[END_REF], with a clear gap between the two. To overcome such a limitation, we choose to devise our own fictitious, but realistic cloud data center designs, by piecing together publicly available information gathered from various cloud vendors and providers [START_REF] Alhebaishi | Threat modeling for cloud data center infrastructures[END_REF], as shown in Figure 1. To make our design more representative, we devise this configuration based on concepts and practices borrowed from major cloud vendors and providers. For example, we borrow the multi-layer concept and some hardware components, e.g., Carrier Routing System (CRS), Nexus (7000,5000,2000), Catalyst 6500, and MDS 9000, from the cloud data center design of Cisco [START_REF] Bakshi | Cisco cloud computing-data center strategy, architecture, and solutions[END_REF]. We synthesize various concepts of the VMware vSphere [START_REF] Hany | VMware VSphere In The Enterprise[END_REF] for main functionality of hardware components in our cloud infrastructure (e.g., authentication servers, DNS, and SAN). We also assume the cloud employs OpenStack as its operating system [START_REF]Openstack Operations Guide[END_REF]. The infrastructure provides accesses to both cloud users and remote administrators through the three layer design. Layer 1 connects the cloud to the internet and includes the authentication servers, DNS, and Neutron Server. Layer 2 includes the rack servers and compute nodes. Layer 3 includes the storage servers. OpenStack components run on the authentication servers, DNS server (a Neutron component provides address translation to machines running the requested services), and compute nodes (Nova to host and manage VMs, Neutron to connect VMs to the network, and Ceilometer to calculate the usage) to provide cloud services.

Such a cloud data center may require many maintenance tasks to be routinely performed to ensure the normal operation of the hardware and software components. Such maintenance tasks may be performed by both internal staff working onsite and remote administrators, including those from specialized third party providers. In our example, assume the cloud provider decides to rely on third party remote administrators for the regular maintenance of the five compute nodes (nodes #1-5 in Figure 1), the authentication servers (node #6), and the two controllers (nodes #7 and 8). Table 1, shows the maintenance tasks need to be performed on those nodes. For simplicity, we only consider three types of tasks here (more discussions about maintenance tasks will be given in next section).

Node Number (in Figure 1)

Maintenance Tasks Read log files Modify configuration files Install a new system

1 × × 2 × × 3 × × × 4 × × 5 × × 6 × × 7 × 8
× Table 1: An example of required maintenance tasks

In such a scenario, the cloud provider would naturally raise security concerns due to the fact that necessary privileges must be granted in order to allow the third party remote administrators to perform their assigned maintenance tasks. For instance, the task read log files needs certain read privilege to be granted, whereas modifying configuration files and installing a new system would demand much higher levels of privileges. Such privileges may allow a dishonest remote administrator, or attackers with stolen credentials of a remote administrator, to launch an insider attack and cause significant damage to the cloud provider and its tenants. Even though the cloud provider may (to some extent) trust the third party maintenance provider as an organization, it is in its best interest to understand and mitigate such threats from individual administrators. However, as demonstrated by this example, there are many challenges in modeling and mitigating such insider threats.

-First, as demonstrated in Table 1, there may exist complex relationships between maintenance tasks and corresponding privileges needed to fulfill such tasks, and also relationships between different privileges (e.g., a root privilege implies many other privileges). Those relationships will determine the extent of an insider threat. -Second, the insider threat will also depend on which nodes in the cloud infrastructure are involved in the assigned tasks, e.g., an insider with privileges on the authentication servers (node #6 in Figure 1) or on the compute nodes (nodes #1-5) may have very different security implications. -Third, the extent of the threat also depends on the configuration (e.g., the connectivity and firewalls), e.g., an insider having access to the controller node #8 would have a much better chance to compromise the storage servers than one with access to the other controller node #7). -Finally, while an obvious way to mitigate the insider threat is through assigning less tasks to each remote administrator such as to limit his/her privileges, our study will show that the effectiveness of such an approach depends on other factors and constraints, e.g., the amount of tasks to be assigned, the number of available remote administrators, constraints like each administrator may only be assigned to a limited number of tasks due to availability, or a subset of tasks due to his/her skill set, etc.

Clearly, how to model and mitigate the insider threat may not be straightforward even for such a simplified example (we will give the solution for this example scenario in Section 4.2), and the scenario might become far more complex in practice than the one demonstrated here. The remainder of the paper will tackle those challenges.

Remote Administrators, Maintenance Tasks, and Privileges

A cloud provider may hire different types of administrators to perform maintenance tasks onsite or through remote accesses [START_REF] Bleikertz | Secure cloud maintenance: Protecting workloads against insider attacks[END_REF]. First, hardware administrators have physical access to the cloud data center to perform maintenance on the physical components. Second, security team administrators are responsible for maintaining the cloud security policies. Third, remote administrators (RAs) perform maintenance tasks on certain nodes inside the infrastructure. The first two types can be considered relatively more trustworthy due to their limited quantity and the fact they work onsite, and directly for the cloud provider. The last type is usually considered riskier due to two facts, i.e., they work through remote access which is susceptible to attacks (e.g., via stolen credentials), and they may be subcontracted through third party companies which means less control by the cloud provider. In this paper, we focus on such remote administrators (RAs), even though our models and mitigation solution may equally work for dealing with other types of users if necessary.

There exists only limited public information about the exact maintenance tasks performed at major cloud providers. We have collected such information from various sources, and our findings are summarized on the left-hand side of Table 2, which shows sample maintenance tasks mentioned by Amazon Web Service [2], Google Cloud [START_REF]Google Cloud Platform[END_REF], and Microsoft Azure [4]. As to privileges required for typical maintenance tasks, Bleikertz et al. provided five sample privileges required for maintaining the compute nodes in clouds [START_REF] Bleikertz | Secure cloud maintenance: Protecting workloads against insider attacks[END_REF], which we will borrow for our further discussions, as shown on the right-hand side of Table 2.

Maintenance Task AWS [2] GCP [3] Azure [4] Review Logs × × × Hard Disk Scan × × Update Firmware × × × Patch Operating System × × × Update Operating System × × × System Backup × × × Upgrades System × × × Maintain Automated Snapshots × Bug Fix × × × Update Kernel × × Privilege Restriction

No privilege No access Read

Cannot read VM-related data Write L1

The restriction of read privilege applies, software modification restricted to trusted repository Write L2

Bootloader, kernel, policy enforcement, maintenance agent, file system snapshots, package manager transaction logs, and certain dangerous system parameters Write L3

No restriction To simplify our discussions, our running example will be limited to ten maintenance tasks on three compute nodes with corresponding privileges on such nodes, as shown in Table 3. Later in Section 4.2, we will expand the scope to discuss the solution for our motivating example which involves all the eight nodes.

Models

This section presnts out threat model and models of the maintenance task assignment and insider threat.

Threat Model and Maintenance Task Assignment Model

Our work is intended to assist the cloud provider in understanding and mitigating the insider threat from dishonest remote administrators or attackers with stolen credentials of a remote administrator. To this end, we assume the majority of remote administrators is trusted, and if there are multiple dishonest administrators (or attackers with their credentials), they do not collude (a straightfoward extension of our models by considering each possible combination of administrators as one insider can accommodate such colluding administrators, which is considered as future work). We assume the third party provider is trusted as an organization and will collaborate with the cloud provider to implement the intended task assignment. We assume the cloud provider is concerned about certain critical assets inside the cloud, and it is aware of the constraints about task assignments such as the number of remote administrators, their availability and skill set, etc. Finally, as a preventive solution, our mitigation approach is intended as a complementary solution to existing vulnerability scanners, intrusion detection systems, and other solutions for mitigating insider threats.

The cloud provider assigns the maintenance tasks to remote administrators (RAs) based on given constraints (e.g., which tasks may be assigned each RA), and consequently the RA will obtain privileges required by those tasks. This can be modeled as follows (which has a similar syntax as [START_REF] Sandhu | Role-based access control models[END_REF]).

Definition 1 (Maintenance Task Assignment Model). Given -a set of remote administrators RA, -a set of maintenance task T , -a set of privileges P , -the remote administrator task relation RAT ⊆ RA × T which indicates the maintenance tasks that are allowed to be assigned to each remote administrator, and -the task privilege relation T P ⊆ T × P which indicates the privileges required for each task, a maintenance task assignment is given by function ta(.) : RA → 2 T that satisfies (∀ra ∈ RA)(ta(ra) ⊆ {t | (ra, t) ∈ RAT } (meaning a remote administrator is only assigned with the tasks to which he/she is allowed), and the corresponding set of privileges given to the remote administrator is given by function pa(ra) = t∈ta(ra) {p | (t, p) ∈ T P }.

Insider Threat Model

We given an overview of our model for the insider threat, which will be demonstrated through an example shown in Figure 2. First, we borrow the resource graph concept [START_REF] Sheyner | Automated generation and analysis of attack graphs[END_REF] to represent the causal relationships between different resources inside the given cloud configuration. Second, we map the privileges given to RAs through maintenance task assignments (Definition 1) to exploits of corresponding resources in the resource graph. Third, we apply the k-zero day safety metric [START_REF] Wang | k-zero day safety: A network security metric for measuring the risk of unknown vulnerabilities[END_REF] to quantify the insider threat of each RA through his/her k value. Finally, we take the average (and minimum) of all RAs' k values as the average (and worst) case indication of insider threat.

Figure 2 shows an example resource graph for our running example (the dashed lines and shades can be ignored and will be discussed later in Section 4.2; also, only a small portion of the resource graph is shown here due to space limitations). Each triplet inside an oval indicates a potential zero day or known exploit in the format <service or vulnerability, source host, destination host> (e.g. <Xen, RA, 4> indicates an exploit on Xen), and the plaintext pairs indicate the pre-or post-conditions of those exploits in the format <condition, host> where condition can be either a privilege on the host (e.g., <W1,4> means the level 1 write privilege and <R,4> means the read privilege Fig. 2: Modeling insider threat using the resource graph which are both explained in Section 2.2), the existence of a service on the host (e.g., <Xen,4>), or a connectivity (e.g., <0,4>means attacker can connect to host 4 and <4,4> means a local exploit on host 4). The edges point from pre-conditions to an exploit and then to its post-conditions, which indicate that any exploit can be executed if and only if all of its pre-conditions are satisfied, whereas executing an exploit is enough to satisfy all its post-conditions.

In Figure 2, the left-hand side box indicates the normal resource graph which depicts what an external attacker may do to compromise the critical asset <user, Xen>. The right-hand side boxes depict the insider threats coming from RAs assigned to each of the three compute nodes. The gray color exploits are what captures the consequences of granting privileges to remote administrators. For example, an RA with the level 1 write privilege <W1,4> can potentially exploit Xen (i.e., <Xen w1,4,4>) to escalate his/her privilege to the user privilege on host 4 (i.e.., <user,4>), whereas a higher level privilege <W2,4> can potentially lead to the root privilege <root,4> through an exploit <Xen w2,4,4>, and the highest privilege <W3,4> can even directly lead to that priv-ilege. Those examples show how the model can capture the different levels of insider threats as results of different privileges obtained through maintenance task assignments.

Next, given the maintenance task assignment for each RA, we can obtain all the possible paths he/she may follow in the resource graph, starting from all the initially satisfied conditions (e.g., <Xen,4>) and those implied by the task assignment (e.g., <W1,4>) to the critical asset (i.e., <user,Xen>). To quantify the relative level of such threats, we apply the k-zero day safety metric (k0d) [START_REF] Wang | k-zero day safety: A network security metric for measuring the risk of unknown vulnerabilities[END_REF] which basically counts the number of zero day exploits (known exploits are not counted, and exploits of the same service are only counted once) along the shortest path. The metric value of each RA provides an estimation for the relative level of threat of each RA, since a larger number of distinct zero day exploits on the shortest path means reaching the critical asset is (exponentially, if those exploits are assumed to be independent) more difficult. For example, an RA with privilege <W3,1> would have a k0d value of 1 since only one zero day exploit <Xen,1,1> is needed to reach the critical asset, whereas an RA with <W2,1> would have a k value of 2 since an additional exploit <Xen w2,1,1> is needed. Finally, once we have calculated the k values of all RAs based on their given maintenance task assignments, we take the average (and minimum) of those k values as the average (and worst) case indication of the overall insider threat of the given maintenance task assignments. The above discussions are formally defined as follows.

Definition 2 (Insider Threat Model). Given the maintenance task assignment (i.e., RA, T , P , RAT , T P , ta, and pa, as given in Definition 1) let C r = ra∈RA pa(ra) be the set of privileges implied by the assignment and E r be the set of new exploits enabled by C r . Denote by G(E ∪ E r ∪ C ∪ C r , R) the resource graph (where E and C denote the original set of exploits and conditions, respectively, and R denote the edges) and let k0d(.) be the k zero day safety metric function. We say k0d(ra), ra∈RA k0d(ra) |RA| , and min({k0d(ra) : ra ∈ RA}) represent the insider threat of ra, the average case insider threat of the maintenance task assignment, and the worst case insider threat of the maintenance task assignment, respectively.

The Mitigation

In this section, we formulate the optimization-based solution for mitigate the insider threat during maintenance task assignment and discuss several use cases.

Optimization-based Mitigation

Based on our definitions of the maintenance task assignment model and the insider threat model, we can define the problem of optimal task assignment as follows. Note the remote administrator task relation RAT basically gives the constraints for optimization since it states which tasks may be assigned to which RA (in some cases the constraints may also be modeled differently for convenience, e.g., as the maximum number of tasks for each RA).

Definition 3 (The Optimal task assignment problem). Given a resource graph G, the remote administrators RA, maintenance tasks T , privileges P , the remote administrator task relation RAT , and the task privilege relation T P , find a maintenance task assignment function ta which maximizes the insider threat ra∈RA k0d(ra)

|RA|

(or min({k0d(ra) : ra ∈ RA})).

Theorem 1. The Optimal task assignment problem (Definition 3) is NP-hard.

Proof: First, calculating the k0d function is already NP-hard w.r.t. the size of the resource graph [START_REF] Wang | k-zero day safety: A network security metric for measuring the risk of unknown vulnerabilities[END_REF]. On the other hand, we provide a sketch of a proof to show the problem is also NP-hard from the perspective of the maintenance task assignment. Specifically, given any instance of the well known NP-complete problem, exact cover by 3-sets (i.e., given a finite set X containing exactly 3n elements, and a collection C of subsets of X each of which contains exactly 3 elements, determine whether there exists D ⊆ C such that every x ∈ X occurs in exactly one d ∈ D), we can construct an instance of our problem as follows. We use X for the set of maintenance tasks, and C for the set of RAs, such that the three elements of each c ∈ C represent three tasks which can be assigned to c. In addition, no RA can be assigned with less than three tasks, and an RA already assigned with three tasks can choose any available task to be assigned in addition. We can then construct a resource graph in which the critical asset can be reached through any combination of four privileges. It then follows that, the insider threat is maximized if and only if there exists an exact cover D due to the following. If the exact cover exists, then every RA d ∈ D is assigned with exactly three tasks and therefore the k value of every RA, and hence the insider threat, will be equal to infinity since the critical asset cannot be reached with less than four privileges; if the cover does not exist, then to have every task assigned, we will have to assign at least one RA with more than three tasks, and hence the k value will decrease.

2 In our study, we use the genetic algorithm to optimize the maintenance task assignments by maximizing k. Specifically, the resource graph is taken as input to the optimization algorithm, with the (either average case or worst case) insider threat value k as the fitness function. We try to find the best task assignment for maximizing the value k within a reasonable number of generations. The constraints can be given either through defining the remote administrator task relation RAT in the case of specific tasks that can be assigned to each RA, or as a fixed number of tasks for each RA. Other constraints can also be easily applied to the optimization algorithm. In our simulations, we choose the probability of 0.8 for crossover and 0.2 for mutation based on our experiences.

Use Cases

We demonstrate our solution through several use cases with different constraints. The first three use cases are based on the five remote administrators and ten maintenance tasks presented in Table 3 and the last use case is based on the motivating example shown in Section 2.1.

-Use Case A: In this case, each RA should be assigned with two tasks. The three tables shown in Table 4 show three possible assignments and the corresponding k values. Also, Figure 2 shows an example path (dashed lines) for tasks assigned to Table 4: Maintenance tasks assignments for use case A RA C 1 based on the top table, and also the shortest path yielding the minimum k value. We use the GA to find the optimal task assignment that meets the constraint given in this case, as shown in the last table, the maximal average of k values among all RAs is k = 2.2. It can also be seen that the minimum k value among all RAs is always k = 1 in this special case. -Use Case B: In this case, each RA should be assigned with at least one task. The optimal task assignment under this constraint is (RA1{8,9,10}, RA2{4,5}, RA3{3}, RA4{1,2}, and RA5 {6,7}). This relaxed constraint improves the average of k from 2.2 in the previous example to 2.8, which shows relaxing the constraint may increase k (which means less threat). -Use Case C: In this case, each RA can handle a fixed subset of tasks. In our example, we assume RA1 can be assigned to any task requiring the read privilege, RA2 to tasks requiring write level 1 privilege, RA3 to tasks requiring write level 1 and 2, RA4 to tasks requiring write level 3, and RA5 can be assigned to any task. After applying our solution, the optimal assignment yields the maximal average of k values to be k = 2.2. -Use Case D: This case shows the optimal maintenance task assignment for tasks discussed in our motivating example in Section 2.1. We have eight RAs and each RA can handle maximum two tasks. The upper table in Table 5 shows the 15 maintenance tasks to be assigned. In Table 5, the four tables on the bottom show four different tasks scenarios assigned to RAs and each table shows different average k.

The bottom table on the right side shows the optimal task assignment in term of the average k = 3.125.

Simulations

This section shows simulation results on applying our mitigation solution under various constraints. All simulations are performed using a virtual machine equipped with a 3.4 GHz CPU and 4GB RAM in the Python 2.7.10 environment under Ubuntu 12.04 LTS and the MATLAB R2017bs GA toolbox. To generate a large number of resource graphs for simulations, we start with seed graphs with realistic configurations similar to Figure 1 and then generate random resource graphs by injecting new nodes and edges into those seed graphs. Those resource graphs were used as the input to the optimization toolbox where the fitness function is to maximize the average or worst case insider threat value k (given in Definition 2) with various constraints, e.g., the number of available RAs and maintenance tasks and how many task may be assigned to each RA. We repeat each simulation on 300 different resource graphs to obtain the average result. The objective of the first two simulations is to study how the average case insider threat (i.e., the average of k values among all RAs) may be improved through our mitigation solution under constraints on the number of tasks and RAs, respectively. In Figure 3, the number of available RAs is fixed at 500, while the number of maintenance tasks is varied between 500 and 2,000 along the X-axis. The Y -axis shows the average of k among all RAs. The solid lines represent the results after applying our mitigation solution under constraints about the maximum number of tasks assigned to each RA. The dashed lines represent the results before applying the mitigation solution.

Results and Implications: From the result, we can make the following observations. First, the mitigation solution successfully reduces the insider threat (increasing the average of k values) in all cases. Second, the results before and after applying the solution decrease (meaning increased insider threat) following similar linear trends, as the number of maintenance tasks increases until each RA reaches its full capacity. Finally, the result of maximum four tasks per RA after applying the solution is close to the result of maximum ten tasks per RA before applying the solution, which means the mitigation solution may allow more (more than double) tasks to be assigned to the same number of RAs while yielding the same level of insider threat.

In Figure 4, the number of maintenance tasks is fixed at 2,500 while the number of RAs is varied between 400 and 1,000 along the X-axis. The Y -axis shows the average of k among all RAs. The solid lines represent the results after applying the mitigation solution and the dashed lines for the results before applying the solution. All the lines start with sufficient numbers of RAs for handling all the tasks since we only consider one round of assignment. We apply the same constraint as in previous simulation.

Results and Implications: Again we can see the mitigation solution successfully reduces the insider threat (increasing the average of k values) in all cases. More interestingly, we can observe the trend of the lines as follows. The dashed lines all follow a similar near linear trend, which is expected since a larger number of RAs means less insider threat since each RA will be assigned less tasks and hence given less privileges.

On the other hand, most of the solid lines follow a similar trend of starting flat then increasing almost linearly before reaching the plateau. This trend indicates that, the mitigation solution can significantly reduce the insider threat when the number of RAs is within certain ranges past which it becomes less effective (because each RA already receives minimum privileges). The trend of 4 tasks per RA is slightly different mostly due to the limited number of RAs. The objective of the next two simulations is to study how the worst case insider threat (i.e., the minimum k values among all RAs) behaves under the mitigation solution. Figure 5 and Figure 6 are based on similar X-axis and constraints as previous two simulations, whereas the Y -axis shows the minimum k among all RAs (averaged over 300 simulations).

Results and Implications: In Figure 5, we can see that the minimum k values also decrease (meaning more insider threat) almost linearly as the number of tasks increases. In contrast to previous simulation, we can see the minimum k values are always lower than the average k values, which is expected. In Figure 6, we can see the minimum k values also increase almost linearly before reaching the plateau as the number of RAs increases. In contrast to previous simulation, we can see the increase here is slower, which means the worst case results (minimum k values) are more difficult to improve with a increased number of RAs. Also, we can see that the worst case results reach the plateau later (e.g., 900 RAs for 8 tasks per RA) than the average case results (700 RAs).

Related Work

The insider threat is a challenging issue for both traditional networks and clouds. Ray and Poolsapassit proposed an alarm system to monitor the behavior of malicious insiders using the attack tree [START_REF] Ray | Proceedings, chapter Using Attack Trees to Identify Malicious Attacks from Authorized Insiders[END_REF]. Mathew et al. used the capability acquisition graphs (CAG) to monitor the abuse of privileges by malicious insiders [START_REF] Mathew | Insider abuse comprehension through capability acquisition graphs[END_REF]. Sarkar et al. [START_REF] Bishop | We have met the enemy and he is us[END_REF]. Roy et al. studied an employee assignment problem to find an optimal tasks assigned to the employee based on constraints in rolebased access control [START_REF] Roy | On optimal employee assignment in constrained role-based access control systems[END_REF].

There is lack of work focusing on the cloud security metrics in general and for insider attacks especially. Our previous work focus on applying threat modeling to cloud data center infrastructures with a focus on external attackers [START_REF] Alhebaishi | Threat modeling for cloud data center infrastructures[END_REF]. Gruschka and Jensen devise a high level attack surface framework to show from where the attack can start [START_REF] Gruschka | Attack surfaces: A taxonomy for attacks on cloud services[END_REF]. The NIST emphasizes the importance of security measuring and metrics for cloud providers in [START_REF]Cloud Computing Service Metrics Description[END_REF]. A framework is propose by Luna et al. for cloud security metrics using basic building blocks [START_REF] Luna | A security metrics framework for the cloud[END_REF].

Besides threat modeling, mitigating insider attackers in clouds is also a challenging task. There are many works discuss securing the cloud from insider attack by limiting the trust on the compute node [START_REF] Sze | Hardening openstack cloud platforms against compute node compromises[END_REF]. Li et al. focuses on supporting users to configure privacy protection in compute node [START_REF] Li | Mycloud: Supporting user-configured privacy protection in cloud computing[END_REF]. Closest to our work, Bleikertz et al. focus on securing the cloud during maintenance time by limiting the privilege grant to the remote administrator based on the tasks assigned to that administrator [START_REF] Bleikertz | Secure cloud maintenance: Protecting workloads against insider attacks[END_REF]. We borrow their categorization of the privileges. Our mitigation approach is also inspired by the network hardening approaches using genetic algorithms [START_REF] Gupta | Matching information security vulnerabilities to organizational security profiles: a genetic algorithm approach[END_REF][START_REF] Borbor | Diversifying network services under cost constraints for better resilience against unknown attacks[END_REF].

Conclusion

In this paper, we have modeled the insider threat during maintenance task assignment for cloud providers to better understand such threat posed by third party remote administrators, and we have formulated the optimal assignment problem as an optimization problem and applied standard optimization algorithm to derive a solution under different constraints. We have also conducted simulations whose results show our solution can significantly reduce the insider threat of remote administrators. Our future work will focus on following directions. First, we will improve our solution to handle more realistic scenarios, e.g., incremental assignment for streams of new maintenance tasks, and handling dynamics (joining or leaving) of RAs, giving priority or weight to tasks. Second, we will consider explicit cost models for assignments and incorporate the cost into the mitigation solution, e.g., based on the number of RAs, the amount or duration of tasks, and privileges needed.

Fig. 1 :

 1 Fig. 1: An example of cloud data center

Fig. 3 :Fig. 4 :

 34 Fig. 3: Average of k among 500 RAs before and after applying the mitigation solution

Fig. 5 :Fig. 6 :

 56 Fig. 5: Minimum k for 500 RAs

Table 2 :

 2 Maintenance tasks in popular cloud platforms (left) and the privileges (right)

Table 3 :

 3 Maintenance tasks and privileges for the running example

Table 5 :

 5 Maintenance task assignments for use case D (the motivating example)

		Task#		Maintenance task		Task#		Maintenance task
		1			Read log files for node 1		2 Modify configuration file for node 1
		3			Read log files for node 2		4	Install a new system for node 2
		5			Read log files for node 3		6 Modify configuration file for node 3
		7		Install a new system for node 3	8 Modify configuration file for node 4
		9		Install a new system for node 4	10	Read log files for node 5
		11		Install a new system for node 5	12	Read log files for node 6
		13 Modify configuration file for node 6 14	Read log files for node 7
		15			Read log files for node 8
	User	RA1 RA2 RA3 RA4 RA5 RA6 RA7 RA8	User	RA1 RA2 RA3 RA4 RA5 RA6 RA7 RA8
	Tasks Number	14 5	1 9	4 15 12 10 11 13 8 2 3 7	6	Tasks Number	1 9	2 10 11 12 13 14 15 3 4 5 6 7	8
	k	1	3	2	3	2	3	2	3	k		3	2	3	3	3	1	2	5
	k				2.375				k					2.75
	Minimum k				1					Minimum k				1
	User	RA1 RA2 RA3 RA4 RA5 RA6 RA7 RA8	User	RA1 RA2 RA3 RA4 RA5 RA6 RA7 RA8
	Tasks Number	1 4	2 7	3 9	5 10 11 12 14 6 15 13	8	Tasks Number	1 12	2 7	3 9	5 10 11 15 13 6 14 4	8
	k	3	2	4	4	3	2	1	5	k		3	2	4	4	3	1	3	5
	k				3					k					3.125
	Minimum k				1					Minimum k				1

Acknowledgements. The authors thank the anonymous reviewers for their valuable comments. This work was partially supported by the National Institutes of Standard and Technology under grant number 60NANB16D287, by the National Science Foundation under grant number IIP-1266147, and by Natural Sciences and Engineering Research Council of Canada under Discovery Grant N01035.


Luciano Argento
email: luciano.argento@unical.it

Andrea Margheri
email: a.margheri@soton.ac.uk

Federica Paci
email: f.m.paci@soton.ac.uk

Vladimiro Sassone
email: vsassone@soton.ac.uk

Nicola Zannone
email: n.zannone@tue.nl

Towards Adaptive Access Control

Keywords: Access control, machine learning, policy adaptation, insider threat, runtime monitoring

Access control systems are nowadays the first line of defence of modern IT systems. However, their effectiveness is often compromised by policy miscofigurations that can be exploited by insider threats. In this paper, we present an approach based on machine learning to refine attribute-based access control policies in order to reduce the risks of users abusing their privileges. Our approach exploits behavioral patterns representing how users typically access resources to narrow the permissions granted to users when anomalous behaviors are detected. The proposed solution has been implemented and its effectiveness has been experimentally evaluated using a synthetic dataset.

Introduction

Data are recognized as the most vital asset of an enterprise and, thus, their protection is of paramount importance. Access control systems are typically employed as the first line of defence for the protection of data as they guarantee that only authorized users can gain access to sensitive resources. Over the past few years, Attribute-Based Access Control (ABAC) [START_REF] Hu | Attribute-based access control[END_REF] has gained in popularity due to its flexibility and expressiveness, allowing the specification of fine-grained and context-aware access control policies.

Despite this flexibility and expressiveness, ABAC (and access control in general) has an intrinsically static nature that makes it difficult to adapt policies in order to timely response to critical events, e.g. a cyber attack. At the same time, policies can become out-of-dated quickly, thus requiring continuous, manual maintenance, which makes policy management and administration a cumbersome and error-prone task. These issues can lead to policy misconfigurations that leave organizations exposed to attacks against data confidentiality and integrity.

A study conduced by SANS in 2017 on threats against sensitive data 4 showed that insider threats are the top concern for organizations, followed by ransomware and denial of service attacks. Insider threats are current or former employees, contractors or business partners who have or had authorized access to the organization's network, system or data, and intentionally exceeds or misuses their privileges in a manner that negatively affected the confidentiality, integrity or availability of the organization's information or information system [START_REF] Silowash | Common sense guide to mitigating insider threats[END_REF]. Thus, organizations need to reinforce their access control systems with procedures to identify policy misconfigurations that could be exploited by an insider threat and update the policies to prevent such exploitations.

Detecting and preventing insider threats by analyzing access control policies and monitoring user behavior have been an active area of research. Common approaches rest on rule mining techniques to discover harmful exploitable policy faults [START_REF] Hwang | Mining likely properties of access control policies via association rule mining[END_REF][START_REF] Bauer | Detecting and resolving policy misconfigurations in access-control systems[END_REF] or on monitoring systems based on behavioral models to detect insider threats [START_REF] Park | Role-based profile analysis for scalable and accurate insider-anomaly detection[END_REF][START_REF] Maloof | Elicit: A system for detecting insiders who violate need-to-know[END_REF][START_REF] Legg | Caught in the act of an insider attack: Detection and assessment of insider threat[END_REF][START_REF] Alizadeh | Behavior Analysis in the Medical Sector: Theory and Practice[END_REF]. Other works [START_REF] Hu | Applying role based access control and genetic algorithms to insider threat detection[END_REF][START_REF] Park | Role-based profile analysis for scalable and accurate insider-anomaly detection[END_REF] have also exploited knowledge from access control policies to detect insider threats. However, these approaches only aim at threat detection and do not focus on the adaptation of access control policies. To date, only a few works (e.g., [START_REF] Costante | A hybrid framework for data loss prevention and detection[END_REF][START_REF] Frias-Martinez | A network access control mechanism based on behavior profiles[END_REF]) have exploited user behavior to generate and adapt access control policies. However, these approaches either require human intervention for policy update [START_REF] Costante | A hybrid framework for data loss prevention and detection[END_REF] or build models that do not properly discriminate behaviors of different types of users [START_REF] Frias-Martinez | A network access control mechanism based on behavior profiles[END_REF]. Contribution. In this paper, we propose an approach based on machine learning to dynamically refine policies to prevent misconfiguration exploitation. The proposed approach allows the refinement of access control rules according to behavioral features monitored at run-time. The designed system, named ML-AC, exploits a white-box decision learning approach whose aim is to learn behavioral profiles of users accessing resources so to accurately refine policies. There might exist different behavioral profiles, here called classes of interaction, that can be determined based on the analysis of contextual knowledge that concerns users and resources. Such knowledge has proven to be a valuable source of information for approaches devoted to improve insider threat detection and access control [START_REF] Maloof | Elicit: A system for detecting insiders who violate need-to-know[END_REF][START_REF] Hummer | Adaptive identity and access management contextual data based policies[END_REF].

ML-AC uses access pattern knowledge learned at run-time to introduce controls on behavioral features into access control rules to avoid abuse of granted rights. Behavioral features refine access policies by introducing controls like frequency of access, amount of data, location, etc. By building an access control knowledge model, this work poses the basis towards machine-assisted administration procedures to support timely changing of access rights. Paper structure. Section 2 provides a motivating example. Section 3 provides an overview of ML-AC and details how machine learning is empowering access control. Section 4 describes the implementation and evaluation of the performance of ML-AC. Section 5 concludes the paper and outlines directions for future work.

Motivating Example

To outline our approach, we introduce an ABAC system managing accesses to software projects within an organization where users' permissions depend on their role and on the projects they are assigned to.

Let us assume an access control policy allowing users assigned to role junior manager to read resources of type R1. However, only junior managers working on ProjectA and from Department 1 can actually access those resources. This policy can be represented in the FACPL language [START_REF] Margheri | A Rigorous Framework for Specification, Analysis and Enforcement of Access Control Policies[END_REF], an XACML-like ABAC language that we use for its conciseness, as follows: policy policy1 {deny-unless-permit rule rule1(permit target: equal ("read", action/id) && equal ("R1", resource/type) && equal ("Junior manager", subject/role) && equal ("Department1", subject/department) && equal ("ProjectA", subject/project))}

Intuitively, our sample policy consists of a policy element (policy1) comprising a permit rule (rule1) whose target defines an access condition built on attributes describing which action a certain subject can perform on a resource.

Let us assume that Bob, a junior manager of Department 1, attempts to read a resource of type R1, represented by the following access request (req1):

(subject/department,"Department 1") (subject/role, "Junior manager") (subject/project, "ProjectA") (action/id="read") (resource/type,"R1")

It is easy to observe that the attributes in the request match the rule target, thus yielding a permit decision. 5Suppose now that Bob attempts to retrieve a large amount of sensitive project documents without a plausible reason. As the previous request exemplifies, policy1 would allow him to do so regardless of how many documents he has retrieved. This situation, however, may indicate that the junior manager is abusing his access privileges for personal interests and benefits (e.g., to sell the documents to a competitor).

These insider threats cannot be prevented by existing access control systems. The main problem lies in the fact that access control is static in the sense that the enforced access conditions do not change dynamically according to user behaviour. We argue that contextual features, such as the number of accesses and amount of accessed data, should be taken into account in access decision making. For instance: Could a user perform multiple read queries in a given time window? Could a user access large amounts of data? Failing to answer these questions can lead to neglect anomalous behaviour representing the abuse of granted access privileges from insider threats.

To reduce the risks of users abusing their privileges, we need to empower access control with proactive measures that adapt policies according to user behavior. Specifically, our goal is to dynamically refine access control policies based on user behaviour monitored at run-time by narrowing granted privileges.

To achieve this goal, we need to equip access control systems with a means to build user profiles representing how users normally access resources and use those profiles to dynamically refine access rules. This requires extracting contextual features that capture For the sake of exemplification, let us assume that contextual features feature/NumberOfReadsPerHour and feature/BytesReadPerHour are monitored by the system and can be checked via new attributes in access rules. In particular, it is observed that every hour junior managers typically access at most 14 project documents for a total 345.6 KB. This knowledge can be exploited to refine policy1 as follows: Intuitively, policy2 narrows the access conditions of policy1 through contextual features by imposing additional constraints on how much and how often resources are typically accessed by junior managers. Consider, for instance, the case where Bob attempts to access 50 project documents within 10 minutes. Based on the updated policy, this behavior would be deemed as anomalous and thus denied, preventing Bob to access all documents.

Adaptive Access Control

In this section, we introduce ML-AC, a system for adaptive access control that aims to reduce the risks of users abusing their privileges. Figure 1 presents the ML-AC architecture. It comprises the following components:

-Authorization Server is a standard ABAC infrastructure à la XACML based on PEP/PDP. -Policy Administration Point (PAP) features the proactive policy refinement functionalities proposed in this work. -Monitoring System supervises the whole system and provides the information needed to build behavioral profiles used by Policy Administration in its refinement process. Once an access request is received by the Authorization Server (step 1), it is evaluated following typical PEP/PDP evaluation frameworks. If access is granted (i.e., a permit decision is returned) by the Authorization Server, the request, together with the corresponding behaviour provided by the Monitoring system, is forwarded to the PAP (step 2) to determine whether it is anomalous. The PAP dynamically refines the access control policies based on the user behavior and enforce them in the Authorisation Server (steps 3-4). Administrators are informed of the changes (step 5).

Our contribution lies in the Policy Administration component. Specifically, we equip PAPs with the Contextual Behaviour Learning component, which is responsible to build user profiles according to the monitored behavior and refine access control policies based on those profiles. The Concept Drift component detects the evolution of the learned user profiles and inform the Contextual Behavior Learning component when new behaviors are detected (step 3).

In the remaining, we introduce our representation of behavioral models and present the mechanics of the Contextual Behaviour and Concept Drift components.

Behavioral Model

To build the behavioral models used to identify anomalous accesses, we introduce the notion of user behavior. Behaviours, denoted as b, represent how users are utilizing resources. They are defined in terms of the attributes forming access requests (i.e., user, resource and action) and of any contextual knowledge features that can be exploited by the access control system for decision making (e.g., working time, working location, types of activities). Formally, a behaviour is defined as:

b A u 1 , . . . , A u m , A o 1 , . . . , A o h , A r 1 , . . . , A r k , . . . A c 1 . . . A c z
where attribute A u i describe users, A o k operations, A r y resources and A c z the context. An attribute is an expression of form A name op value , where op is a relational operator (e.g., =, >) between an attribute name and a value from the attribute's codomain. For instance, the following behaviour (we shorten attribute names for ease) b 1 = role = jnr-mng, act = read, res = R1 , #byte = 250, #read = 10 corresponds to the access request reported in Section 2, where #byte and #read are contextual features provided by the Monitoring System.

Behaviors are grouped into so-called class of interactions. Each class represents a group of homogeneous behaviours (i.e., whose representation involves the same set of attribute name) that are considered normal. We assume that the set of initial classes are defined according to the access policy rules, hence on the basis of the controls on user, action and resource attributes. Changes at runtime to the classes are managed by the Concept Drift component (Section 3.3).

Contextual Behavior

Our approach builds behavioral profiles of normal accesses in the form of class of interactions. To determine to which class of interaction a given behavior belong, we relies on Random Forest (RF) [START_REF] Breiman | Random forests[END_REF], where each RF is used to characterize a class of interaction. Based on this matching, the knowledge on the corresponding contextual features is used to refine access control policies.

Learning Practicalities. Given a class of interactions C i , our goal is to recognize whether a user behavior b i is similar to those represented by C i or not, i.e. whether b i is anomalous. Practically, being b i a potentially anomalous behavior, we cannot assume it will always match (the attributes of) C i . It follows that this problem cannot be addressed as a multi-class classification (labels would be represented by the classes of interactions and our goal would be to determine if the label of a test sample b i is C i or another C j , with i = j), but as a One Class Classification (OCC) problem [START_REF] Tax | One-class classification: Concept-learning in the absence of counter-examples[END_REF] for each of class of interaction C i individually.

Solutions for the OCC problem are numerous. However, being our goal to obtain learning outputs that can be used to refine policies, we opted for the white-box approach of RF. Specifically, each RF is an ensemble of Decision Tree (DT) each of which models the conditions on the attributes identifying the normal behaviors of a class. Each DT produces an output of the form of antecedent ⇒ consequent rules [START_REF] Quinlan | Generating production rules from decision trees[END_REF]. The antecedent consists of logical conjunctions stating under which conditions a behavior can be classified as normal or anomalous, as indicated by the consequent.

It is worth noting that each DT produces its own output, leading to potential inconsistencies. For instance, let us suppose a RF with three DTs. Given a behavior b, each DT produces its own decision, e.g. DT 1 (b) = 1, DT 2 (b) = 0 and DT 3 (b) = 1, where 1 and 0 denote normal and anomalous behavior, respectively. To solve this problem RF relies on a majority vote algorithm among DTs; hence b is classified as normal. Notably, a final decision can always be guaranteed by using a known RF voting solution [START_REF] Andrzejak | Interpretable models from distributed data via merging of decision trees[END_REF].

Access Control Refinement. The DT outputs, hereafter called ML-rules, is used to bridge from the machine learning world to the actual refinement of access control policies. Practically, they encode the obtained knowledge in terms of additional conditions to add to the access control policy. The syntax of ML-rules is defined by the following grammar: where true (resp., false) identifies a normal (resp., anomalous) behavior. The antecedent consists of a conjunctive sequence of conditions, whereas the consequent is a Boolean value stating whether a behavior satisfying the antecedent is normal or anomalous. For instance, the following ML-rule represents the refinement leading from policy1 to policy2 of the example role = jnr -mng && act = read && res = R1 && #read < 14 && #byte < 345.6 ⇒ true Therefore, ML-rules are used to transfer the contextual knowledge learned by the RFs into the access control policies. Policy refinement occurs on the basis of the conditions on the contextual features present in an ML-rule (e.g., the #read and #byte above). Practically, the access control rules to refine correspond to those matching the conditions on user, action and resource attributes present in the ML-rule. The refined rules contain the additional controls on the contextual features as per the example of policy2.

ML

Concept Drift

After the behavioral models have been build, the system starts monitoring the evolution of user behaviors to detect concept drifts in order to maintain the RF models accurate over time. It follows from the RF design that concept drifts can only be detected on the contextual features.

To this aim, we rely on Olindda [START_REF] Spinosa | Novelty detection with application to data streams[END_REF], a clustering-based approach similar to the one followed by BBNAC [START_REF] Frias-Martinez | A network access control mechanism based on behavior profiles[END_REF]. Olindda uses the well-known k-means algorithm (or one of its extensions, e.g. k-modes for categorical features) to cluster behaviors of the classes of interactions and detect the emergence of new classes (aka new clusters) based on the distance among clusters.

Figure 2(a) depicts a scenario where concept drift can be observed. For instance, given three classes of interactions C 1 , C 2 and C 3 , at the beginning just three groups of user behaviors, respectively the clusters A, B and D of blue-filled shapes, are identified. After a certain amount of time, the behaviors in the cluster D change to the point that concept drift is detected: the red-filled shapes. Therefore, these behaviors are used by the RF modelling the class C 3 to update its knowledge accordingly. Additionally, when behavior like those represented by red cross shapes are observed, i.e. not forming any cluster, Olindda deems them as anomalies. This is the key assurance to avoid RF to refine access control policies with conditions allowing anomalous behaviors.

Notably, emerging concepts may overlap among classes leading to difficulties in their classification. For instance, Figure 2(b) depicts new concepts emerging from the cluster D that present similarities to both cluster D (circle shapes) and cluster B (square shape). All emerging concepts like the latter are treated as anomalies.

Divergence in clusters.

A key aspect of concept drift is the emergence of sub-clusters within an existing cluster. Given a class C i , it may happen that a subset of its users start behaving significantly different from the remaining users, over time. This would lead to the discovery of new classes of interactions detailing different behavioral profiles.

Our approach aims to build classes of interactions that are characterized by behaviors that are very similar to each other. Therefore, in the light of the new discovered

Evaluation

To evaluate the effectiveness of our approach, we have implemented it 6 and performed experiments using a synthetic dataset. The goal of the experiments is to demonstrate the benefits of combining domain context knowledge (inferred using machine learning) with knowledge based on access control rules (used to create classes of interaction) for the detection of anomalies. In particular, we assess the detection accuracy of ML-AC by analyzing the number of true and false positive. This will allows us to demonstrate how the refinement based on this detection approach will prevent anomalies to happen a priori. Note that we do not evaluate the use of machine learning to classify user behavior, being this extensively reported in the literature (e.g., [START_REF] Nellikar | Role-based differentiation for insider detection algorithms[END_REF]).

In the experiments, we compared our approach for anomaly prevention with two other approaches.We took BBNAC [START_REF] Frias-Martinez | A network access control mechanism based on behavior profiles[END_REF], the closest approach from the literature. To avoid bias in the experimentation, we re-implemented BBNAC in Matlab. 7 Additionally, we performed a comparison with ML-AC nok , a variant of ML-AC where a priori knowledge on the policy is not used. This allows us to better assess the role of contextual knowledge. Dataset. We generated a synthetic dataset whose data instances represent user behaviors, under the assumption that there are two classes of interactions. The behaviors are represented as three-dimensional points and based on numerical features. We generated over 3000 behaviors, with almost an equal number of normal and anomalous instances. Intuitively, about 2000 behaviors were used for training, while the rest for testing. Results. To evaluate the accuracy of the approaches, we computed the ROC curve for the three evaluated approaches (Figure 3). The ROC curve is a graphical plot we use to evaluate how well the classifier we defined distinguishes between normal and anomalous behaviors, based on a varying discrimination threshold (i.e., the value used to deem a behavior anomalous). Specifically, it shows the true positive rate or TPR (y-axis) against the false positive rate or FPR (x-axis) with respect to different threshold settings. These performances can also be reduced to a single scalar value, called area under the ROC curve (AUC), which represents the probability that a classifier will rank a randomly chosen anomalous instance higher than a randomly chosen normal instance. This gives better insights on the number of false positive detected.

As can be seen in Figure 3, ML-AC achieves the best performance. ML-AC significantly surpasses the others due to the use of a priori knowledge on the policy. This allows ML-AC to create more accurate profiles and hence to discern more precisely among groups of behaviors. Specifically, we have that the AUC drops from the 99% of ML-AC to the 87% and 85% of ML-AC nok and BBNAC, respectively. The main cause is that both BBNAC and ML-AC nok classify most of the anomalous behaviors of each class as a normal behavior of the other class.

Conclusion

In this paper we proposed ML-AC, an approach to refine and update access policies in order to eliminate policy misconfigurations that can be exploited by insider threats. ML-AC builds behavioral models representing the normal usage of resources and exploits these models at run-time to prevent anomalous accesses. Our approach has been implemented and validated using a synthetic dataset. Future work. There are a number of interesting aspects to address as future work. Firstly, we plan to conduct more extensive experiments based on real-life datasets and measure the number of refinement applied in practice to the access control policies.

Moreover, we would like to study further the presence of an adversarial attacker [START_REF] Huang | Adversarial machine learning[END_REF], who may try to deceive the machine learning algorithm in order to bypass security controls. ML-AC employs different machine learning algorithms to achieve its goals, therefore it may incur in the risk of being subject to adversarial attacks. The definition of class of interaction may constitute a starting point for devising strategies to hinder typical attacks such as causative and exploratory. The fact that user behaviors are split based on the classes, may make the task of deceiving ML-AC quite difficult. Many anti-adversarial algorithms have been proposed in literature, like those presented in [START_REF] Frias-Martinez | A network access control mechanism based on behavior profiles[END_REF] that effectively mitigate threats related to concept drift.

Another aspect concerns classes of interactions. It might not always be possible to clearly define those classes based only on the knowledge derived from the context and access control policies. There may be some classes that should be merged or split, hence we plan to design a preprocessing step to support the classes definition process.

Fig. 1 .

 1 Fig. 1. The ML-AC system

  -rule ::= Antec ⇒ Consec Antec ::= Cnd {&& Cnd} Cnd ::= name op value Op ::= = | > | < | ≤ | ≥ | in Consec ::= true | false

Fig. 2 .

 2 Fig. 2. Detection of concept drift

Fig. 3 .

 3 Fig. 3. Comparison among ML-AC, BBNAC and ML-AC nok

https://www.sans.org/reading-room/whitepapers/analyst/ sensitive-data-risk-2017-data-protection-survey-37950

We overlook combining algorithm deny-unless-permit as it yields permit if the enclosed rule returns permit, and yields deny otherwise.

The tool is freely available at https://github.com/cybersoton/ml-ac/