Example

Using the simple domain action presented in Figure 4.2 and the problem instance pro- vided in Figure 4.3, the LPG algorithm will generate a plan solution as shown in Fig- ure 4.4. Although the plan is quite simple, it describes the plan generation process. The objects correspond to the parameter list of the domain action and describe the information that is required to perform the proposed operation. The plans shows that a user account IE8SAAD$ was created in a network by another account Administrators. The Administrators account performed the process with ‘SeTcbPrivilege’ permission, which means it had system-wide authorisation to access any resource.

There is a possibility of multiple actions having same a precondition but different effects. In that case, the action with highest accumulative-weight value will be included in the plan and the rest of them will be discarded. Still, if the accumulative-weight is identical as well in such actions, the LPG planner will employ the heuristic function to choose the action that, in later stages of planning, will maximise the overall accumulative-weight value.

It should also be noticed here that the plan solution includes only those actions from the domain model, which were selected by the planner based on matching the initial state of the problem instance. The matched initial state of a plan describes the security con- cerns or some missing configurations, while the remaining part manifests the mitigation actions. As the routine/meaningless events are filtered in early stages of creating TAC rules and assuming the domain model comprises of relevant and sufficient knowledge, the actions in a plan can perform one of the following tasks: (1) recognise pattern of a security issue and (2) identify a security issue and propose a method to resolve it as well. It is also possible that the plan delivers partial information; however, it would still provide useful insight to some extent for the non-experts. Furthermore, the objects of each action in a plan play an important role in conveying the desired level of information as they belong to the vulnerable machine.

4.4

Chapter Summary

This chapter describes the representation and utilisation of knowledge acquired as the TAC rules. This chapter begins by describing the conceptual model of classical planning along with general assumptions. After that, it explains the process of knowledge rep- resentation and domain modelling. The chapter also presents an overview of common domain representation languages.

The representation of TAC rules is performed in two fully automated steps: (1) encoding the rules into a PDDL domain action model and (2) converting event log entries of a given vulnerable machine into a PDDL problem instance. After that, the domain model and problem instance are used as input for the LPG planner to search a plan solution in reasonable time. The plan is complete and sub-optimal, and it proposes the sequences of actions that can provide security assessment and configuration steps relevant to the vulnerable machine.

As mentioned before, the AP techniques have been successfully used to conduct pene- tration testing on systems and networks. The application of AP is also integral in our research as it provides several benefits, which are provided in the following list:

1. AP algorithms provide a fully automated and systematised deliberation mecha- nisms to replicate the human expert actions;

2. The parameters and accumulative-weight values of domain actions enabled the modelling of additional information specified in the TAC rule;

3. Objects in the actions of a plan belong to the underlying machine, hence providing usable and relevant results for non-experts;

4. Ability to generate an optimal plan based on a metric, ensuring that actions with the maximum accumulative-weight values are chosen to output the best results against a given situation; and

5. The knowledge is presented in a standardised format and can be utilised by any PDDL supporting planner, and thus distributing a benchmark domain model for the AP community.

Implementation and Evaluation

This chapter provides the details of proof-of-concept implementation along with the evaluation process of the solution proposed in this research. The implementation in- cludes the explanation of complete software development process, which is supported by figures and and other visual aids for evidence and better understanding of the reader. The software application is based on the theoretical foundation of the proposed solu- tion, which is provided in the previous chapters. After building the application, it is evaluated against the security expert knowledge to determine the quality, accuracy and validity of the underlying concepts. This is based on the empirical analysis of evaluation data and further includes performance and scalability comparison with manual security assessment and configuration procedures. This chapter also discusses the limitations and bottlenecks of the developed application in terms of live operation, environment and usage.

5.1

Implementation

This section presents the specific details of software requirements, design and imple- mentation of the proposed solution. Various aspects were considered during the design and development stages of the solution, such as ease of usability for all users having different technical knowledge, robust and suitable programming languages, clear and precise format of input/output, error and exception handling, and higher flexibility. It is important to use a structured approach to build the proposed solution as any logical

error/bug in the application will lead to the incorrect output, and negatively impact the quantity and quality of final results.