This is an archive
(replace .gov by .rip)

Access Control Policy Testing ACPT

Access Control Rule Logic Circuit Simulation (ACRLCS)

Access control (AC) policies can be implemented based on different AC models, which are fundamentally composed by semantically independent AC rules in expressions of privilege assignments described by attributes of subjects/attributes, actions, objects/attributes, and environment variables of the protected systems. Incorrect implementations of AC policies result in faults that not only leak but also disable access of information, and faults in AC policies are difficult to detect without support of verification or automatic fault detection mechanisms.

Most research on AC model or policy verification techniques are focused on one particular model, and almost all of the research is in applied methods, which require the completed AC policies as the input for verification or test processes to generate fault reports. Even though correct verification is achieved and counter examples may be generated along with found faults, those methods provide no information about the source of rule faults that might allow conflicts in privilege assignment, leakage of privileges, or conflict of interest permissions. The difficulty in finding the source of faults is increased especially when the AC rules are intricately covering duplicated variables to a degree of complexity. The complexity is due to the fact that a fault might not be caused by one particular rule; for example, rule x grants subject/attribute s access to object/attribute o, and rule y denies the group subject/attribute g, which s is a member of, access to object o. Such conflict can only be resolved by removing either rule x or y, or the g membership of s from the policy. But removing x or yaffects other rules that depend on them (e.g., a member of subject group g k is granted access to object o), and removing s’s membership in g will disable g‘s legitimate access to other objects/attributes through the membership. Thus, it requires manually analyzing each rule in the policy in order to find the correct solution for the fault.

To address the issue, CSD researched the AC Rule Logic Circuit Simulation (ACRLCS) technique; this research proposes an automatic method through the construction of a simulated logic circuit that simulates AC rules in AC policies or models. The simulated logic circuit allows real-time detection of policy faults including conflicts of privilege assignments, leaks of information, and conflicts of interest assignments. Such detection is traditionally done by tools that perform verification or testing after all the rules of the policy/model are completed, and it provides no information about the source of verification errors. ACRLCS enables the AC authors to detect a fault when the fault-causing AC rule is added to the policy/model, so the fixing can be implemented in real time before adding other rules that further complicate the detecting effort. Thus, rather than checking by retracing the interrelations between rules after the policy is completed, the policy author needs only check the newly added rule against previous “correct” ones. In ACRLCS, AC rules are represented in a Simulated Logic Circuit (SLC). The use of simulation may restrict ACRLCS implementation on a physical electronic circuit; however, the concept can be implemented and computed through simulated algorithm.

Access Control Rule Logic Circuit Simulator Prototype System

Access Control Rule Logic Circuit Simulator Prototype System


Prototype:

Access Control Rule Logic Circuit Simulator prototype system (Please contact vincent.hu@nist.gov for download password) was developed by Skye J. Horbrook from Department of Computer Science of Bowie State University in August, 2013, and Xinyu Xiong from Department of Computer Science of the City College of New York in August 2016.


References:

Vincent Hu, Karen Scarfone, “Real-Time Access Control Rule Fault Detection Using a Simulated Logic Circuit”, Proceeding, 2013 ASE/IEEE International Conference on Privacy, Security, Risk and Trust, Washington D.C., USA, September 8-14, 2013.

DISCLAIMER :
Certain software products are identified in this document. Such identification does not imply recommendation by NIST, nor does it imply that the products identified are necessarily the best available for the purpose.

Created May 24, 2016, Updated December 17, 2020