International standard organizations and governments rolled out the requirements for businesses to tackle raising issues of cybersecurity, it’s wise to choose those standards/frameworks rather than relying entirely on business experiences. There are various standards available which propose security controls to mitigate the cybersecurity issues. Choosing the appropriate standard and selecting the right set of security controls can be a daunting task as it requires a huge effort in understanding the performance needs and industry-specific security standards. This task needs to be done during the architectural phase and it gives inputs to software stakeholders like system architects, software architects, software developers and product owner who are responsible for defining and implementing the cybersecurity strategy for a system.
The purpose of this paper is listed below:
- Present the security phases required in a software development lifecycle.
- Present the major standards currently in practice and guide the readers to select a standard.
- How to select the security controls using NIST (National Institute of Standards and Technology) Framework.
This paper comprises four major sections:
- Security Strategy – Process Flow
- Identify Technology Type
- Cybersecurity Standards
- NIST Framework & Security Controls
A glossary at the end of this article provides a list of acronyms and terminology used throughout this paper.
1. Security Strategy – Process Flow
Security strategy is a must for any embedded system or a component in its overall development lifecycle. Typical security strategy phases are highlighted in Figure 1 as part of conventional SDLC phases.
Figure 1: Security Strategy Flow in SDLC Process. (Source: HCL Technologies)
The input and output of all the security phases are shown in Table 1.
Table 1: Input and Output of the Security Phases. (Source: HCL Technologies)
1.1. Threat Modelling
Threat modelling or Threat risk assessment is the process of finding out threats for a given system. Threat Modelling needs to be done in all the risk areas. Refer SEI link, Wiki link for various threat modelling techniques currently practised in the industry. Selecting the appropriate threat modelling technique for a specific system is outside the scope of this paper.
After threat modelling is done, it is necessary to prioritize the threats. This task is known as the Threat Risk Assessment. The common methods available for threat prioritization are DREAD and CVSS. The result of this task is the prioritization of the threats.
1.2. Identify Security Controls
The guidelines to use the NIST framework and identify security controls will be elaborated in detail from section 8. These security controls are needed to mitigate the threats in the corresponding risk area.
The identified security controls need to be implemented as software functionality. These software functionalities need to work together and need to be implemented as a group of software elements to achieve the required security objectives. These group of cybersecurity software elements and their inter-relationship forms the cybersecurity software architecture which is a part of software architecture.
The software architecture needs to be defined in such a way to accommodate the implementation of security controls. For a family of systems, this task needs to be done while defining the reference software architecture for that family.
1.3. Design & Implement Security Controls
Once the security controls are identified, it is the job of software stakeholders to design and implement them which is outside the scope of this paper.
1.4. Vulnerability/Penetration testing
Vulnerability or penetration testing is the process of identifying vulnerabilities in a system. The output of this phase gives new threats or defects. The process mentioned in Figure 2 needs to be followed to manage the new threats or defects. This phase can be iterative until all the relevant security threats are mitigated.
Figure 2: Management of new threats/defects (Source: HCL Technologies)
2. Identify Technology Type
The essential step needed prior to choosing standard and selecting security controls is identifying the type of technology. Performance requirements as highlighted in Table 2 varies for devices belonging to different technology groups so as the security controls. Hence, the essential step before choosing a standard/framework is to identify whether the target system is information technology or operational technology or a hybrid one.
2.1. Information Technology
IT focusses on electronic data processing, storing and exchanging using general-purpose computers and networking devices.
2.2. Operational Technology
OT focusses on various embedded and control systems like supervisory control and data acquisition (SCADA). These are real-time systems and interacts with the surrounding environments.
2.3. Hybrid Technology – IT/OT Convergence
The integration of networking, communications, automation and analytics in OT devices introduces a hybrid technology. This enables the system administrators to monitor and control the system more easily. IoT is the best example of this hybrid technology.
2.4. Comparison of IT and OT System Characteristics
The outcome of following any security framework is the identification of required security controls. These security controls might be the same for the IT and OT systems. As an example, consider the risk area “Data Protection”, the security controls identified for this risk area needs cryptography in both IT and OT systems. However, the implementation of these security controls varies as per the target technology and its characteristics.
Table 2 shows a comparison of the characteristics of IT and OT.
Table 2 – Comparison of IT and OT system Characteristics (Source: HCL Technologies)
3. Cybersecurity Standards
There are various standards and guidelines available to implement mechanisms for securing the system. It is always good to follow these guidelines and standards rather than to proceed with our own custom solution. However, the important task here is to identify the relevant standard to follow.
The list below covers the majority of the standards applicable for developing information management systems:
Institute of Electrical and Electronic Engineers (IEEE) – Standards for PHY/MAC & data link layer standards (layer 1 & 2)
Internet Engineering Task Force (IETF) – Defines standards for all the networking protocols from layer 3 and above
International Standard Organization (ISO) – Defines standards for many domains
International Electrotechnical Commission (IEC) – Defines standards for electrical and electronic products
ISO/IEC 27000 family of standards – Jointly defined by ISO and IEC for defining information security management system (ISMS) standard. Many other ISO/IEC series are available. Ex: For lightweight cryptography, vulnerability assessment etc.
International Society of Automation (ISA) – Defines standards for Automation.
ISA Security Compliance Institute (ISCI) or isasecure – A part of the ISA group defines standards for cybersecurity of industrial automation control systems. Provides below 3 certifications in alignment with IEC 62443
EDSA – Embedded Device Security Assurance Certification
SSA – System Security Assurance Certification
SDLA – Security Development Lifecycle Assurance Certification
IEC 62443 or ISA 99 – Defines standards for the security of Industrial Control System (ICS) networks. This standard was produced by the International Society of Automation (ISA) and taken over by the International Electrotechnical Commission for further development.
Though many standards are available, there were no guidelines available for how to use the above-mentioned standards.
4. NIST Framework & Security Controls
NIST Cybersecurity Framework released by NIST is a framework of security policies and guidance for organizations to secure their systems. This framework guides the organization in improving its abilities to handle cyber-attacks. It contains an exhaustive list of cybersecurity requirements and the security controls needed to make the system secure.
NIST framework uses the terms as shown in Table 3 to do this mapping.
Table 3 – NIST Terms (Source: HCL Technologies)
4.1. Functions
NIST framework has defined five functions. The brief overview of the five functions are listed below:
Identify – Capability which enables the organization to identify what needs to be protected, such as systems, assets, data and capabilities
Protect – Develop and implement the needed tasks to ensure the functionality of critical services.
Detect – Develop and implement the needed tasks to identify the occurrence of a security event.
Respond – Develop and implement the needed tasks when facing a detected security event.
Recover – Develop and implement the needed tasks to restore the functionality that was damaged because of a security event.
Refer the NIST link for a detailed understanding of the NIST framework. NIST proposes various standards as informative references from which security controls can be identified for the system.
4.2. NIST Recommended Standards
The NIST recommended standards and their applicability for the technology types can be seen in Table 4.
Table 4 – NIST Framework – Proposed Standards (Source: HCL Technologies)
The description for the above standards are listed below:
CIS – Recommends the best practices, tools and benchmarks primarily focused on improving internet security
COBIT – Framework of control objectives primarily used for the governance and the management of Information and related technology.
ISO 27001 – Jointly defined by ISO and IEC for defining information security management system (ISMS) standard. Many other ISO/IEC series are available. Ex: For lightweight cryptography, vulnerability assessment etc.
NIST SP 800-53 – A standard from NIST with an exhaustive list of security controls for different security levels.
NIST SP 800-82 – A NIST proposed standard for industrial control systems. It is based on NIST SP 800-53
ISA 62443 – Defines standards for the security of Industrial Control System (ICS) networks, products development life cycle and processes.
4.3. NIST Profile
Organizations need to do threat modelling against all the risk areas mentioned in the NIST Framework and choose the requirements against their business goals. The selected set of security requirements is called a profile. NIST has already created the profiles for various systems as shown in Table 5.
Table 5 – NIST Profiles (Source: HCL Technologies)
4.4. Domain-Specific Standards
Apart from the NIST recommended standards, there are many standards available specific to the domain. Some examples of domain-specific standards are shown in Table 6.
Table 6 – Examples of Domain-Specific Standards (Source: HCL Technologies)
4.5. NIST SP 800-53 – NIST Proposed Security Controls
NIST has recommended its own security controls in its special publication NIST SP 800-53 which is an open publication. When domain-specific standards are not available and if the organization decides not to procure a new standard, then NIST SP 800-53 will be highly useful. This special publication has more than 350 pages and it will take more efforts to understand. This section briefly presents how to use this publication. It is highly recommended to refer NIST SP 800-53 for the details.
4.5.1. Security Control Structure
The security requirements needed to mitigate the risks are known as security controls. The security controls are organized into eighteen families or risk areas as shown in Figure 3. The controls used to protect these risk areas are called baseline security controls.
Figure 3: NIST 800-53 Risk Areas (Source: NIST SP 800-53 rev4)
The sections present in a security control are as follows: (i) a control section; (ii) a supplemental guidance section; (iii) a control enhancements section; (iv) a references section; and (v) a priority and baseline allocation section.
4.5.1.1. Control Section
The control section explains the security requirements need to be implemented by the organization or the system
4.5.1.2. Supplemental Guidance
The supplemental guidance section gives additional information related to a particular security control.
4.5.1.3. Control Enhancements
The security control enhancements section gives information about the security capabilities which can be applied to particular security control.
4.5.1.4. References
The references section mentions the standards and guidelines related to a specific security control
4.5.1.5. Priority & Baseline Allocation
The priority and baseline allocation sections show the recommended priority codes used for security control implementation. These codes can be used by the organization for sequencing the implementation of security controls.
Apart from the above sections, some security controls may be embedded with assignments and selection statements which enable the organizations to customize the selected security control to meet the security requirements. A sample security control is shown in Figure 4.
Figure 4: A sample security Control (Source: NIST SP 800-53 rev4)
4.5.2. Select Security Controls – Process
The process to select the security controls using NIST proposed security controls is shown in Figure 5.
Figure 5: NIST 800 53 – Security Control Selection Process (Source: HCL Technologies)
4.5.2.1. Security Categorization
The essential step before identifying security controls for a system is to determine how critical and sensitive is the information to be processed. This process is called the security categorization. FIPS Publication 199 describes this process in detail.
4.5.2.1.1. FIPS 199 Security Categorization
FIPS Publication 199 recommends doing security categorization based on the impact of security objectives like confidentiality, integrity, and availability of the system and the data to be processed. The impact has been classified as listed below:
A system is considered as a low-impact system when all the security objectives are low
A system is considered as a moderate-impact system if any one of the security objectives is moderate and other security objectives are lower than moderate.
A system is considered as a high-impact system is if any one of the security objectives is high.
The implementation tip given in NIST SP 800-53 is shown in Figure 6.
Figure 6 – Security Categorization – Implementation Tip (Source: NIST SP 800-53 rev4)
4.5.2.2. Identify Baseline Security Controls
The output of threat modelling is threats or security requirements. The security controls have been mentioned in Appendix D in NIST SP 800-53 rev4. Organizations need to identify the required controls from this catalogue based on the security categorization and the security requirements.
4.5.2.3. Tailoring Baseline Security Controls
After baseline security controls are selected from Appendix D, tailoring process needs to be started. This process allows the organization to customize the security controls by modifying or adding or deleting controls to meet the system and environment-specific requirements. Below listed steps are needed in the tailoring process
4.5.2.3.1. Identify Common Controls
Common controls are applicable for a family of systems controls that are inheritable by one or more organizational systems.
4.5.2.3.2. Apply Scoping Considerations
This step is needed to filter the unwanted security controls from the control baselines.
The list of scoping considerations NIST specifies is shown below.
Control Allocation and Placement Considerations
Operational/environmental-related Considerations
Technology-Related Considerations
Security Objective-Related Considerations
Policy/Regulatory-Related Considerations
Mission Requirements-Related Considerations
4.5.2.3.3. Select Compensating Controls
This step allows the organization to select alternate security controls when the controls mentioned in NIST SP 800-53 do not satisfy the requirements of the target system because of the type of technology, environment, cost reasons etc.
4.5.2.3.4. Assign Security Control Parameter Values
Organizations assign the organization-defined values for the identified security controls. This may be useful before selecting compensating controls. This will also be useful when organizations work together and agree upon a set of security controls for a particular system.
4.5.2.3.5. Supplementing Security Control Baselines
This phase strongly recommends the use of risk assessment for the target system. Risk assessments give additional security requirements which leads to identifying the needed security controls.
4.5.2.3.6. Providing Additional Information
Security controls are high-level design inputs and lack implementation level details. The organization can add additional implementation level details during documentation. Additional information for one of the security controls is shown in Figure 7.
Figure 7 – Additional Information (Source – NIST SP 800-53 rev4)
Organizations can use tailoring guidance on top of baseline security controls to form a set of security controls for a domain or a family of systems. The final set of security controls is called overlay. Ex: NIST SP 800-82 is the overlay created for ICS or OT.
4.5.2.4. Document the Control Selection Process
Organizations need to document the entire process of identifying the baseline security controls and tailoring guidance with proper rationale. This will be highly useful during the review.
The high-level security control selection process is shown in Figure 8.
Figure 8 – Security Control Selection Process (Source – NIST SP 800-53 rev4)
4.6 Why & When NIST Framework should be Followed?
NIST Framework and the proposed security controls in NIST SP 800-53 is applicable to organizations relying on technology, whether their cybersecurity focus is primarily on IT, OT, ICS, cyber-physical systems (CPS), or connected devices more generally, including the IoT.
The flow chart in Figure 9 shows when to follow the NIST Framework and how to choose the NIST proposed security controls.
Figure 9 – Process to Identify Security Controls (Source: HCL Technologies)
Conclusion
This paper presented the security phases required in a software development lifecycle. Then explained the type of technologies and the security standards needed for the relevant technologies. When defining the security strategy for a system, it is wise to follow the process shown in Figure 9. NIST cybersecurity framework and the security controls mentioned in NIST SP 800-53 will greatly help to define and implement security strategy for a system. An excerpt from Wikipedia states that “A security framework adoption study reported that 70% of the surveyed organizations see NIST’s framework as a popular best practice for computer security”.
References
- https://www.nist.gov/cyberframework
- https://www.isa.org/isa99/
- https://insights.sei.cmu.edu/sei_blog/2018/12/threat-modeling-12-available-methods.html
- https://en.wikipedia.org/wiki/Threat_model
- https://searchitoperations.techtarget.com/definition/IT-OT-convergence
- https://www.youtube.com/watch?v=facFYklJP5A
- https://csrc.nist.gov/CSRC/media/Presentations/Industrial-Control-System-Security-and-NIST-SP-800/images-media/ICSS_SP800-5307-02-2008.pdf
- NIST SP 800-53 rev4 – Security and Privacy Controls for Federal Information Systems and Organizations
- NIST SP 800-82 – Guide to Industrial Control Systems (ICS) Security
- https://en.wikipedia.org/wiki/NIST_Cybersecurity_Framework
- https://en.wikipedia.org/wiki/Cyber_security_standards
- https://cipher.com/blog/a-quick-nist-cybersecurity-framework-summary/
- https://www.cisecurity.org/
- https://en.wikipedia.org/wiki/Center_for_Internet_Security
Acronyms
| S.No | Acronym | Expansion |
| 1 | CVSS | Common Vulnerability Scoring System |
| 2 | ICS | Industrial Control Systems |
| 3 | IoT | Internet of Things |
| 4 | IT | Information Technology |
| 5 | NIST | National Institute of Standards and Technology |
| 6 | OT | Operational Technology |
| 7 | SDLC | Software Development Life Cycle |
| 8 | SP | Special Publication |
Terminology
Component – An embedded device.
System – A group of components interconnected to each other.
Threat – Any event that compromises the security of the system.
Risk Area – A hardware/software functionality of the system which is vulnerable to security threats.
Security Requirements – High-level software requirements to mitigate software vulnerabilities.
Security Controls – Design level details to mitigate security threats and meet security requirements.
https://www.embedded.com/understanding-nist-framework-security-controls/
