Keywords

1 Introduction

In traditional systems design, security considerations of a system were limited to the integration of security added after the completed system was developed [1,2,3], treating security features as of secondary importance. The Industrial Internet of Things (IIoT) defines the use of new digitized and highly connected systems [4], which require these systems to be designed, developed and managed by engineers while considering the impact and effects of cyberattacks on these systems throughout the whole system [5]. In reaction to these required changes in design, the systems engineering community identified security roles and responsibilities applicable to the entire systems development life cycle for future connected environments [6], namely the secure systems development life cycle (S-SDLC) [5]. Various sources argue that all engineering disciplines must understand and practice security through all phases of the system lifecycle to meet the project’s requirements and manage an acceptable level of risk [8, 9].

In systems engineering, a holistic cybersecurity view is required by Systems Engineers (SEs) to design secure systems as the S-SDLC requires the execution of various specialized security tasks, such as security requirements planning which requires the evaluation of functional systems requirements relating to security and translation into technical solutions [11]. Globally, engineering industries are observing that SEs are not adequately prepared to execute many of these tasks, including the incorporation of system security requirements into the system [11, 12]. Therefore, industries require SEs with holistic cybersecurity knowledge and Security Requirements Engineers (SREs) who can conduct the security requirements process, minimizing the risk during systems development lifecycle [8].

In the South African (SA) engineering space, there exists a high demand in cybersecurity engineering professionals. However, throughout academic institutions in SA there are no known comprehensive cybersecurity engineering courses offered, based on their undergraduate and postgraduate syllabus descriptions [9]. In systems engineering, the lack of cybersecurity content or modules in SA engineering education and the need for cybersecurity professionals point toward a gap in cybersecurity knowledge amongst engineers in industry. The need for such a skill requires the addition of security requirements engineering to the education in systems engineering curricula [13]. The aim of this paper is to design a cybersecurity module for systems engineering students focusing on security requirements engineering.

2 The Need for Security Requirements Engineering Education

Engineering industries globally are observing that SEs are not adequately prepared to incorporate system security requirements into the system [12], which constitutes the need for an additional SE who possesses the knowledge, skills and competencies related to security requirements [11]. This includes the consideration of security requirements as an integral part of system requirements to reduce systems weakness [8], treating security requirements as functional requirements and not just non-functional requirements or of secondary importance [14, 15]. However, not all system engineers can be trained to become security experts. Therefore, academia should develop security experts as a path in system engineering, including the SRE [16].

In the paper entitled “Global Perspectives on Cybersecurity Education for 2030: A Case for a Meta-discipline”, the authors argue that cybersecurity must be integrated into existing academic disciplines, not simply be developed as separate degree programs [13]. As with a module educating SEs to have a holistic view of cybersecurity, a module must exist in which a SE responsible for requirements engineering must be educated on the security factors influencing requirement engineering. To ensure the development of relevant content for such modules, this research investigates internal and external factors of the cybersecurity and systems engineering fields which can influence and impact the content of a cybersecurity curriculum.

3 Methodology

A preliminary investigation into a basic body of knowledge of a SE cybersecurity module was presented in [10] which provided a baseline for this research. This paper builds on the work done in [10] where a broader spectrum literature was considered to inform a module in SE. The framework described by Knapp et al. [17] was developed to ensure that cybersecurity certifications remain relevant in industry, by identifying factors which professional bodies recognize as important to a relevant certification. These relevant factors are then used to inform a current curriculum to remain relevant to industry requirements.

This framework was adapted to analyze professional certifications to help shape a new cybersecurity module related to SE. The module was validated against the Curriculum Guidelines for Post-Secondary Degree Programs in Cybersecurity (CSEC2017) guidelines. The adapted framework followed is illustrated in Fig. 1 below.

Fig. 1.
figure 1

Methodology for module development [14]

