DevSecOps - brings defense in depth to embedded security

DevSecOps brings defense in depth to embedded security While connected systems have brought easier monitoring, upgrading and enhancement, they’ve also presented more vulnerable attack surfaces. Defending against such attacks can be tough.

Applying multiple levels of security—for instance, secure boot for correct image loads, domain separation, and attack surface reduction—ensures that if one level fails, others remain. While secure application code alone cannot provide sufficient protection in an unsecure environment, it does play a key role in a system designed with security in mind.

This remains true regardless of the preferred development lifecycle. So, embedded development teams increasingly embrace DevOps principles, while others prefer the V model traditionally associated with functional safety standards such as DO-178C for aerospace, ISO 26262 for automotive, and IEC 62304 for medical devices.

From DevOps to DevSecOps for defense in depth The DevOps approach integrates development and operations teams and was designed specifically to respond to changing circumstances. DevOps brings clear benefits to many embedded applications. For example, new market demands can be met faster through more integrated product development, and perhaps most important, application patches and updates such as over-the-air (OTA) security for automotive software can be applied much faster than with other approaches.

DevSecOps—which stands for development security operations—expands on DevOps principles with a “shift left” principle, designing and testing for security early and continuously in each software iteration.

Defense-in-depth and the process model Traditionally, the practice for secure embedded code verification has been largely reactive. Code is developed in accordance with relatively loose guidelines and then subjected to performance, penetration, load, and functional testing to identify vulnerabilities.

A more proactive approach ensures code is secure by design. That implies a systematic development process, where the code is written in accordance with secure coding standards, is traceable to security requirements, and is tested to demonstrate compliance with those requirements as development progresses.

One interpretation of this proactive approach integrates security-related best practices into the V-model software development lifecycle that is 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, ensuring that vulnerabilities are designed out of the system ( Figure 1 ).

Figure 1 The use of security test tools and techniques in the V model is based on the secure software development life cycle (SSDLC) framework. Source: LDRA

Although the context differs between DevSecOps and the SSDLC, shift left implies the same thing for both—an early and ongoing consideration of security ( Figure 2 ).

Figure 2 The DevSecOps process model makes use of security test tools and techniques. Source: LDRA

Shift left: What it means The concepts behind the “shift left” principle should be familiar to anyone developing safety-critical applications because for many years, functional safety standards have demanded a similar approach. Consequently, the following best practices proven in the functional safety domain apply to security-critical applications as well:

Establish requirements at the outset Undocumented requirements lead to miscommunication on all sides and create rework, changes, bug fixes, and security vulnerabilities. To ensure smooth project development, all team members must understand in the same way all parts of the product and the process of its development. Clearly defined functional and security requirements help ensure they do.

Such requirements are likely to define a complete system for V-model developers, and merely an iteration for those applying DevSecOps. However, the principle remains the same. This is not to say that software can never be used as an “intellectual modeling clay” to create a proof of concept, but the ultimate result of such experimentation should be clearly defined requirements—and production code appropriately developed to fulfill them.

Provide bidirectional traceability Bidirectional traceability means that traceability paths are maintained both forward and backward, and automation make it much easier to maintain in a changing project environment ( Figure 3 ).

Figure 3 Automation make bidirectional traceability much easier to maintain. Source: LDRA

.........

https://www.embedded.com/devsecops-brings-defense-in-depth-to-embedded-security/