DevSecOps and Full Lifecycle Security

The industry is rapidly transforming from devices at the edge that weren’t always connected, to devices at the edge that are now connected 24/7, 365 days a year. These include engineering devices fielded in a wide range of environments from remote oil fields to medical offices and everything in between. This change now requires a significant focus on the security of that device, so security must be integrated into the full life cycle of the device.

Full lifecycle security ensures that security is taken into consideration at the start of any project, not bolted onto the end. Consideration needs to start with the hardware platform of the specific edge device, including which features that hardware brings that can be utilized. Security testing needs to be shifted early in the development flow ensuring that security is integrated throughout the product life cycle from inception through decommissioning. By moving the security related testing early in the development flow, the security related issues are identified and resolved sooner along with issues related to the device’s functionality, which are traditionally identified earlier in the development process. With all this in mind, the industry term “DevSecOps” is gaining more attention. DevSecOps is the concept of automating the integration of development, security and operations.

The SolarWinds attack earlier this year brought the development environment security into the immediate forefront. Instead of attacking individual sites, hackers have now decided to penetrate a widely used software package, and that gives them access to over 15,000 different entities across the globe when that infected software package was distributed. So, the attack vector was moved from the end product that gets fielded to the supply chain that builds the product, and the attackers have shifted left just as we have. So, the work of adding security to the DevOps environment to get to a DevSecOps environment must itself be secured.

IMPLEMENTING FULL LIFECYCLE SECURITY
First, a team should conduct a security assessment of the device to identify the assets and vulnerabilities of that device—typically the device data and determine which security features are required to protect the data from identified threats. A security assessment isn’t a one and done type of activity, but rather a tool that should be periodically revisited during the full life cycle of the device. As projects evolve and pivot use cases change, and the threat landscape is always changing. Figure 1 illustrates a full lifecycle security assessment.

The team should also pick a hardware platform that provides the widest selection of security features that can be leveraged over the project’s lifespan along with, and very importantly, the ability for the cryptographic algorithms to be updated, or crypto agility. The third item is to secure the development environment itself. As the recent SolarWinds attack has brought to the forefront is the criticality of the development environment and just what a broad reach penetration of the development environment can have.

Because this space is ever-evolving, teams can also retrofit a design with security by performing this same assessment on the device. The assessment will bring forward a prioritized list of the assets or the data that need to be protected and will also take into account any regulatory requirements with which the project team needs to comply. Depending upon the level of technology refresh the project can support, whether it would include the hardware or be software specific, the security assessment will then provide the guidance in securing that device.

There’s a core set of technologies that can be leverages in securing a DevSecOps environment. These are shown in Figure 2, and detailed here:

• The Hardware Security module (HSM) is a purpose-built device that we can use to generate and protect all of our cryptographic key material.
• Identity management—For all authentication for both human accounts and service accounts, these are managed through a single platform for the authentication and authorization into the DevSecOps environment as a system and within each component of the environment.
• The Private Certificate authority is a layer that’s really above the hardware security module or a software implementation if the HSM isn’t available. The Private Certificate Authority manages the asymmetric hierarchy within the DevSecOps environment. So, this includes the digital signature generation and verification of forensic artifacts that the DevSecOps environment produces along with digitally signing the resulting image that the DevSecOps environment creates.
• Mutually authenticated Transport Layer Security (TLS) ensures that all communication within the DevSecOps environment itself is encrypted, authenticated, and authorized.
• Tooling automation supports a DevSecOps environment with the focus on the fact that the DevSecOps environment has to be able to build that DevSecOps environment.
• Security Information and Event Management (SIEM)— There are more than a hundred different components in a typical DevSecOps environment and each of these generate a variety of log messages that need to be analyzed both individually and in the larger context of the system to determine if the security policy of the DevSecOps environment has been violated or not.
• Privileged Access Management—Instead of one individual having access to the root password, this system would create a two-person rule for any privilege command issued within the DevSecOps environment. This ensures that if an individual’s credentials are compromised, the DevSecOps an environment is still secure.

THE END OF THE LIFECYCLE
Often, the decommissioning of devices unfortunately means to toss them into a recycle bin at your favorite electronics store—or worse, put them up for sale on the various reseller sites without removing the critical data from that device. This critical data can include personally identifiable information or similar data that would be of extreme value to attackers. When a device comes to the end of its lifecycle, the project team must take into consideration the ability to securely remove this critical data within the device, to the point where they consider this a secure reset to factory default mechanism. Thus, they would implement a mechanism that’s referred to as cryptographic erase – a method of sanitization, in which the encryption key for the data in question is itself erased. So, this makes the recovery of the decrypted data infeasible based on the algorithm that’s used.

Maintaining and updating security features is a neverending process. Vulnerability management is absolutely paramount in maintaining the security posture of the DevSecOps environment. With the large number of components used along with new vulnerabilities being reported every day, this maintenance requires a disciplined and mature process to be in place to manage the inflow of common vulnerabilities and exposures.

RESOURCES

Wind River | www.windriver.com

PUBLISHED IN CIRCUIT CELLAR MAGAZINE • DECEMBER 2021 #377 – Get a PDF of the issue

Arlen Baker

Principal Security Architect at Wind River | + posts

Arlen Baker is the Principal Security Architect in Technology Office at Wind River. Arlen works with customers in the industrial, aerospace, medical, and defense sectors to secure their systems. Since joining Wind River in 2007, Arlen has filed several security-related patents, written whitepapers, and has delivered numerous presentations on the topic of security. Prior to Wind River, Arlen has worked in various technical leadership capacities within the U.S. Department of Defense arena for more than 23 years.

This author does not have any more posts.