Information Technology Reference
In-Depth Information
translated to one ACL item. One more kind of SPL rules defines decision algorithms.
There might be Deny Take Precedence, Permit Take Precedence, More (Less)
Specific Take Precedence, or another user-defined algorithm. Thus, policy rules and
conflict resolution strategies are described in SPL, security capabilities of a network
node (PEP) are defined in SDL.
Present-day policy-based security systems also include these three categories of
information, but not all three at the same time. Extended access control markup
language (XACML) supports access control policies. Three-level structure of policy
description (rule - policy as a set of rules - set of policies) allows to build flexible
resolution system using formalized notion of decision algorithm on the levels of
policy and policy set. XACML does not support system description language directly,
as network nodes are represented in rules. Ponder language [9] contains rules for
positive and negative authorization, obligation and delegation. The authors of Ponder
suggested several approaches for conflict resolution strategies [7]. Flexible
Authorization Framework (FAF) [3,4] studies access control policies. The advantage
of proposed system and reasoning is deep consideration of object, subject, and
privileges hierarchies. The language allows the specification of positive and negative
authorization and incorporates notions of authorization derivation, conflict resolution
and decision strategies.
The are also several relevant papers devoted to different techniques of conflict
detection and resolution, including deontic logic (L.Cholvy, et. al.), dynamic conflict
detection and resolution (N.Dunlop, et. al.), detecting conflict of duty (D.Ferraiolo,
R.Sandhu, et. al.), policy conflicts specification and resolution (Morris Sloman, et.
al.), credential-based approach to specification of access control policies, conflict
resolution in event-based policy management (Jan Chomicki), etc.
In our approach we try to use a set of different approaches in one common
framework for conflict detection and resolution in different policies (authentication,
confidentiality, filtering, etc.). The paper presents the architecture of Security Checker
intended for disclosure and resolution of policy conflicts and illustrates methods of
conflict detection based on event calculus. Section 2 describes the architecture of
policy-based security system proposed, the Security Checker architecture and
implementation issues. Section 3 characterizes the event calculus-based verification
module. Section 4 summarizes the results of the paper.
2 Security Checker Architecture and Implementation
The general architecture of policy-based security system is presented in fig. 1 [10].
Security checker
(SEC) checks if the policies are consistent and can be implemented
with the functionality available in the information system. SEC plays a role of
SDL/SPL debugger, which interacts with user approving SPL/SDL descriptions or
pointing to inconsistencies.
Configuration Generator
produces
Generic Security
Rulesets
(GSR) which are the set of rules that do not keep into account the specific
implementation of security block (e.g. firewall type and manufacturer).
Security
Technology Mapper
transforms GSR into a specific configuration for each security
block in the system. This step will need the help of
Block Security Maps
provided by
the manufacturer of the block.
Security Deployment Engine
transfers configuration to
