Cybersecurity and Systems Engineering

Cybersecurity inherently involves diverse computer systems, human processes, varying operating systems, and other systems involved in cybersecurity. Cybersecurity could appropriately be labeled a system of systems; therefore, systems engineering is the appropriate template for cybersecurity engineering. One of the proposals in this chapter is that cybersecurity be formalized as a subdiscipline of systems engineering.

Before cybersecurity engineering can be defined as a subdiscipline of systems engineering, it is critical to first establish a clear understanding of what systems engineering is. The International Council on Systems Engineering (INCOSE) defines systems engineering as follows:

Systems Engineering is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem: Operations, Performance, Test, Manufacturing, Cost & Schedule, Training & Support, Disposal.

Systems engineering is, by definition, an interdisciplinary engineering discipline. It brings together diverse fields of engineering and includes project management activities. Systems engineering is concerned with a given system, or system of systems, throughout the system life cycle. This begins with the concept phase and continues through system disposal. This is an appropriate approach for cybersecurity engineering as well.

The first area to consider is requirements engineering, which is involves defining the requirements for the system to be developed. The process begins with an informal and often vague articulation of requirements as per the stakeholders and moves on to processing that information into specific and actionable system requirements. In cybersecurity, requirements engineering is a critical component that is often overlooked. Many cybersecurity projects are done simply because they meet minimum requirements for some regulatory requirement or because they are common cybersecurity tasks. Formalized requirements engineering is not a common occurrence in cybersecurity. This indicates that one benefit of formally defining cybersecurity engineering is that requirements engineering can then be integrated into cybersecurity projects.

Applying Engineering to Cybersecurity

While the engineering processes apply to all aspects of cybersecurity, it can be beneficial to consider a specific example to illustrate the application of requirements engineering. For that purpose, one can consider a penetration test. Currently penetration testing is often done in an ad hoc manner. In penetration testing, the requirements engineering process can be used to define the specific requirements for a particular penetration test. Client often have only vague ideas about what a penetration test is and about what they want to accomplish with pen testing.

The requirements engineering activities begin with requirements elicitation. This is a process wherein stakeholders and engineers meet to discuss requirements. As the name suggests, the engineers elicit requirements from the stakeholders. The requirements initially gathered are then analyzed. During the requirements analysis phase UML diagrams, SysML diagrams (which we will explore later in this chapter), user stories, and other techniques may be used to clarify the requirements. Often requirements analysis is then followed with system modeling. Modeling can be done with UML or SysML modeling, or tools such as MATLAB. The idea is to explore the requirements that have been gathered. Next the requirements are specified and validated.

In requirements engineering, the systems engineer uses techniques to elicit requirements from the client or other stakeholders. This is a process that can be readily tailored to cybersecurity engineering. As one example, this can be applied to penetration testing, a subset of cybersecurity. For penetration testing, requirements engineering can involve several techniques:

• Review past incidents the client organization has had and incidents that have occurred in the same industry. Extrapolate from those specific requirements and seek the client’s agreement on those requirements.

• Use-case diagrams are common in systems engineering. They provide a very easy to understand model that even a very nontechnical stakeholder can understand. Penetration testers can use misuse cases to model potential misuses of the client’s systems. These misuse cases can include insider threats, external attackers, and even accidental security violations. Misuse cases are described in detail later in this chapter, in the section “SecML.”

• Review specific requirements from relevant regulatory bodies and industry standards. Many standards, such as the Payment Card Industry Data Security Standard (PCI-DSS), define specific penetration testing requirements.

Once requirements have been gathered and approved by the stakeholder, those requirements should form the foundation of the penetration test. In systems engineering a bidirectional requirements matrix is a common tool for tracing requirements. For penetration testing, this will trace every requirement to at least one specific test that was conducted, and every single test should trace back to a specific requirement. This ensures that all requirements were met in the penetration test, and that all tests conducted were necessitated by one or more specific requirements. Figure 15.1 displays a simplified requirements matrix for a penetration test.

Clearly, an actual penetration test would have many more activities and requirements. But this figure demonstrates the usefulness of the requirements bidirectional traceability matrix when applied to penetration testing. The primary issue in this example is to integrate requirements engineering into the penetration test. The specific requirements will vary depending on the specific needs for that particular penetration test. The current issue is that existing cybersecurity curriculums do not include any systems engineering. Thus it is not uncommon to find cybersecurity professionals with no formal training in requirements engineering.

