Building security and privacy into product development is more critical today than ever before. First introduced through the Microsoft Trustworthy Computing initiative in the early 2000s, the well-known security development lifecycle (SDL) is a framework designed to do just that. It was originally devised to enhance software security, but an SDL process can and should be applied to all types of products to help root out security and privacy vulnerabilities, while establishing long-term resilience in the rapidly evolving threat landscape.

At Intel, for instance, we’ve taken a holistic approach to SDL, customizing the process to address the highly integrated nature of hardware, firmware and software development. Why? Security researchers and bad actors alike are increasingly focused on trying to identify hardware vulnerabilities. Additionally, hardware security presents a pair of inherent challenges not found in software. First, hardware development cycles are generally longer and more complex due to the various coordination required across the manufacturing process, requirements for specialized components, testing processes in diverse conditions and more. Second, hardware updates are often far more difficult because of physical limitations to the amount of code that fits in a piece of hardware, constant uptime requirements, integration with firmware or software, etc.

These two obstacles mean hardware engineers must place an emphasis on security during product development, and actively work to anticipate new usage models and potential threats years in advance. In order to build and support more secure hardware products, consider the following best practices across each stage of the security development lifecycle (SDL):

1. Planning and Assessment – Start by having security experts interview product architects with the goal of helping the project team identify the necessary security tasks and processes across the development cycle. In this stage, your team should map out and assign cryptography and privacy reviews, as well as other architectural assessments. For hardware specifically, it’s important to carefully plan and execute security assurance appraisals for any third-party components and intellectual property (IP). Conducting a thorough risk assessment up front can help you avoid designing for or purchasing third-party IP from an untrustworthy source or that has been compromised at some point within the supply chain. Failing to take this initial step when planning your product could leave it open to major vulnerabilities you must patch retroactively (which can be an immensely complex, time-consuming and costly proposition for hardware systems).

2. Architecture – Next, it’s time to develop your architectural specifications. Once specs have been finalized and sent off to the design team, any undetected security gaps become much harder to address. So here it is critical that security architects and developers work together to define security objectives, build an appropriate threat model and document product security and privacy requirements. Your team should complete every review laid out in the planning and assessment process, while architects follow secure design principles (such as least privilege, fail safely and securely, defense in depth, zero trust, etc.) throughout this process. By conducting due diligence in the hardware architecture phase, you can often identify and resolve hardware security or privacy issues that would otherwise take months (and sometimes even years) of re-architecture, design, validation, production and distribution to address.  

3. Design – In this phase, your team will want to ensure that the product design satisfies all the architectural specifications defined in the previous phase. Hardware validation experts should take the lead on defining your security and privacy validation strategy, using appropriate hardware tools (which vary based on your industry), security test plans and regression testing to achieve confidence that the product design meets all architectural requirements.  

4. Implementation – Now you’ll need to work to ensure that product implementation addresses the threat models defined in the architecture phase, and that the development team is on track to deliver a trustworthy product. In this phase, you’ll perform manual secure code reviews and static code analysis as appropriate to identify any hardware issues, such as register transfer level (RTL) issues. Establish formal verification for implemented mitigations against glitching attacks and other threats, and help confirm that all aspects of the product are performing as designed and architected. The team should also spend time verifying and accounting for any necessary updates to the SDL and formal security validation plan (to address any new findings or updated test requirements) to execute on in the next phase.

5. Security Validation – When done successfully, the security validation stage can help account for known and emerging threats and risks, and even help anticipate unknown vulnerabilities. Throughout this process, the product team should execute and document a variety of security and privacy analyses as appropriate, including penetration testing, fuzzing exercises and more. From a hardware security perspective, it’s important to conduct physical attack assessments to help ensure your product isn’t open to clock glitching attacks, denial of service or other attack types. Any bugs you identify during validation should be triaged and addressed prior to release. At this point, your team should be able to make a strong recommendation whether or not to ship a product, since you will have information regarding whether the product is clear of known risks, meets security requirements and is supported with an appropriate survivability plan.

6. Release and Post Deployment – When releasing hardware, the goals include delivering a trustworthy product that can be effectively supported throughout its lifecycle. This entails evaluating and updating third-party hardware components and IP to account for known vulnerabilities, working to eliminate any malware from the release package, and putting a plan in place for product support, hardware patch contingencies (via firmware or software) and survivability.

In today’s dynamic threat landscape, both researchers and bad actors will continue to devote more time and energy toward cracking hardware products and with the complexity of modern computer systems, absolute security is not guaranteed. But now more than ever, the industry must make a committed effort to continuously improve the quality, security and privacy of new hardware products. This starts with a “security first” mindset and a commitment to applying SDL principles throughout each stage of hardware development, in addition to firmware and software. As more organizations take this proactive approach and leverage the above best practices, the industry as a whole can find and resolve potential hardware vulnerabilities earlier, and deliver products that offer the level of security, privacy and resilience required today.