Practices for a Secure Development Lifecycle (SDL)
All practices together define the necessary processes that must be in place and established to guarantee Secure by Design, and thus the Defense-in-Depth strategy, throughout the entire device lifecycle. The practices are often applied iteratively.
Further, IEC 62443 defines a maturity model, which is similar to CMMI to prove the fulfillment of the requirements regarding information security. The goal of the maturity model for the development organization is to demonstrate the quality of information security and for the device user to evaluate whether the quality is sufficient for the intended use.
Practice 1 - Security Management
Ensure that all security-related activities are planned, documented and executed throughout the lifecycle of the device.
To do this, it is best to create a security plan, in a similar way as a safety plan in functional safety.
Practice 2 - Specification of Security Requirements
Ensure that the information security requirements of the device and the assumed security context are documented.
At the beginning of the specification lies the creation of a specific threat model for the device. The goal of this model is to systematically identify potential threats, such as structural vulnerabilities or lack of appropriate safeguards, and derive the security requirements for the device. The requirements must take into account the entire life cycle, i.e. from development to decommissioning of the device.
It is essential that the model is regularly reviewed and updated as needed (e.g. in response to the emergence of new threats), even if the device itself does not change.
Documenting the assumed security context ensures that developers and users have the same understanding of what the intended use of the device is. E.g. it clarifies questions such as: Is there physical device protection? Is the device behind a firewall? This information helps developers make appropriate design decisions.
Practice 3 - Security by Design
Ensure that device information security is considered in all phases of development, i.e., from system architecture to detailed design.
This is the actual "technical" part of Secure by Design, which is strongly emphasized in e.g. "Secure by Design, Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software " by CISA.
Here, the focus is particularly on the internal and external physical and logical device interfaces, which must be identified and characterized.
Furthermore, several layers of defense (Defense-in-Depth strategy) must be provided. This means that each layer has an assigned responsibility and reduces the attack surface of the next layer. Each layer must assume that the underlying layer may be compromised. The design of the layers is based on the threat model (Practice 2) and follows a risk-based approach.
Up-to-date security-relevant technologies, such as Secure Boot, encrypted communication, etc., must also be applied.
Practice 4 - Secure Implementation
Ensure that security requirements for hardware and software are implemented correctly.
This is done using specifications (design specifications, programming guidelines, etc.) and reviews (peer review, static code analysis, etc.).
Practice 5 - Security Verification and Validation
Ensure that the device meets all security requirements and that all test activities are documented.
Security tests occur at various points in the development cycle and cover the following aspects:
- Tests that all security requirements (Practice 1) are met
- Tests of the effectiveness of threat defenses (e.g., testing each layer of a layered defense strategy)
- Testing for known vulnerabilities (e.g., MITRE, OWASP)
- Penetration testing (discovering vulnerabilities)
Tests can be automatic (unit testing, fuzzing, vulnerability scanner, etc.), manual (test lists, penetration testing, etc.) or combined.
Practice 6 - Management of Security-Related Issues
Ensure that all reported security issues are included and addressed according to the other practices.
Possible internal and external sources that discover and report security issues are:
- Testers (verification and validation)
- Suppliers of third-party components
- Device users (integrators, service personnel, etc.)
Practice 7 - Security Update Management
Ensure that security updates are made available for a device in due time.
At a minimum, security updates must be regression-tested.
Practice 8 - Security Guidelines
Ensure that user documentation exists that describes how to securely configure, operate, maintain, and dispose of the device.
It is especially important that the user knows in what context the device can be used securely.
What do you need to do to Live Secure by Design?
For those who already have an established process landscape for development, such as CMMI or aSPICE, the step is small. Define processes for the new practices and add those processes to your process landscape. Train your staff and use lessons learned from your development projects to iteratively improve your information security processes.
If you don't already have an appropriate process landscape, this is the time to address it. No one can avoid the topic of information security anymore. And as outlined in this blog, processes are the be-all and end-all for Security by Design, , also for embedded Security by Design.
Do you need knowledge or support for creating development processes or implementing your development project? We are glad to support you!
Alois Cavelti
Do you have additional questions? Do you have a different opinion? If so, email me or comment your thoughts below!
What does Secure by Design mean for Embedded Development? Embedded Secure by Design?