Full size image
  1. 1.

    Step 1: Review the key input factors that certifying bodies consider relevant, including threat landscape, technology changes, industry standards, workforce needs, and government and regulation as per the framework in [17]. From this review, relevant cybersecurity knowledge and skills are determined.

  2. 2.

    Step 2: Development of a draft SE cybersecurity module from the data collected in Step 1.

  3. 3.

    Step 3: Validate the developed SE cybersecurity module against the CSEC2017 guidelines.

The results of the various steps are discussed in the subsequent sections.

4 Review of Input Factors

To analyze the significant factors that professional certifying bodies consider most important relating to cybersecurity in systems requirement engineering, literature was reviewed to determine specific skills, knowledge and activities relating to security in requirements engineering. The five input factors, shown in Fig. 1, is considered. This is not an exhaustive list and other factors can be considered but is considered comprehensive to provide relevant information for module development [17].

4.1 Threat Landscape

The changing technological landscape constantly gives rise to new threats and risks, like protection of information and information systems and communications and network security [20]. As cybersecurity threats are constantly evolving, it is essential to consider literature discussing any new threats relating to engineering systems and how they should be managed. Traditionally, security requirements were considered as non-functional requirements [11, 14, 15]. Other instances include where security requirements are developed independently from the rest of the requirements engineering activity and hence not integrated into the requirements engineering activities [11]. Generally, this leads to serious design challenges and wide-ranging security vulnerabilities. New requirements must be considered by SEs as part of each system to create innovative solutions to address the new risks. Researchers argue that many security problems can be eliminated through the integration of security with requirements engineering [5, 7, 19]. By conducting security requirements in the early stages of the development process with the system requirements specifications, security threats can be avoided very early in the systems development process as security is adequately planned, acquired, built in, and deployed as an integral part of the system [5, 7, 19].

NIST Special Publication 800-64 - Security Considerations in the System Development Life Cycle [7] comments on the enforcement of security requirements throughout the phases of the life cycle. Nejib and Beyer comment on the importance of systems engineers towards contributing to secure systems [8]. They considered current and evolving policies, guidance, and standards (ISO 15288:2015) regarding security activities in the S-SDLC and provide a framework which identifies the security-related activities applicable to systems engineers. The 5 SE processes related to requirements engineering was identified as important processes which an SRE should implement.

The identified 5 processes will be used as inputs to the cybersecurity module. The output of this investigation yielded the following [8]:

  • Elicit Stakeholder Requirements

  • Define Stakeholder Security Requirements

  • Analyse and Maintain Stakeholder Security Requirements

  • Define Systems Security Requirements

  • Analyse and Maintain Systems Security Requirements

4.2 Workforce Needs

Von Solms and Marnewick identified that within the S-SDLC, specialized security-related requirement actions relevant to the 5 processes identified in Sect. 4.1 requires the skills of a System Requirements Planner – a position generally filled by a SE [11]. To identify the tasks, skills, knowledge and abilities required by the SE to perform these tasks, the 81 tasks, skills, knowledge and abilities documented in NIST 800-181 relating to this position were investigated. The factors relevant to the requirements engineering process (5 processes identified in Sect. 4.1) were determined.

The output of the analysis is shown in Table 1 below where the NIST code in provided with a shortened description. These 22 identified factors will be used as inputs to the cybersecurity module.

Table 1. Tasks, skills, knowledge and abilities requirements from NIST 800-181 [21]
Full size table

4.3 Changing Technology

Changing technological landscapes, including Industry 4.0 requirements, bring changes to the cybersecurity landscape. The security areas will differ for each new system, so the SRE must be able to elicit the security requirements upfront, impacting the system in development. Salini et al. [19] states that every SRE must have the knowledge related to various types of security requirements and factors which influence requirements. Elicitation of requirements includes considering various non-technical aspects, which includes standards and best practices [11], laws and regulations, as well as knowledge relating to human factors, which can be considered expert knowledge to be used as input to security requirements engineering and threat analysis.

The Cyber Security Body of Knowledge (CyBOK) is one framework developed to provide guidance on the foundational and generally recognized knowledge on cybersecurity [22]. To identify the cybersecurity body of knowledge which applies to the SRE, the 19 top-level knowledge areas (KAs) documented in the CyBOK were evaluated.

