Coverage-Based Test Cases Selection for XACML Policies

Abstract

Abstract-XACML is the de facto standard for implementing access control policies. Testing the correctness of policies is a critical task. The test of XACML policies involves running requests and checking manually the correct response. It is therefore important to reduce the manual test effort by automatically selecting the most important requests to be tested. This paper introduces the XACML smart coverage selection approach, based on a proposed XACML policy coverage criterion. The approach is evaluated using mutation analysis and is compared on the one side with a not-reduced test suite, on the other with random and greedy optimal test selection approaches. We performed the evaluation on a set of six real world policies. The results show that our selection approach can reach good mutation scores, while significantly reducing the number of tests to be run.

Security Testing

“…Testing the security of the communication channels includes approaches that check the correct validation of SSL/TLS certificates (e.g., Frankencerts [18]) as well as protocol fuzzers such as SNOOZE [10] or SECFUZZ [124]. For testing the correct access control, various model based approaches (e.g., [13,19,85]) haven been applied to case studies of different size. Finally, tools like Nessus [109] that rather easily allow to scan networks for applications with known vulnerabilities and, thus, applications that need to be updated or patched.…”

On‐line tracing of XACML‐based policy coverage criteria

“…In literature there are few works facing coverage assessment of XACML policies. Seminal works are presented in [17] and [6]. In the former, the authors provide a first coverage criterion for XACML policies defining three structural coverage metrics targeting XACML policies, rules and conditions respectively.…”

“…This section provides a set of XACML coverage criteria useful for assessing the effectiveness of a generic XACML based testing strategy. Revising and extending the definition provided in [5], we first provide some generic definitions concerning the policy (Definitions 1 and 2) and request elements (Definition 4) and then we define the XACML coverage criteria (Definitions 5, 7, 9, 11).Definition 1 (Target Tuple): Given a Rule R , a Policy P , a PolicySet PS , with R P and P PS , and given the set of XACML elements, called XE = { xe: xe is PS or P or R }, the Target Tuple of an xe XE , called , is a 4‐tuple ( S , Res , A , E ), where S ( Res , A , E ) is a finite set of subjects (resources, actions, environments) in the XACML target of xe .…”

“…Intuitively, the main goal is to derive an acyclic graph, defining a partial order on policy elements. Several proposals are available such as [5, 8] for XACML policy specification. Once extracted, the traces are provided to the Monitor infrastructure . Policy evaluation engine is in charge of the execution of the policy and the derivation of the associated response.…”

“…Specifically, the authors introduced the concept of reachability‐based and firing‐based fault localisation techniques. In this paper, we extend the criteria proposed in [5] differentiating the concept of Rule Target matching, so to better analyse the evaluation of policy rules.…”