EMBEDDED TECHNOLOGY
The ‘Shift Left’ Approach to Securing Connected Embedded Systems
While connected systems offer easier monitoring, upgrading and enhancement, these improvements have introduced security-critical devices to new vulnerabilities. Securing embedded software for these devices has consequently become even more essential, but far too often, companies still “design first, test later,” invariably creating insecure code that puts industry and individuals at risk.
W
ith traditional software development, requirements flow to design, to code (perhaps via a model), and to test. With agile development, requirements are built up iteratively in layers from the inside out, each with its own loop of requirements, design, code, and test. With either methodology, ensuring that security requirements are an integral part of the development process will lead to a far more satisfactory and less costly outcome than merely looking for vulnerabilities at the end. This proactive approach to designed-in security is referred to as “shift left” of the software development life cycle.
Defense-in-depth and the V-model Shift left implies a systematic development process where the code is: •
written in accordance with secure coding standards
• •
traceable to security requirements
tested to demonstrate compliance with those requirements as development progresses
Shift left integrates security-related best practices into the V-model software development lifecycle that should be familiar to developers in the functional safety domain. The resulting Secure Software Development Life Cycle (SSDLC) represents a shift left for security-focused application developers and provides a practical approach to ensuring that vulnerabilities are quickly addressed. These same design principles can be applied to the DevOps lifecycle, resulting in what has become known as DevSecOps. Although the context differs between
22 MAY 2024 | ELECTRONICS FOR ENGINEERS
DevSecOps and the SSDLC, shift left implies the same thing for both; an early and ongoing consideration of security, with functional and security requirements established at the outset (V-model) or before each iteration (DevSecOps).
Regardless of the process followed, developers should test early and use the appropriate tools, tests and techniques. In the V model, these are largely analogous and complementary to the processes usually associated with functional safety application development (figure 1).
In the DevSecOps model, the DevOps life cycle is superimposed with security- related activities throughout the continuous development process (figure 2). Requirements traceability is maintained throughout the development process in the case of the V-model, and for each development iteration in the case of the DevSecOps model (shown in orange).
Some SAST (static) tools confirm adherence to coding standards, ensure that complexity is kept to a minimum, and check that code is maintainable. Others check for security vulnerabilities but only to the extent that such checks are possible on source code without the context of an execution environment. White-box DAST (dynamic) enables compiled and executed code to be tested in the development environment, or even better, on the target hardware. Code coverage confirms that all security is fulfilled by the code, and that all code fulfills one or more requirements. Source to object code traceability can also be confirmed if required. Robustness testing can be used within the unit test environment to help demonstrate the resiliency of specific functions, whether in isolation or in the context of their call tree. Fuzz and penetration black-box testing techniques traditionally associated with software security remain of considerable
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50
