Rule-Based Systems Security Model - Computer Network Security - page 136

3. There is a strong need to be able to update rules incrementally at run time without
rebooting or suspending a system.
Based on the above commonalities we distinguish two types of behaviours — the
one of network functionality ( functional behaviour), and the one of a rule-set control-
ling access to the functionality ( ruling behaviour). The former is of common interest,
while the latter is of interest only to rule-set designers — it should be transparent to a
common and legal user of functionality.
Behaviour of a rule-based system is the one exhibited jointly by functional and rul-
ing behaviours (section 2) and is defined by openly exposed rules rather than by hid-
den state transitions, that makes these systems more flexible, and, at the same time
more vulnerable to potential attacks. Nevertheless, they are attractive for they meet
three core requirements: openness, flexibility, and scalability.
A rule-based system is open because its components have standard conventions for
service syntax and semantics. It is flexible because it is relatively easy to configure a
service out of open components by distributing to them behaviour definitions , i.e. rule
sets defining ruling behaviour for a service under configuration. Finally, a rule-based
system scales because of its potential to evolve — ruling behaviour can be changed
gradually to adapt to new requirements.
Taken altogether the three networking requirements above can be called network
programmability , a feature that lies at the very heart of network provisioning business
- to guarantee optimal policy for each user/application. M. Sloman explains policy as
“a rule that defines a choice in the behaviour of a system” [2]; hence any network
element is composed of element's policy and element's mechanism - the two distinct
concerns in their design, management and in security considerations.
In this paper we concentrate on securing the policy part, or the part containing de-
finitive rules of the rule-based system. Based on security policy framework section
two introduces further separation of concerns in a rule-based system that enables rule
base programmability. This opens an opportunity for dynamic service creation; sec-
tion three provides needed framework for creating services by modifying rules in
rule-based systems. Needed building blocks for this — events, monitors and rules
with negative modalities - are discussed in section four. Section five concludes the
generic part by introducing a rule-based system security model. Section six examines
conflict resolutions and rule base self-organisation followed by a conclusion.

2 Separation of Concerns in Rule-Based Systems

Access control issues are traditionally studied within security policy research, where a
Subject ( Su ) is attempting to get access to certain action ( a i ) at a target Object ( Ob ),
i.e. to invoke a i by sending a request
Su request(Su, Ob, a i ) Ob, (1)
Within a policy abstraction framework a notion of a policy agent was introduced as
a placeholder for various policies, including authorisation ones. Logically a policy
agent sits between a Subject and an Object; in implementation however it is embed-
ded into their mechanisms. Based on organisational role modelling of security policy
area M. Sloman proposes two types of policies - obligation ( O ) and authorisation ( A ),