Security Checker Architecture for Policy-Based Security Management - Computer Network Security - page 460

Security Checker Architecture
for Policy-Based Security Management
Artem Tishkov, Igor Kotenko, and Ekaterina Sidelnikova
SPIIRAS, 39, 14 Liniya, St.-Petersburg, 199178, Russia
{avt, ivkote}@iias.spb.su, [e-mail]
Abstract. Policy-based management systems are now the object of steadfast
attention in network security theory and applications. Due to a complex
structure of subject role hierarchies, target grouping, and action mutual
dependence the security policy conflicts are complicated to detect and resolve.
Moreover, an initially consistent policy ruleset may lead to inconsistent or
unenforceable rules during the system lifecycle. The paper presents the
architecture of Security Checker module (intended for disclosure and resolution
of policy conflicts) and illustrates conflict detection based on event calculus.
1 Introduction and Motivation
Recently, common standard for policy-based security architecture is the one provided
by the IETF through several of its working groups, mainly policy framework (policy)
WG [2]. Policy rules are stored in a repository and policy decision point (PDP) is
separated from the policy enforcement point (PEP). Centralization of policy rules
store allows to build separated (passive) software tool for verification of security
policy as a whole. However, since verification process includes decision making in a
conflict situations, the verification tool should provide a conflict resolution strategy
used by PDP. PDP in turn sends decision to PEP which has to be appropriate to PEP
capabilities. Therefore, the verification tool needs three kind of information: policy
rules from repository, resolution strategy, and security capabilities of PEP.
Proposed policy-based framework which is under development in the Positif
Project [10] contains two input languages: System Description Language (SDL) and
Security Policy Language (SPL). SDL formally describes the information system. The
language supports the description of (1) system topology as network elements and
physical connections, (2) the network services offered and the applications supported
for each network element, (3) the security functionality of element such as network
filters, OS intrinsic controls, application-level ACL, etc. SPL specifies a security
policy. The language is able to describe high-level and low-level security policy rules.
High-level rules express a composite task that implies a number of actions to
implement. For example, to enforce the rule “Split the network into two independent
subnetworks”, the system should perform gateway reconfiguration, change of IP
addresses and subnet mask, and, possibly, addition of new filtering policies. Low-
level rules are more specific and in most cases could be considered as atomic action.
For example the rule “block any packet from network 195.19.200” would be