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

identity and we call it hereafter Service Invocation ID (SID). Examples of SID are
source IP address, AAA 1 credential, session ID, etc.
Within the security policy area events are recognised as important trigger of
obligations. Within device configuration policy area events are used as a performance
enhancement during the policy information base lookup process. Within a traditional
representation of a configuration policy (7)
Event IF Condition THEN Action (7)
an occurrence of an event is yet another condition, though maybe the one with much
higher update frequency than that of other conditions. Dynamic rule-based systems
change their behaviour at run-time, this breaks traditional boundary between events
and conditions, thus we adopt generic event-only policy provision (8):
IF Events THEN Action (8)
As a consequence of a service domain concept that compartments all service en-
ablers, we introduce a notion of a Monitor - a placeholder for a notification policy .
Notification policy is Monitor's obligation to notify Su or Ob on occurrence of pre-
defined actions by reporting their post-conditions in a form of events to pre-specified
event channels. Similar to roles that help to abstract behaviours from subjects, event
channels help to abstract events from actions in (8), thus opening an opportunity for
flexible service creation by enforcing (obligation, authorisation and notification) rules
that would produce needed events, trigger needed actions being properly authorised.
We impose no limitations on either event channels or on their publish and sub-
scribe interfaces. We are interested in what happens before an event is published and
after an entity receives a particular event. In case of obligation a request is an event
that notifies target object on the need to invoke an action specified within subject's
obligation policy; in the notification case a notification is a report on monitored ac-
tion. This similarity motivates us to protect event subscribers (both subjects and ob-
jects) by event authorisation rules, with the main purpose to filter out (by A- policy)
all unwanted or forbidden events, thus retaining (3) in our framework. The reason to
retain another odd policy - negative obligation (5) - is manifold. First, this might be
needed to revoke subject's certification in an event driven, i.e. dynamic manner. Sec-
ond, monitors that detect conflicts in rule-based systems may trigger the use of nega-
tive obligation policies as conflict isolation and conflict resolution rules.
Section 6 aims to demonstrate that negative modality of rules is the key to achieve
scalable programmability and self-organisation of rule-based systems.

5 Rule-Based Systems Security Model

Putting the above pieces together we propose the following model (Fig. 1). It uses two
types of authorisation and two types of obligation rules regardless of entity type (sub-
ject or object) The model is a non-layered one, we group similar rules in clusters .
The authorisation starts with event authorisation (EA) cluster with rules:

1 AAA — Authentication, Authorization and Accounting, an Internet standard technology for
access control