Chapter 15. Cybersecurity Engineering

Chapter Objectives

After reading this chapter and completing the exercises, you will be able to do the following:

  • Understand basic systems engineering concepts

  • Understand how to integrate systems engineering into cybersecurity

Introduction

The field of cybersecurity is growing rapidly. While this rapid expansion has been beneficial for the career prospects of cybersecurity practitioners, it has presented challenges for defining the profession, including the roles and requirements within cybersecurity. It is not even clear where cybersecurity belongs in a university. A wide range of approaches are used in cybersecurity and cybersecurity education. In some cases, cybersecurity is taught and practiced as a business management discipline, with a focus on policies and procedures. In other instances, it is approached as a computer science subdiscipline. This disparity in even defining cybersecurity is a significant problem for both practitioners and academia.

One result of this lack of a coherent definition of cybersecurity is the wide range of technical backgrounds and skillsets for practitioners. There are cybersecurity professionals with a strong background in computer science or engineering, and others with virtually no technical background at all. This ambiguity leads to difficulty in even defining what cybersecurity is. Some people approach it as a management issue, primarily focused on the formulation and implementation of appropriate security standards and policies. In this approach, technical skills are a secondary (or even tertiary) concern and only relevant to the implementation of security standards and policies.

A different approach to cybersecurity is to view it as a highly technical discipline. In this view, policies and procedures are still a part of cybersecurity, but they are ancillary to technical skills. This approach focuses on the technical aspects of cybersecurity, and the technical skillset of practitioners. In this view, cybersecurity practitioners are likely to have a strong computer science background, perhaps including a degree in computer science or a related discipline. This chapter embraces the technical viewpoint of cybersecurity but provides more specificity and refinement to that definition. The approach outlined in this chapter is to view cybersecurity as an engineering discipline—in fact, as a subdiscipline of systems engineering.

Defining Cybersecurity Engineering

In order to define cybersecurity engineering as a discipline, it is first necessary to define engineering. The Accreditation Board for Engineering and Technology defines engineering as follows:

The profession in which a knowledge of the mathematical and natural sciences gained by study, experience, and practice is applied with judgment to develop ways to utilize, economically, the materials and forces of nature for the benefit of mankind.

This definition indicates that any engineering discipline must be predicated on knowledge of mathematical and natural sciences. If you consider traditional engineering disciplines (aerospace, electrical, mechanical, and so on), you realize that engineering is heavily focused on planning and testing. One must plan everything from requirements gathering to testing and rollout. Modeling is also a central concept. These are things not often done in cybersecurity.

Traditional engineering disciplines include mechanical, electrical, civil, and chemical. In the twentieth century, that list was expanded to include aerospace, bio, nuclear, computer, and other types of engineering. In the past 50 years we have seen a rise in the field of systems engineering. What all these diverse fields of engineering have in common is that they all are predicated on same engineering principles, including rigorous design, based on application of mathematics and natural sciences. Engineering is primarily concerned with a mathematical and scientific approach to design. That systematic approach to design carries on into development and testing—and, in fact, throughout the systems life cycle. Even the rigorous design is in turn predicated on a scientific and methodical approach to requirements engineering.

Based on an understanding of engineering definitions and principles, it should be clear that in order to make cybersecurity engineering a true engineering discipline, there are elements of the practice and teaching of cybersecurity that must be changed. The most efficient way to effect such changes is to model cybersecurity engineering after some existing engineering discipline. It might seem appropriate to choose computer engineering or software engineering as templates for cybersecurity engineering; however, cybersecurity engineering inherently involves a symbiosis of a wide range of systems. Cybersecurity is not limited to computers. It also includes human factors, policies, and legal issues that are foreign to computer engineering and software engineering.

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.

A screenshot depicts a requirement bidirectional traceability matrix.
Figure 15.1 Requirements bidirectional traceability matrix.

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.

A figure shows the work breakdown structure.
Figure 15.2 Work Breakdown Structure.

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.

MSD equals 1 over n times sigma upper limit equals n lower limit i equals 2 of (y subscript i minus T) the whole squared.
Figure 15.3 Mean squared deviation formula.

In this formula, yi 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.

MPE equals 100 percent over n times sigma upper limit equals n lower limit t equals 1 of a subscript t minus f subscript t over a subscript t.
Figure 15.4 Mean percentage error formula.

In this formula,

n is the number of different times for which the variable is forecast, at 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.

MTBF equals sigma times (start of downtime minus start of uptime) over number of failures.
Figure 15.5 MTBF Formula 1.

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.