The category “Human, Organizational, and Regulatory Aspects” were considered relevant to the SRE as humans, organizations and regulations must be considered when requirements are defined. The output of the analysis is shown in Table 2 below where a unique code in provided with a shortened description. These 3 identified factors will be used as inputs to the cybersecurity module.

Table 2. Cybersecurity knowledge requirements from CyBOK [22]
Full size table

4.4 Industry Standards

Industry standard and best practices are considered an important input toward curriculum relevance. Various industry standards and guidelines relating to cybersecurity, including ISO and NIST security frameworks, provides authoritative guidelines, frameworks and procedures to be adopted by industry [17, 23].

Upon the investigation of the eCompetence framework, it was seen that security aspects are only defined in the “Build” function much later in the S-SDLC. This implies that security forms part of the design, but no more detail is provided. Considering security requirements in the eCompetence framework, it was only included in the “Run” phase of the SDLC, implying that security only forms part of the reaction and maintenance processes of a system and not the requirements [24]. A second investigation into the NIST 800-160 [25] framework as well as the INCOSE Systems Engineering Handbook [26] was conducted. These frameworks describe the use of the technical Systems Engineering and Software processes set out in ISO/IEC/IEEE 15288:2015. Nejib et al. mapped the Security Systems Engineering processes described in the NIST 800-160 framework technical processes of ISO/IEC/IEEE 15288:2015, resulting in 27 Security Systems Engineering processes [8]. From these processes, five were related to the Security Requirements phase of the S-SDLC. These five processes were identified in Sect. 4.1, which already formed part of the input factors to the curriculum.

4.5 Government and Regulation

Following the evaluation done on the key input factor of Changing Technology, is was determined that law and regulations must be viewed as stakeholders in the requirements process. When a system is designed, the requirements of these laws and regulation must be integrated into the requirements of the system itself. Kotonya and Sommerville [27] commented on the inputs and outputs of the requirements engineering process and stated that two inputs include Organizational Standards and Regulations [24]. In the same manner, all regulations and standards related to cybersecurity must be included in the Security Requirement Specification process. As stated in Sect. 4.3, knowledge relating to cybersecurity laws and regulations can be considered specialized knowledge and must be considered as an input factor the curriculum design.

5 Module Development

The input factors identified in Sect. 4 is now utilized to design a cybersecurity module for systems engineering students focusing on security requirements engineering. The cybersecurity knowledge, tools and skills identified in Sect. 4 require various levels of understanding by the SRE, ranging from a holistic view regarding systems security to specialized knowledge relating cybersecurity laws and regulations to elicit relevant requirements.

Kossiakoff et al. derived a range of educational components relating to systems engineering development, based on quality work experience and professional certifications [28]. These components include three overhead components, namely engineering process training, systems thinking activities and systems engineering work experience, each consisting of three sub-activities each. Adapting the generalized activities presented in [28] to the field of requirements engineering, the following development activities were identified to use as a guideline in the development of a module for SREs:

  • Engineering process training: which include Process Knowledge, Tools and techniques and Skills

  • Systems thinking activities which include Security discipline expertise, Problem solving and Holistic view

The evaluation of the threat landscape in Sect. 4.1 identified five engineering processes relating to requirements engineering in the S-SDLC. These processes are viewed in relation to the six engineering development activities listed above to generate a Body of Knowledge (BoK) table, namely the rows and columns of the table, respectively. This BoK table is populated by mapping all the knowledge, skills, abilities and tasks identified in the other sections of Sect. 4 to the six engineering processes and developmental activities. The BoK table is shown in Table 3 below.

Table 3 Body of knowledge for security requirements engineering module
Full size table