Once the requirements are established, it is necessary to plan the actual penetration test. Systems engineering provides several effective tools to aid in planning. One such tool is the Work Breakdown Structure (WBS). The WBS is a diagram that takes a large process and breaks it down into smaller, manageable pieces. This is useful for ensuring all tasks have been planned. It also breaks the project into smaller tasks to facilitate both scheduling and budgeting. A simplified Work Breakdown Structure for a single server is shown in Figure 15.2.

Simply by applying requirements engineering and a Work Breakdown Structure to a penetration test, one will achieve a more systematic and consistent test. This can improve efficacy of penetration testing as well as streamline efficiency. This cannot be accomplished, however, if the penetration tester is not educated on these fundamental concepts from systems engineering.

Beyond the particular example of planning and executing a penetration test is the broader issue of designing any security system. Such design principles apply to any security implementation such as deploying a new intrusion detection system (IDS), implementing new network policies, or developing a honey pot (decoy system). The current trend in cybersecurity is to perform tasks with minimal if any planning. This is another area wherein systems engineering can enhance cybersecurity.

As was previously discussed, elements from reliability engineering can also be applied to cybersecurity engineering. By integrating the established methodologies for measuring reliability, cybersecurity engineering has a ready-made set of metrics. At its core, reliability engineering is about risk management. And that is also the ultimate goal of cybersecurity.

Any integration of systems engineering with cybersecurity will have to integrate specific standards. The IEEE 15288 standard defines the system development life cycle. This same life cycle should be applied to developing security in any environment. Thus, when implementing a new intrusion detection system, or in implementing new network policies, one should follow the IEEE 15288 system development life cycle. That standard includes the following clauses:

• Clause 6.4.1—Stakeholder Requirements Definition Process

• Clause 6.4.2—Requirements Analysis Process

• Clause 6.4.3—Architectural Design Process

• Clause 6.4.4—Implementation Process

• Clause 6.4.5—Integration Process

• Clause 6.4.6—Verification Process

• Clause 6.4.7—Transition Process

• Clause 6.4.8—Validation Process

• Clause 6.4.9—Operation Process

• Clause 6.4.10—Maintenance Process

• Clause 6.4.11—Disposal Process

This defines the process for developing or acquiring any system, beginning with defining requirements. This process is commonly taught in introductory systems engineering courses but might be foreign to many cybersecurity practitioners. Understanding the system development life cycle is essential to development of any system, including cybersecurity systems.

Any cybersecurity system must begin with the requirements engineering process. One of the hallmarks of requirements engineering is requirements elicitation. This is a process whereby the engineer elicits requirements from stakeholders. The idea is that the stakeholders may not be aware of what can be done or what should be done. The engineer’s expertise is needed to elicit a set of requirements. This is particularly applicable to cybersecurity. It is very likely that the stakeholders are not well versed in cybersecurity and will not effectively arrive at a complete list of requirements, without some assistance from an engineer.

Another tool from systems engineering that can be of significant benefit in cybersecurity engineering is the use-case diagram. This was originally part of UML and is now incorporated into SysML. The use-case diagram shows a range of users, including other systems, and how they will interact with the system of interest. The details of the use case are expounded upon later in this chapter, in the section “SecML.” However, the simple concept of modeling how users interact with a system can be very useful in defining system functionality. It is also an effective tool for communicating with stakeholders during requirements elicitation.

Unified Modeling Language (UML) is a set of diagrams used to model software. These diagrams include use-case diagrams that show how the software will be used. UML also includes deployment diagrams describing how the software should be deployed. There are a total of 14 different UML diagrams. SysML (or Systems Modeling Language) is similar but applies to any system. There are 9 different SysML diagrams.

The tools discussed in this section are just a few of the techniques that systems engineering uses that can be effectively applied to cybersecurity in general and penetration testing in particular. It can be advantageous for any penetration tester to take a course in systems engineering. Educational institutions may wish to consider adding a systems engineering course to any existing cybersecurity curriculum. At a minimum, a cybersecurity engineer should at least become familiar with the INCOSE handbook.

The tools presented in this section are only a sample of the tools utilized in systems engineering. As important as the tools are the concepts of systems engineering. For example, system modeling and simulation is common in systems engineering, but not commonly done in cybersecurity. Defining cybersecurity engineering as a subdiscipline of systems engineering requires that modeling and simulation be included.

