Domain Modelling

Consider an example of TAC rule presented in Table 4.1. This information is used to produce a domain action. It shows a cause and effect relationship between two events 4720 and 4673. The event type 4720 means that a new user account was created, whereas 4732 informs that the account was created by using administrative permissions. The object names and other information given in the rule are imperative for the planning

Rule property Value Cause

event

Type: 4720

Object names: DisplayName, HomeDirectory, HomePath, Pass- wordLastSet, ProfilePath, SamAccountName, ScriptPath, Sub- jectDomainName, SubjectLogonId, SubjectUserName, Subjec-

tUserSid, TargetDomainName, TargetSid, TargetUserName,

UserWorkstations Effect

event

Type: 4673

Object names: ObjectServer, PrivilegeList, ProcessId, Process- Name, SubjectDomainName, SubjectLogonId, SubjectUserName, SubjectUserSid Counter 3 Temporal- association accuracy 95 Causal rank 3

Table 4.1: An example of TAC rule for generating a PDDL domain action

algorithm to generate a quality plan of actions, which will consequently provide the non-experts with an actionable knowledge. The remaining section will use the example TAC rule to demonstrate the domain modelling process.

In this research, we encode the TAC rules and output a PDDL domain model file. A domain model consists of types of objects, predicates modelling facts, functions to handle numerical operations and actions. The objects and predicates are used to model the underlying system and an action represents an evaluation or configuration step to increase the security. A precondition depicts at what point the action is selectable with respect to a problem, and an effect models a change to the objects, predicates and functions, and is a step towards achieving desired goal. The cause becomes the precondition, whilst, the effect event of a rule becomes the effect part of an action. This is due to the reason that cause lead to the effect event and they are also ordered through temporal metric.

4.3.2.1 Domain Name, Requirements And Types

The domain name is formatted as {EventRelations–<Number>}, e.g. EventRelations– 1. The domain model uses ‘typing’ and ‘fluents’ requirements. All unique object names of cause and effect events in a TAC rule are encoded as variable names and types. While the objects describe the entities involved in the occurrence of an event, defining

variables with types will also inform the particular entities required to perform the do- main action. All variables that are used in the domain model have types, hence the need for typing requirement. Using the example, a typed variable would be ‘?Display- Name - DisplayName’. Furthermore, every TAC rule has three numeric values: counter, temporal-association accuracy and causal rank. The representation of these numeric constraints in the PDDL domain model needs fluent requirement.

4.3.2.2 Predicates

The predicates represent the set of unique events found in the TAC rules. A pred- icate is a combination of event type and its corresponding parameter list. It is for- matted as ‘(e <EventType> TYPED-PARAMETER-LIST)’. Using the example TAC rule, ‘(e 4720 ?DisplayName - DisplayName ?HomeDirectory - HomeDirectory · · · ?User- Workstations - UserWorkstations)’ is a predicate to model event type 4720. Notice that the variables and types have same names, except the variables starts with question mark symbol (‘?’).

4.3.2.3 Functions

A function or numeric fluent is way of storing numeric values in the domains actions, initial state and goal state, and the values are accessible during the execution of planning algorithm. A function named accumulative-weight is used in the domain model to hold the amount of confidence or importance of every modelled rule. This function is increased upon the selection of underlying action by a value that is the sum of counter, temporal-association accuracy and causal rank values of the rule. Using the example, the TAC rule (4720 → 4673) has a sum of 3 + 95 + 3 = 101.

4.3.2.4 Actions

The actions are responsible for changing the current state of the world. In our research, the cause and effect relationship between events in the TAC rules is represented as a action, and there are same number of domain actions as there are number of rules in the database. An action has four components: name, parameters, precondition and effect. The name of an action is formatted as {e <Cause event>-to-e <Effect event>}, e.g.

e 4720-to-e 4673. The combined list of unique object names from both cause and effect of a TAC rule constitutes as a parameter list. Each domain action encodes all objects (in the form of one or more parameters) that are required to make any configuration change in the underlying system.

The precondition and effect are always written as and /or conjunctions. The precondi- tion is composed of a single predicate that models the cause event, whereas the effect part represents the effect event of a TAC rule, as well as the accumulative-weight function that assigns a cost/confidence value to the action. A negative predicate is also placed in the effect that prevents the consecutive selection of the same actions, involving the same objects. It is false (void or inapplicable) before the action selection and means that the given arguments have not been processed yet, and consequently marked true to depict that the same arguments cannot be executed again. Note that the negative predicate would not limit the repetition of actions in a plan. It would just prevent successive re- dundancy that can occur due to absence of goal state and use of maximisation metric in a problem instance (explained in Section4.3.3.3). So the planning algorithm would not allow the duplication of the same set of actions to forge a maximum accumulative-weight value, and only generate a precise plan of actions.

4.3.2.5 Domain Model Example

Continuing the example, a complete domain action model of the TAC rule is provided in Figure 4.2. The event types 4720 and 4673 have some objects in common, e.g. ‘SubjectDomainName’ and ‘SubjectUserName’. Such duplicate objects will be removed for the parameter list.