Deriving PVA models from PRM files

4.3.1

Design considerations

The

iEaat

files from the previous section contain both an object model and the CySeMoL class model. This separates the definition of network components from the definition of instances of these components. In our own models, we also maintain this separation wherever possible. In this section, we will discuss the transformation to the PVA model, and we will explain the transformation to the PVAI model in section 4.4.

PVA Concrete Types Templates Virtual Connections Asset instances Defence

instances AttackStepinstances Special relations P²AMF

operations

Concrete

Connections DefendedBy AttackStepTarget AttackStep order AttackStep

isAccessible isFunctioningDefence

Figure 4.1: A graph representing the construction dependencies of the PVA model. The arrows indicate a dependency on the existence of another object.

4.3.2

Derivation order

In order to construct our PVA model instances, we will need to extract the relevant data (i.e. the class model) from the

PRM

files contained in the

iEaat

files. For the implementation details on how we achieve this, see section 5.3. The result of our efforts with regard to the parsing of

iEaat

files, is that we end up with a Java object representation of the class model of CySeMoL. Using the code-generation feature from EMF, we first generate (Java) classes conforming to our PVA model. During the transformation from a PRM file, we use these classes to construct a PVA model in-memory. Afterwards, serialize the resulting PVA model using XMI (see section 2.5.4), and pass the serialized model to the next transformation stage.

We have implemented a program in Kotlin(see also section 5.1) which constructs a PVA model from the CySeMoL class model by using the aforementioned generated EMF classes. Due to the design of the PVA model, there are some difficulties in the transitive creation dependencies, that is, the creation order of valid objects is complicated by dependencies in their relations. For this reason, we opt to create partial objects during runtime, which are completed when applicable. We determine the creation order in such a way that, when a reference is required, the corresponding object (which might be incomplete)can always be identified. The construction dependencies are as shown in figure 4.1.

From these construction dependencies we derived the following order suitable for the construc- tion of PVA models:

1. The model container

2. Concrete Types

(i) Assets (ii) Defences (iii) Attack steps

(iv) Concrete connections

3. Templates

(i) Template definitions (ii) Type instantiations (iii) Internal connections (iv) External connections

4. Special relations

(i)

AttackSteps.target

relation (ii)

Asset.defendedBy

relation (iii) Attack step dependencies

5. P2AMF operations

(i)

AttackStep.isAccessible

(ii)

Defense.isFunctioning

6. Virtual connections

The data for the components is derived from the

PRM

, by traversing the class model it contains. In section 5.3 we will go into detail on this process, and will show the specific parts of the

PRM

where the data for our PVA model elements is obtained. The end result of applying the construction ordering is a complete and valid PVA model.

4.3.3

Parsing P

2

_{AMF code}

In this section, we will discuss how we derive the P2AMF code for the P2AMF operations stored in the PRM. These operations are stored in the PRM as strings, which are parsed during our transformation to the PVA model. By analysing the structure of the P2AMF code of CySeMoL, we noticed that the most code blocks follow a common pattern. For this reason, we have developed a parser for the P2AMF code in CySeMoL using the ANTLR4 parser generator engine (for more details on parser generators and ANTLR, see section 2.8).

The code blocks which our parser targets are:

• The

AttackStep.isAccessible

operations. • The

AttackStep.getPaths

operations. • The

Defense.isFunctioning

operations.

XMIObject ObjectModelObject id : ELong name : EString metaConceptId : ELong metaConcept : EString template : EBoolean = true

Association metaConcept : EString metaConceptId : ELong id : ELong Evidence metaConceptId : ELong metaConcept : EString evidence : EBoolean = false

[0..*] objects [0..*] associations

[0..*] evidenceAttributes

[1..1] parentObject [1..1] childObject

Figure 4.2: The derived structure of the

EOM

model. Displayed as an Ecore class diagram.

These code blocks are all written within the scope of the containing instance. For example, the code in

PhysicalAccess.isAccessible

is written from the scope of an instance of the

PhysicalAccess

class. For derived edges, the scope of the ‘owner’ of the relation is used. Given that all relations used in CySeMoL are bi-directional, this scope seems to be irrelevant. However, in the case of derived relations, the scope of the program remains unchanged when the relations are referenced by the ‘child’. In this case, when resolving derived edges, the owner of a bidirectional edge is likely to be relevant. In practice, the navigation path specified by the P2_{AMF code of these}

relations must be resolved in both the normal and reverse directions.

For our approach, to the parsing of the aforementioned P2AMF scripts, we have developed a set of three parsers. We have constructed one large parser which is able to parse the

isAccessible

and

isFunctioning

methods, and two smaller specialized parsers which each are able to parse one of the other two P2AMF code sources.

In document Vulnerability analysis of cyber security modelling language models using probabilistic logic (Page 52-55)