Modeling and simulation provide a useful mechanism for testing systems in a variety of scenarios. For example, if one is developing a system to counter denial of service (DoS) attacks, then it would be useful to simulate a DoS attack to determine how the system will respond. MATLAB is already widely used to model network traffic. It is therefore appropriate to utilize MATLAB to model network traffic-based attacks. However, this modeling is not common in cybersecurity. This is one example of the application of modeling and simulation to cybersecurity engineering.

MATLAB is a tool that is commonly used in systems engineering and in other engineering disciplines. This tool has been applied to a wide range of engineer disciplines, including aerospace engineering and bioengineering. This tool should be included in cybersecurity engineering as well. The versatility of this modeling trip makes it an effective tool in many diverse engineering disciplines.

Reliability analysis is another important component of systems engineering—and one that would be well applied to cybersecurity engineering. Reliability engineering and analysis is the process of determining how reliable a given system is. Often in cybersecurity, systems are implemented without knowledge of their reliability. Reliability engineering includes a number of techniques, and formulas for determining reliability.

One hallmark of all engineering disciplines is quantifiable data. It is necessary to have objective metrics in order to make informed decisions. Reliability engineering includes a number of formulas that can assist in acquiring such metrics. Fortunately, many of these do not require advanced mathematical knowledge.

The mean squared deviation formula is relatively simple and provides insight into how any system deviates from expectations. This formula is shown in Figure 15.3.

In this formula, y_i is the actual value (that is, how the system was supposed to perform), and T is the target value.

Adjusting the settings of controllable inputs allows one to alter the MSD. This is a relatively simple formula from reliability engineering that can be applied to the reliability of any cybersecurity system. This would be particularly useful in evaluating the efficacy of intrusion detection systems (IDSs) and antivirus software. The MSD formula could be coupled with modeling and simulation to fine tune the cybersecurity system before it is put into operation.

The MSD formula naturally leads to the MPE formula. The mean percentage error (MPE) is the mean number of errors from modeling. In other words, what is the mean error of the model versus actual values. This is critical in modeling as it can be used to evaluate the efficacy of the model itself. Figure 15.4 shows the MPE formula.

In this formula,

n is the number of different times for which the variable is forecast, a_t is the actual value of the quantity being forecast, and f,_t is the forecast.

In addition to useful formulas for cybersecurity engineering, reliability engineering involves concepts that are applicable to cybersecurity. For example, the concept of mean time between failures (MTBF) estimates the mean time before a component will fail. For an antivirus software solution this could be the mean time before a given file is misidentified as being a virus or not being a virus. The mean time between failures can be calculated as shown in Figure 15.5.

Now this formula does appear in some cybersecurity books (including this one) and is addressed in some certification courses. A more accurate explanation of the MTBF formula can be defined as the arithmetic mean value of the reliability function R(t), which can be expressed as the expected value of the density function f(t) of time until failure. This requires integral calculus, which is shown in Figure 15.6.

Don’t panic if this is new math to you. That symbol is the definite integral. I believe integration is often covered in Calculus II in many universities. Clearly the MTBF formula has a clear application to cybersecurity. Understanding when a device is expected to fail is useful information. This can first be a measure of the efficacy of a given cybersecurity device or component. It can also be useful in evaluating whether any system or subsystems failure is expected or not. Furthermore, an unexpected failure could indicate an attack. However, this also indicates the need for at least basic calculus as a part of a cybersecurity curriculum.

Another concept from reliability engineering is the mean time to repair (MTTR). That is another metric that actually is currently covered in many cybersecurity books and certification courses. Continuing with the example of an antivirus software suite, what is the mean time after a virus that is not interdicted, for a system to recover from the virus infection. This data would allow the cybersecurity engineer to objectively evaluate the cybersecurity system in question.

As outlined previously, cybersecurity engineering is appropriate viewed as a subdiscipline of systems engineering. By integrating elements from other domains within systems engineering, cybersecurity can be elevated to a true engineering discipline. This requires integration of reliability engineering and requirements engineering into cybersecurity. Furthermore, implementing robust and effective modeling techniques. The end result of these efforts is a formal cybersecurity engineering discipline. This engineering discipline is then well defined, and the professional requirements much clearer than the current state of the cybersecurity profession.

