11
Developing Model‐Based Cyber Modeling and Simulation Frameworks

While logical ranges provide the means for emulating systems of interest, M&S frameworks are still a necessary ingredient to provide the scale and scope to model contemporary cyber systems. Prescriptive approaches (Leversage and Byres 2007), for example, represent a system’s specific behavior, and use process models, embodied in more detailed component‐level descriptions (e.g. SysML), for more granular cyber system analysis. These structured approaches provide the “bottom up” behavioral rigor that composes cyber M&S frameworks.

11.1 Background

As early as 2001, the Modeling and Simulation Information Analysis Center (MSIAC) wrote a State of the Art Report (SOAR) (Waag et al. 2001) on Information Assurance (IA) to describe “cyber.” Since then, we have seen IA transition from DIACAP to the current Risk Management Framework (RMF); each risk framework spanning the “bow‐tie” with varying terms, depending on the domain that the risk evaluation approach was developed for. RMF, the current standard, is a flexible approach, that can be complemented by cyber M&S’ dynamics to provide system‐level analysis, such as attack surface estimation and operating metrics (e.g. Availability, Confidentiality, and Integrity).

11.2 Model‐Based Systems Engineering (MBSE) and System of Systems Description (Data Centric)

MBSE is evolving from the software development community, currently being used for overall systems development. The Object Management Group’s Systems Modeling Language (SysML) (Object Management Group [OMG] 2012), leveraging UML concepts, is an example of this extension from software to systems engineering (Figure 11.1).

Diagram displaying 2 overlapping circles labeled UML 2 and SysML. Area between UML 2 and SysML is labeled UML reused by SysML UML4SysML while other areas are labeled not required by SysML and SysML’s extensions to UML.

Figure 11.1 UML 2 and SysML.

SysML’s top‐down approach provides the Chief Engineer with a process to determine essential elements of data to support an assessment or decision (Estefan 2008). In addition, SysML’s extensions of UML result in a broadly applicable systems level tool; for example, SysML diagram types shown in Figure 11.2.

Tree diagram of SysML diagram branches to behavior diagram (branches to use case diagram, activity diagram, etc.), requirement diagram, and structure diagram (branches to package diagram, parametric diagram, etc.).

Figure 11.2 SysML diagram types.

In addition, SysML is intended to be compatible with the evolving ISO 10303‐233 (Valilai and Houshmand 2009) systems engineering data interchange standard. Figure 11.2 provides an overview of existing systems engineering process standards and capability models.

11.3 Knowledge‐Based Systems Engineering (KBSE) for Cyber Simulation

Knowledge‐Based Systems Engineering (KBSE) provides a data‐based approach for developing sophisticated training and simulation systems (Figure 11.3).

Flow diagram of legacy simulation‐based acquisition development approach, from data, model, and computer-aided design, engineering, and manufacture leading to distributed simulation-based acquisition.

Figure 11.3 Legacy simulation‐based acquisition development approach.

As shown in Figure 11.3, original concepts for simulation‐based acquisition included leveraging computer‐aided design (CAD) information, data at a level of modern KBSE. Combining KBSE with the behavioral simulation common to agent‐based modeling has the potential for a comprehensive approach to cyber M&S.

11.3.1 DHS and SysML Modeling for Buildings (CEPHEID VARIABLE)