This populated table provides an overview on the cybersecurity module for SE students. The columns of the BOK table are the five processes related to the Security Requirements phase of the S-SDLC identified in Sects. 4.1 and 4.4. The table is populated with the knowledge, skills, abilities, tasks and requirements identified in Sects. 4.2, 4.3 and 4.5. This table can provide guidance to determine the content of a Security Requirements Engineering module in systems engineering as the codes in the table indicate the topics of interest for each Security Requirements process in the S-SDLC.

Table 3 presents the content for the cybersecurity module for security requirements within a SE curriculum. From the table mapping the systems thinking ability is very important for the future and a lot of focus should be in this area to help teach future students to think in this manner.

6 Module Validation

The CSEC2017 framework provides guidance for education efforts in cybersecurity [18] which offers a sound guideline for the validation of the developed module. The CSEC framework divides the cybersecurity content into 8 KAs and states that the content must be aligned to workforce needs by viewing the work through a disciplinary lens. In the development of a cybersecurity module for SEs, von Solms and Futcher identified systems engineering as the disciplinary lens and determined that 3 of the 8 knowledge areas can be considered too technical for the systems engineering domain [10]. Building on this research, the 5 KAs considered in the validation of this developed module are Software, System, Human, Organizational and Societal security.

The five processes which formed the headings of Table 3 columns were used as the divisions for five module units of work. Using the key words of the various knowledge, skills, abilities and tasks included as entries in the Table 3, the CSEC2017 document was investigated and corresponding KAs and knowledge units (KUs) were identified and indicated in Table 4. When a corresponding CSEC2017 KU could not be found, an addition entry was added to Table 4, named “Systems Engineering Specialized”.

Table 4. Security requirements engineering module outline
Full size table

7 Discussion and Recommendations

From the validation process shown in Table 4, emphasis is placed on five main KAs:

  • Systems Thinking: As a SE, the professional must have skill of systems thinking and be able to view a system holistically.

  • Risk Management and Governance: The SE must be able to implement and understand risk management of systems and organizational security controls, which requires knowledge of applicable standards, best practices, and approaches. In addition, the new threats that the connected systems introduce must be analysed and risk estimations must be done during requirements phase.

  • Security systems engineering principles: The SE responsible for the security requirements engineering needs to have expert knowledge in the security discipline.

  • Law and Regulation related to Cybersecurity: All local and international statutory and regulatory requirements, compliance obligations, and security ethics, must be known to elicit security requirements.

  • Human Factors: Knowledge relating to human factors and user behaviours and how it impacts security, security culture and awareness must be known by SREs.

These observations support the findings in Table 3 where it was shown that systems thinking skills must be considered in the changing technological landscape. However, the SE must have fundamental expert knowledge in security practice and the ability to apply systems thinking. Security threats will change, and the SE must be able to consider all possible scenarios when specifying requirements. Due to technological changes in systems, this module needs to be developed and used in the training of specialized SEs to prepare them for the changes brought forth by changing technological landscapes.

8 Conclusion

The creation of systems to comply with Industry 4.0 environments and cyberattacks requires the elicitation of security requirements from various sources, including regulations, client needs and human behavioral factors. The elicitation of these security requirements requires a SE who are specialize in the field of security requirements engineering and had specialized knowledge relating to various security aspects which may influence the security requirements of the system.

Engineering education in SA does not include comprehensive cybersecurity modules in systems engineering and does not provide specialized education in the field of security requirements engineering. This paper includes an investigation to determine the BoK for the creation of a module which specializes in security requirements engineering. Input factors from industry were considered to determine the knowledge, skills, abilities and tasks required for security requirements elicitation. The CSEC2017 framework were utilized to validate the educational content to be included in the module. The basic BoK for a security requirement engineering module is presented, which shows that the KAs of Systems Thinking, Risk Management and Governance, Security systems engineering principles, Law and Regulation related to Cybersecurity and Human Factors are the most important for inclusion in the module.

This work will contribute to cybersecurity curriculum design in systems engineering and other specialized systems engineering fields, such as security requirements engineering. This work can also be used as a roadmap for the development of SE modules outside of SA, as it is based on international standards and best practices. However, the laws and regulations relevant to the specific country must be considered.