We require that the configuration discovery of virtualized infrastructures contains all elements that might solicit or prevent information flow (cf. Section 3.3.1). Further, we require that the translation modules of
concrete systems are capable to correctly translate configuration elements to vertices and edges in the realization model (cf. Section 3.3.2).
In order to analyze our discovery and translation, we consider the following fault cases where the produced graph model differs from the actual virtualized infrastructure topology.
• Extra Vertex: The produced graph model contains a vertex that does not correspond to an element in the actual virtualized infrastructure of the mapped type.
• Missing Vertex: An element in the actual infrastructure is not represented by a vertex in the graph model of the corresponding type.
• Extra Edge: An edge is produced that does not represent an actual relation in the infrastructure topology.
• Missing Edge: An edge is missing in the graph model and does not represent a relation of the infrastructure topology.
• Incorrect Vertex Attribute: A vertex attribute can have a wrong value, where the attribute values of the model and the configuration differ. An attribute could not be set, although the attribute is present in the actual configuration. The attribute is set in the model, but not present in the actual infrastructure.
In general, the impact of the fault cases on the detection rates of our analysis is the following. An extra vertex without any additional edges has no impact on the analysis, since graph coloring requires an edge for color propagation. An extra edge may increase the false positive rate, because an additional path of color propagation can be established with the extra edge. However, an extra edge does not increase the false negative rate, because an extra edge cannot remove an existing color propagation path.
The combination of an extra vertex with a modified edge set can lead to an increase in false negatives, for instance, for the following example where the extra vertex becomes an intermediate node. The correct graph model looks like: A C but an intermediate node B has been created due to a faulty discovery
or translation: A B C . This intermediate node may now also increase the false negative rate,
because color propagation can be stopped at B but would have propagated between A and C directly. It is important that the direct edge between A and C has been removed, which therefore also blends in the missing edge fault case.
Missing elements can increase the false negative rate if a follow rule is not applied due to missing elements, or false positives if a stop rule is not applied. Incorrect vertex attributes can affect the predicate outcome of traversal rules. Depending on the traversal decision of an affected rule (stop or follow) this can increase the false negative (follow rule) or false positive (stop rule) rate.
Fault Analysis of Discovery
Our discovery needs to mitigate the defined faults in order to not impact the detection rate of our analysis. The essential properties of our discovery are: i) complete and unmodified view of the configuration by the management system or hypervisor, and ii) complete configuration extraction.
The configuration view provided by the management hosts or hypervisors is critical for our discovery phase. We assume that the software on the configuration endpoints, i.e, the management host or hypervisor, is correct and reflects the actual state of virtualized infrastructure configuration. We assume that the software has not been compromised, which could result in a modified or incomplete view of the configuration. In addition the communication channel between the configuration endpoint and our discovery software needs to be authenticated and integrity protected. Otherwise the configuration view could be modified on the network level or provided by a malicious configuration endpoint. In practice, the trusted communication channel is realized with either HTTPS and server certificate verification, or SSH and host key verification.
In order to ensure a complete extraction, our framework needs to know all the existing management hosts and hypervisors from which to extract their configuration. This must be provided by the administrator. The configuration endpoints typically have access control policies in place and our discovery requires read-only access to the entire configuration. Otherwise, we may not obtain a complete configuration view. Configuration extraction method by our discovery is to unconditionally extract the entire configuration and only in the translation phase explicitly ignore configuration elements. In the case of API-based discovery probes, we perform a complete iteration over the configuration elements (cf. Section 3.5.1 for VMware). We iterate over all elements and serialize them into XML without any further processing or modifications by the discovery probe. In the case of SSH-based probes, we either execute commands that already return XML, such as for libvirt, and which do not require further processing. Otherwise, we execute commands and parse their output, for instance for pSeries. The command output parsing will provide warnings in case of parsing errors and does not silently ignore those errors, which could result in an incomplete or incorrect configuration extraction. Furthermore, the command output is typically in a delimiter-separated format that can be parsed robustly.
A complete view by the configuration endpoint and an unconditional and complete configuration extract ensures that the configuration output is not missing elements and mitigates the faults of missing ver- tex/edge. The discovery does not create new configuration elements while performing the configuration extraction, therefore no extra vertex nor extra edge faults. We minimize the processing of configuration output in order to mitigate the problem of incorrect vertex attributes.
Fault Analysis of Translation
The translation phase is building up on the complete and unmodified configuration output from the discovery phase as discussed earlier.
We assume we have a correct meta model that defines the vertex types and the type relations. In a practical implementation, we can use a statically typed language, such as Java or Scala in our case, that allows us to define the vertex types and their required vertex attributes, including modeling relations as attributes. Proving the correctness of the meta model itself is not feasible, but the meta model has been developed based on domain knowledge of virtualized infrastructure configurations, analyzing the configuration output of different systems and identifying common elements, and evaluating and evolving the meta model in case studies.
The translation needs to iterate over all the configuration elements and either map them to vertex types and their attributes in the model or explicitly ignore them, because an element is not relevant for our analysis and not represented in the meta model. All other configurations elements that have not been mapped nor explicitly ignored will generate a warning, because this could lead to a potentially missing vertex in the graph model. The mapping from configuration element to vertex type is a simple one-to-one mapping, e.g., a VMware VM object is mapped to a VM type in the graph model. When a configuration element has been mapped to a vertex type in the meta model, the translation will instantiate a new vertex of this type. The required attributes of the vertex are populated with the values from the corresponding attributes in the configuration element with minimal amount of processing. Enforcing the population of required vertex attributes mitigates the fault of unset vertex attributes.
Relations are either represented in the configuration output as explicit relations with an internal identifier to another configuration element or as nested configuration elements. We translate those cases explicitly into edges in our graph model. In a translation of a configuration element with internal identifier relation, both the current element and the target element of the relation are translated. An edge is then created between the two vertices. In the case of nested configuration elements, we perform a recursive translation on the nested elements and create edges between a vertex and the produced vertices of the recursive translation.