While DHS is known for its ICS‐CERT’s Cybersecurity Evaluation Tool (CSET®) for onsite assessments, network design architecture reviews, and network traffic analysis and verification, an additional development that we are seeing is the evolution of overall frameworks for cyber strategy formulation, leveraging threat behavior models for enterprise risk evaluation. An example of this more detailed modeling approach was a Small Business Innovative Research (SBIR) funded Cyber‐to‐Physical Domain Mapping Toolkit for Vulnerability Analysis and Critical Resource Identification Enablement (CEPHEID VARIABLE). Built by Knowledge Based Systems, Inc. (KBSI) (Small Business Innovative Research [SBIR] 2012), the goal of CEPHEID VARIABLE is to enable IT managers to perform vulnerability assessment of cyber–physical systems in an application framework that enables the acquisition, representation, storage, mapping, vulnerability, and dependency analysis of information linking cyber and physical resources; supporting both static and dynamic vulnerability analysis. This includes a leveraging of available, and evolving, NIST threat representations (Chapter 2, Table 2.1). As discussed in Chapter 8, cyber M&S includes requirements gathering, the use of constructive simulation, and the leveraging of this knowledge for analyst and operator training.

11.3.2 The Cyber Security Modeling Language (CySeMoL)

The Cyber Security Modeling Language (CySeMoL) (Sommestad 2013) is a modeling language for enterprise‐level system architectures that uses a probabilistic inference engine. Modeling the enterprise computer systems with CySeMoL allows the inference engine to assess the success probability of candidate system attacks. A compilation of security domain research results, covering a range of attacks and countermeasures, was used to compose the corpus of CySeMoL attack–probability calculations.

11.3.3 Cyber Attack Modeling and Impact Assessment Component (CAMIAC)

Leveraging a uniform system description results in a reproducible framework for cyberattack modeling and impact assessment. A common approach to attack modeling and impact assessment is based on representing malefactors’ behavior, generating attack graphs, calculating security metrics, and providing risk analysis procedures. The architecture of the Cyber Attack Modeling and Impact Assessment Component (CAMIAC) is proposed in (Kotenko and Chechulin 2013).

As shown in Figure 11.4, the CAMIAC authors present the prototype of the component, the results of experiments carried out, and comparative analysis of the techniques used.

Diagram of CAMIAC prototype architecture consisting internet (external databases), data repository updater, application server, specification generator, network sensors, GUI, database server, etc.

Figure 11.4 CAMIAC prototype architecture.

11.4 Architecture ‐Based Cyber System Optimization Framework

Modeling real cyber phenomena usually requires some level of abstraction (e.g. two player games, agents, etc.). MITRE’s Collaborative Research Into Threats (CRITS) (Figure 11.5) provides an enterprise‐level capability to “simulate” incidents over associated COAs and adversary TTPs.

Diagram displaying arrows labeled incident analysis from CRITS to analysis cell, incident response (CyCS) from analysis cell to mission execution, and playbook training (indicator) from CRITS to TARA playbook.

Figure 11.5 Federated Analysis of Cyber Threats (FACT) (MITRE 2015).

Expanding on CRITS, Musman developed the Cyber Security Game (CSG) (Musman and Temin 2017), an approach and supporting software that quantitatively identifies cybersecurity risks and uses this metric to determine the optimal employment of security methods for any given investment level. CSG maximizes a system’s ability to operate in today’s contested cyber environment by minimizing its mission risk, where its risk measure is the inverse of its cyber resilience.

11.5 Conclusions

Contemporary modeling spans from data structuring (e.g. UML, MBSE, SySML…) to overall descriptive approaches (e.g. CySEMOL, CAMIAC), composing the foundation for a future of knowledge‐based design in cyber systems. As these frameworks evolve to provide the foundation for secure cyber system development, approaches will develop for model‐based systems to rapidly traverse potential state spaces, some of which may not have been explored by the designer, thereby providing increasingly secure and reliable cyber systems.

11.6 Questions

  1. 1 How does SysML compliment standard modeling approaches (e.g. Markov modeling, DEVS, Petri Nets, etc.)?
  2. 2 How is the “people” element included in SysML description?
  3. 3 What kind of state changes, within the enterprise system, should the cyber modeler expect to emulate, when developing a cyber system defense simulation?
  4. 4 What are the basic components of a Playbook in MITRE’s FACT?
  5. 5 How does a Playbook overlap with a COA in MITRE’s FACT?
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.117.183.172