The Security Development Lifecycle (SDL) is a software development process that helps developers build more secure software and address security compliance requirements while reducing development cost. The cost part is important to consider as the later you introduce security in the process the more expensive it turns to fix issues, and it gets more difficult and time consuming.
The SDL involves modifying a software development organization's processes by integrating measures that lead to improved software security. The intention of these modifications is not to totally overhaul the process, but rather to add well-defined security checkpoints and security deliverables.
The main principles for building secure software on which SDL is based are Secure by Design, Secure by Default, Secure in Deployment and Secure communications (SD3 + C):
Secure by Design: the software should be architected, designed, and implemented so as to protect itself and the information it processes, and to resist attacks.
Secure by Default: in the real world, software will not achieve perfect security, so designers should assume that security flaws would be present. To minimize the harm that occurs when attackers target these remaining flaws, software's default state should promote security. For example, software should run with the least necessary privilege, and services and features that are not widely needed should be disabled by default or accessible only to a small population of users.
Secure in Deployment: Tools and guidance should accompany software to help end users and administrators use it securely. Additionally, updates should be easy to deploy.
Communications: software developers should be prepared for the discovery of product vulnerabilities and should communicate openly and responsibly with end users and administrators to help them take protective action (such as patching or deploying workarounds).
The SDL can be simplified with the following diagram:
We can see that the starting point is the security training of the development teams, teams needs to understand security, what are the consequences of insecure software, and how they can prevent them by integrating security in their thinking. The SDL process next proposes that a group of security requirements or activities associated with the standard phases of the Software development Lifecycle are defined, the main points being:
- Establish security requirements of the product/service
- Create quality gates or bug bars.
- Security & privacy risk assessment of the product/service
- Establish design requirements
- Analysis of the attack surface
- Threat Modeling
- Use approved tools
- Deprecate unsafe functions
- Static analysis
- Dynamic analysis
- Fuzz testing
- Attack surface review
- Incident response plan
- Final security review
Let's be honest, implementing SDL isn’t easy for an established company unless they are starting development from scratch. Conversely this shouldn’t be a reason for developers to not try and make their software as secure as possible.
The impact of a security issue on Critical infrastructure is well understood and documented.Recent history is littered with examples of the consequences of insecure software design, which enabled attacks on infrastructure like Stuxnet, Regin, Duqu, etc. Furthermore, it should be noted that software errors attributed to the Scottish Chinook helicopter crash in 1994, the deadly medical radiation overdoes in the Therac-25 medical device, the European Ariane 5 rocket failure in 1996 and the 1.9 million Toyota Prius recalled due to a software glitch in 2014.
It should be clear from the above that the consequences of insecure software can put peoples lives in danger, potentially causing millions of dollars in losses due to shutting down the critical infrastructure of a country due to a single software vulnerability.
It is encouraging to see a number of ICS vendors now making the move to on-board SDL into their Software development lifecycle with the objective of providing secure products to increase critical infrastructure security.
We believe that SDL adoption is an activity that will provide the bests results for a company that is looking to produce secure software/services, as we mentioned before the sooner we address security in the development life cycle the cheaper and easier it will be.
We at Applied Risk can help you to implement SDL in your organization, if you are interested in learning more about SDL for ICS/SCADA product please contact us!