SecML Concepts

The general concept for Security Modeling Language (SecML) is to provide a modeling tool that can be used to effectively model both cyber-attack scenarios and defense postures. Given that cybersecurity involves systems of systems, it is appropriate to begin with SysML as a basis and modify that modeling language to formulate SecML.

Some of the diagram types are very similar to SysML diagrams with only slight modifications. Other diagram types were created explicitly for cybersecurity applications. Unlike UML, the language SysML is based on, the diagrams in SecML are not divided into categories such as structural, behavioral, or interaction. However, some clearly are oriented towards behavior or structure. It might seem advantageous to divide the diagrams into attack or defense-oriented diagrams; however, this was intentionally not done. Clearly diagram types such as the misuse-case diagram are appropriate for attack modeling. Similarly, the security block diagram (SBD) could be viewed as a defense-oriented diagram type. However, other diagrams such as the security sequence diagram are appropriate for both attack and defense. Therefore, the diagrams are not divided into attack and defense categories.

Misuse Case Diagram

The first SecML diagram, and the easiest to understand, is the misuse case diagram (MCD). Both SysML and UML utilize use-case diagrams in order to understand how users interact with a given system. Users also include other systems that might use a given system. For security purposes, the largest concern is on how an attacker might misuse a system. Therefore, it is logical to diagram misuse cases. The essence of an attack is misusing a system. Figure 15.7 shows a typical use-case diagram.

In the traditional use-case diagram, some relatively simple elements are utilized. The image that appears to be a stick figure is used to represent any user of the system. This can, of course, be a human user. However, another system can in fact be a user and will still be depicted with the stick figure. Activities that are done in the system are labeled ovals. The connection between a user and a system action is represented via a line. Furthermore, when one activity extends another, that relationship is demonstrated with the dotted line and the <<extends>> label.

The UML use-case diagram has been widely used to model specific uses of a system of interest. Its utility derives from the ease of understanding it. The diagram elements are self-evident, and easily understood. That is one reason why this particular UML diagram is useful in communicating with nontechnical stakeholders.

The concept of misuse cases already exists. However, the modification here is to have formal notation for the misuse. The logical starting point is the UML use-case diagram that is then modified to demonstrate misuses. This involves adding/modifying some symbolism. For the SecML misuse-case diagram, the notations shown in Figure 15.8 are added.

Figure 15.9 shows an exemplary use-case diagram. The diagram shows a normal user and an abuser misusing the system. It also shows which activities have some mitigation provided to address misuse and which do not yet have any mitigating factors.

The diagram can be enhanced with additional notation. For example, the indication of a counter measure could be further described, indicating what the counter measure is. A number is also indicated on the counter measure symbol indicating that there are multiple counter measures. The number of mitigating factors would be an integer inside the circle with the X, as illustrated in Figure 15.10.

Figure 15.9 would then be enhanced by explanatory notes about the countermeasures employed. For example, the countermeasures could be (1) Policy against downloading attachments and (2) antivirus to counter viruses sent from an abuser/attacker to a victim. The misuse-case diagram allows the cybersecurity engineer to model how the attacker would misuse the system, and what counter measures are currently in place. More importantly, by modeling all misuse cases, it will become obvious which attack vectors have adequate mitigation measures and which do not.

Figure 15.11 provides a specific example of a misuse case. This figure shows a normal, authorized user logging into the system. It also shows an abuser (that is, an attacker) sending an email with a malware attachment. It can be seen clearly how the abuser is misusing the normal process of sending email. It is also clear in this example that the abuser’s remote login is blocked by two mitigating factors, but there are not mitigating factors for sending email with malware attachments.

Obviously, Figure 15.11 presents a rather simplified example; however, it illustrates the utility of this diagram. It immediately clarifies the attack vectors an abuser might use. Furthermore, it becomes abundantly clear that there appears to be adequate mitigation for remote connections, but not for sending malicious emails. That lack of mitigation would also facilitate phishing campaigns. The concept is that misuse-case diagrams (MCDs) should be created for all attack vectors. This facilitates modeling and understanding those attacks, as well as selecting and applying mitigating countermeasures.

Security Sequence Diagram