MTBF equals integral over the intervals 0 to infinity of R of t dt equals integral over the intervals 0 to infinity of tf of t dt.
Figure 15.6 MTBF Formula 2.

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

This section of the chapter is adapted from a paper written by the book’s author. That paper first defined Security Modeling Language (SecML) as a new modeling language.

Systems engineering utilizes a number of approaches to modeling systems and subsystems. Modeling is an integral part of design and testing. In fact, there is an entire field of model-based systems engineering. One of the primary modeling methods utilized in systems engineering is system modeling language SysML. SysML is an extension of the earlier Unified Modeling Language (UML). UML was created by the Object Management Group (OMG) in order to design software. SysML extends that to modeling a wide range of systems. SysML includes 9 diagrams, some of which are taken directly from UML and others of which were created for SysML.

Software engineering also includes a number of other modeling languages. For example, there are domain-specific modeling languages, such as framework-specific modeling languages (FSMLs). FSMLs are used in object-oriented programming. There are multiple, specific modeling languages for a wide range of software engineering applications.

Systems Modeling Language (SysML) was developed for modeling systems and systems of systems. SysML is the primary modeling tool used in systems engineering. It was originally developed as an open source specification that extended Unified Modeling Language (UML). In 2001 INCOSE started the SysML initiative. Eventually INCOSE worked with the Object Management Group (OMG) to create SysML. SysML v1.0 was released in 2007. The current version of SysML is 1.5 and was introduced in 2017. It is specified in ISO Standard 19514:2017, “Information technology: Object management group systems modeling language (OMG SysML).”

As has been discussed, there are specific modeling techniques and even modeling languages for particular engineering disciplines. If cybersecurity engineering is to be truly defined as a separate engineering discipline, it would also benefit from its own modeling language. This would facilitate modeling that is tailored to cybersecurity needs.

An important part of systems engineering is modeling. In fact, there is an entire subdiscipline of systems engineering concerned with modeling. The concept is to facilitate better understanding of a system at any stage in the system development life cycle. Being able to simulate and model system behavior can even be used during requirements gathering. This fact supports the need for cybersecurity engineering to include a modeling language.

It is clear the modeling is an integral part of engineering, and particularly systems engineering. It is also true that modeling has been used, in a limited fashion in some aspects of cybersecurity. These facts support the need for a cybersecurity specific modeling language.

What is being proposed in this chapter is a modification to SysML in order to facilitate modeling in security. This modeling is termed SecML and is used to model security needs. The SecML definition uses some SysML and UML diagrams and adds a few new diagrams. The concept is to provide a modeling language that is specific to cybersecurity. Software engineering uses UML and systems engineering SysML; it is only natural that cybersecurity engineering should have a modeling language specific to the domain.

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.

A screenshot depicts a typical use-case diagram for a restaurant scenario.
Figure 15.7 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.

A table presents the various misuse case notations.
Figure 15.8 Misuse-case notation.

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.

An example of a misuse-case diagram is shown.
Figure 15.9 Misuse-case diagram example.

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.

An example of a misuse-case diagram is shown.
Figure 15.10 Another misuse-case example.

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.

An example of a specific misuse-case diagram is shown.
Figure 15.11 Specific misuse-case example.

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.

A UML/SysML sequence diagram is shown.
Figure 15.12 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.

A figure shows the cyber security addition symbol that is added to sequence diagrams. The symbol is represented with a circle and an X in it. It is used for an unauthorized sequence such as sending a spoofed e-mail or malware.
Figure 15.13 Cybersecurity addition to sequence diagrams.

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.

A modified sequence diagram is shown.
Figure 15.14 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.

A figure shows the data interface diagram.
Figure 15.15 Data interface diagram.

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

The various data interface diagram elements are listed in a table.
Figure 15.16 Data interface diagram elements.

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.

Summary

In this chapter, you have seen the application of systems engineering to cybersecurity. The goal is that you would begin to apply a methodical, systematic approach to cybersecurity. Penetration testing, as one example, should not be just a set of random hacking attempts. Rather, it should be a carefully engineered process that is mapped to specific testing requirements. It is also beneficial to model cybersecurity scenarios in order to better understand system security requirements. The SecML modeling language that was briefly introduced in this chapter provides such a methodology.

Test Your Skills

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 counter measure symbol, represented by an "X" mark enclosed in a circle.

A. A forbidden action

B. A blocked system

C. A countermeasure

D. An attack

6. What does this symbol represent in SecML?

A system abuser symbol represented by a typical user diagram enclosed in a circle.

A. Attack victim

B. System abuser

C. System user

D. Isolated user

7. What does this system represent in SecML?

An unauthorized sequence symbol.

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.

..................Content has been hidden....................

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