Problem Instances

Problem instances are automatically constructed using a given domain action model and the event log entries of a vulnerable machine. A problem instance contains the following components: objects, initial state, goal state and an optimisation metric. The reason behind using the domain model is to ensures that the object types and initial state of a problem instance are restricted to the types and predicates of the domain model, thus avoiding any execution errors during the planning.

(define (domain EventRelations--1) (:requirements :typing :fluents)

(:types DisplayName HomeDirectory HomePath ObjectServer PasswordLastSet · · · TargetDomainName TargetSid TargetUserName UserWorkstations) (:predicates (e 4720 ?DisplayName - DisplayName · · · ?UserWorkstations - UserWorkstations) (e 4673 ?ObjectServer - ObjectServer · · · ?SubjectUserSid - SubjectUserSid) ) (:functions (accumulative-weight) ) (:action e 4720-to-e 4673

:parameters (?DisplayName - DisplayName · · · · · · ?UserWorkstations - UserWorkstations)

:precondition (and (e 4720 ?DisplayName - DisplayName · · · · · · ?UserWorkstations - UserWorkstations))

:effect (and (increase (accumulative-weight) 101) (not (e 4720 ?DisplayName - DisplayName · · ·

· · · ?UserWorkstations - UserWorkstations)) (e 4673 ?ObjectServer - ObjectServer · · ·

· · · ?SubjectUserSid - SubjectUserSid)) )

)

Figure 4.2: An example of PDDL action, which is created from the temporal- association-causal relationship of two events. It also shows the relevant objects/pa-

rameters and an accumulative-weight value.

4.3.3.1 Problem Name And Objects

The problem instance is formatted as {Problem–<Domain name>}, e.g. Problem- EventRelations–1. Using object or property name-value pairs of the event entries, values will be used as objects, whereas the respective names will be assigned as types. Defining types improves the quality of domain model as it categorises the objects of problem in- stance. The planning algorithm uses these objects as constant arguments to the domain actions. This is quite beneficial for the non-experts as these objects will be involved in carrying out the security-related actions.

4.3.3.2 Initial State

The initial state models the current state of a vulnerable machine by using its security event logs. It is a set of predicates, whose variable parameters are initialised/replaced

with the corresponding objects or constants. Such predicates are known as grounded predicates. Each predicate represents a unique event type of a vulnerable machine. Only those predicates are included in the initial state, which also occur in the domain action model. In other words, all predicates of the initial state are also found in the domain model. The order of predicates (or events) is not important as they are considered as a collection in the initial state.

4.3.3.3 Goal State And Optimisation Metric

Defining a goal state in this particular case is a challenging task. First of all, we cannot determine or even predict beforehand what actions need to be scheduled. Secondly, there is no way of finding the set of one or all missing configurations in the target machine. Several scenarios can be speculated at this stage. Let us consider a scenario where a new predicate, say Goal-reached, is introduced. This predicate becomes part of every action’s effect in the domain model as well as a goal state. Doing so will not work because as soon as the planner finds a single action with respect to the initial state, it would have reached goal and the planning process will be terminated. Again, consider a similar scenario where each domain action is assigned its own unique predicate, for example Goal-reached-1, Goal-reached-2, · · · , Goal-reached-N. All these predicates form a goal state. This is not an acceptable solution as the planner would never reach the goal unless every single action is found to be included in the plan solution.

Considering the aforementioned discussion, the goal state is kept empty. Also, a max- imisation plan metric is applied in the problem instance to obtain the complete set of actions or those with the highest accumulative-weight value in the specified planning time. As the PDDL does not allow more than one metrics in a single problem instance, we have used the sum of counter, temporal-association accuracy and causal rank as an accumulative-weight. A combination of empty goal state and maximisation metric enables the planning algorithm to explore all possibilities with respect to initial state and find a quality solution. The planning algorithm will seek for the maximum total accumulative-weight value of a plan, which is the sum of accumulative-weight of each chosen action. In other words, the planning algorithm will choose the maximum number of actions that have relatively higher accumulative values, hence finding an accurate and complete plan solution for a given problem.

(define (problem Problem-EventRelations--1) (:domain EventRelations--1) (:objects Test1 - DisplayName NULL - HomeDirectory NULL - HomePath DS - ObjectServer O 1794 - PasswordLastSet SeTcbPrivilege - PrivilegeList 0x238 - ProcessId C:\Windows\System32\lsass.exe - ProcessName NULL - ProfilePath test1@local - SamAccountName NULL - ScriptPath WORKGROUP - SubjectDomainName O 0x3e7 O 0x105f5 - SubjectLogonId IE8SAAD$ IEUser1 - SubjectUserName S 1 5 18 S 1 5 19 - SubjectUserSid IE8Win7 - TargetDomainName S 1 5 32 - TargetSid Administrators - TargetUserName NULL - UserWorkstations ) (:init (= (accumulative-weight) 0)

(e 4720 Test1, NULL, NULL, O 1794, NULL, test1@local, NULL, WORKGROUP, O 0x105f5, IE8SAAD$, S 1 5 18, IE8Win7, S 1 5 32, Administrators, NULL)

. . .

(:goal (and ) )

(:metric maximize (accumulative-weight)) )

Figure 4.3: An example of problem instance generated automatically from a machine that has poor security configurations

4.3.3.4 Problem Instance Example

A problem instance from a live system is presented in Figure4.3. It was extracted from a machine having poor security configurations. Every object is assigned to a type, for example, Test1 - DisplayName represents an object Test1, which is of DisplayName type. Same goes for the WORKGROUP - SubjectDomainName, where domain name of underlying subject is WORKGOUP. The initial state is comprised of the grounded predicates, and the goal is not explicitly specified. The accumulative-weight value is initialised with zero and will be incremented (to maximum extent) according to the execution of domain actions.