In SysML a sequence diagram shows how objects interact over time. Specifically, sequence diagrams show how actions are related between objects. In a security context, this is of significant importance. In any attack scenario, the sequence of data flow from one object to another is critical to the analysis. This is also applicable for defense and mitigation strategies. Understanding how an intrusion detection system interacts with security information event management (SIEM) is relevant to modeling the security of any system of interest. It would be possible to utilize the sequence diagram as it exists in SysML without any modification for security purposes.

While the sequence diagram could be used without any modification for security purposes, slight modifications would improve its utility. Thus, SecML defines a minor modification to the sequence diagram named the security sequence diagram (SSD). In SecML the sequence diagram is used in in almost the same manner as it is in SysML. Figure 15.12 shows the current UML/SysML sequence diagram.

The sequence diagram demonstrates a sequence of actions; however, these models were meant to diagram intended activities, not attacks. To modify the sequence diagram involves adding/modifying some symbolism. For the SecML, the notation shown in Figure 15.13 is added to the security sequence diagram.

Traditional sequence diagrams do not differentiate between authorized and unauthorized actions. In fact, nothing in SysML even contemplates unauthorized activities. However, in cybersecurity, unauthorized actions are of critical importance. Figure 15.14 shows an exemplary modified sequence diagram.

As in a traditional SysML sequence diagram, the messages are still written with the message name above and the directionality of the message. However, the modification for SecML allows one to differentiate between normal operations and unauthorized actions. Seeing unauthorized and authorized actions as they actually occur in a system, provides a very effective understanding of system operations.

The modified sequence diagram provides an overview of the sequence of events in any cyber attack. This allows the cybersecurity engineer to model various attacks. Coupling the security sequence diagram with a misuse-case diagram provides an effective overview of the attack vector in question.

Data Interface Diagram

This diagram type is created specifically for SecML. The data interface diagram (DID) is used to provide the cybersecurity engineer an understanding of data flow in the system of interest. It models the flow of data into and out of any system. The concept is to look at any system or subsystem and diagram all interfaces for data to flow into and out of the system of interest. Any place that data can flow is an area for security concerns. Data flowing outward can lead to data exfiltration. Data flowing inward can lead to malware being introduced to the system. This is shown in Figure 15.15.

Figure 15.16 shows the specific elements of the data interface diagram.

This diagram is intentionally simple. The goal is to make the process one that cybersecurity engineers can efficiently use with minimal training required. The concept it to ensure that all data flow points have been identified, and that mitigation measures have been identified. This diagram is used to examine the system of interest and to determine what, if any mitigation strategies have been put into place for each data interface. This is essentially a limited interface diagram.

Security Block Diagram

Unified Modeling Language (UML), which was the basis for SysML, has a component diagram. In UML, component diagrams are used to identify components in software and to model how they connect. For example, UML contains assembly connectors that model a connection when one component requires another component. The delegation connector links an external component.

This section described the foundations of SecML, which is based on the preexisting SysML. It may be that further research leads to enhancements to these models, and the addition of new models to SecML. As with all modeling language, it is expected that SecML will be revised and expanded.

Multiple Choice Questions

1. What type of diagram is used to show how any entity might interact with a system?

A. Use-case diagram

B. Sequence diagram

C. Data interface diagram

D. Requirements diagram

2. What is the most appropriate tool for capturing the requirements of any security process or system?

A. Use-case diagram

B. Sequence diagram

C. SysML

D. Traceability matrix

3. Which of the following cybersecurity activities would be most accurately described as engineering?

A. Implementing complex IPS rules

B. Implementing asymmetric cryptography

C. Creating a requirements traceability matrix

D. Conducting a forensic investigation

4. Which modeling language is used by systems engineers?

A. SecML

B. SysML

C. UML

D. DML

5. What does this symbol represent in SecML?

A. A forbidden action

B. A blocked system

C. A countermeasure

D. An attack

6. What does this symbol represent in SecML?

A. Attack victim

B. System abuser

C. System user

D. Isolated user

7. What does this system represent in SecML?

A. Blocked activity

B. External attack

C. Unauthorized activity

D. Internal attack

Exercises

Exercise 15.1: Misuse-Case Diagram

Create a misuse-case diagram for a specific type of attack. You can choose any attack described in this book.

Exercise 15.2: Requirements Gathering

Consider the cybersecurity requirements of a college campus. Create a requirements traceability matrix for penetration testing a campus computer network.