The complex nature of cyber-physical systems like the smart
grid presents many security challenges. For example, subtle
weaknesses in the underlying IT-infrastructure (as well as in
computerized physical devices) can open entry points for malicious
intruders and enable attacks with serious and far-reaching
consequences (e.g., large-scale blackout). Our goal is to help
stakeholders make use of the diverse information (network diagrams,
device settings, known attacks, etc.) at their disposal to reason
about the security of their system.
To achieve this, we introduce the concept of workflow - describing how a system provides its intended functionality as a pillar of cybersecurity analysis. By focusing on the system's functional workflows, our framework can integrate heterogeneous information about system components, empirical data, and attacker models to quantitatively reason about security goals in a largely automated fashion.
A security assessment methodology should be rigorous, holistic, and scalable to large systems. Each of these objectives pose challenges (and tradeoffs) for researchers. Performance and reliability modeling frameworks may include rigorous mathematical underpinnings, but lack attacker models, and are difficult to apply for information properties like confidentiality. Conversely, many established attacker modeling frameworks from the security domain are not readily applicable to complex systems, since they lack workflow models to bridge the gap between IT infrastructure and other subsystems or actors. Most of the holistic approaches that exist today (e.g., assurance cases) are subjective in nature, and require a high level of human modeling effort. Such assessments may be constructed or interpreted differently by different security analysts, and do not scale well.
The crux of any security assessment is a logical argument for security properties of interest. In the literature, graph has already been used to describe safety arguments such as in Goal Structuring Notation. The appeal of graphs is their ease of visualization, especially in case of complicated security reasoning. It is thus natural to make use of graphs to assist security assessment.
A security argument graph is a graph whose vertices represent security goals (properties) and edges denote dependencies between those goals. We expect argument graphs to be directed and acyclic. A security goal i.e. security-related property of a system can be very general such as "a system component is available", "the communication between two devices is always confidential", etc.
For example, the following graph denotes the following relationships
We remark that vertices could contain additional information indicating what kind of dependency between it and its neighbors as in the case of our current implementation.
Due to its importance in security assessment, it is desirable to generate argument graph automatically from available information such as system configuration, knowledge of existing vulnerabilities, etc. We identify various argument patterns and formalize those patterns into argument graph expansion templates that can be applied repeatedly to "grow" a security argument graph. For example, one pattern we found is that whether a component such as a server is available depend on its relevant subcomponents (e.g. server machine, executing server process, etc.) being available. A closely related pattern is that availability of a component depend on the attacker's not being able to carry out relevant attacks.
From the (typically logical) relationships between security properties captured in argument graph, we can quantitatively evaluate them.
The simplest reasoning model is perhaps Boolean logic where each property is assigned a true/false value. Aggregation is performed using Boolean evaluation. In this case, we need each node in the argument graph to provide a logical formula indicating its relationship with its neighbors.
A more interesting evaluation method is probabilistic reasoning via Bayes' theorem. Here, we want to assign each node in the graph a probability indicating its likelihood to be true. Evidently, the values need to be consistent with the dependency between the nodes. For simplicity, our tool makes the assumption that leaf properties are independent. This allows us to estimate likelihood of security properties of interest such as availability of the system service from probability of disparate events such as a successful attacks or system overload.