A security maturity model for hardware development


With systems becoming more sophisticated, the potential for new semiconductor vulnerabilities continues to grow. Consumers and hardware partners rely on organizations to meet their due diligence obligations to ensure security-sensitive design assets are secure when products are shipped. This is an iterative process, so a security maturity model is an essential part of getting it right.

Companies have always focused their attention and investments on securing the software used in their devices, not the underlying hardware. But failure to develop a comprehensive approach that fixes hardware vulnerabilities early on means there is no ongoing mitigation of hardware security weaknesses. This shortfall can expose organizations to costly hardware security surprises after production or even in the later stages of system integration and development.

Fig. 1: Identifying security issues early reduces costs and risks.

However, creating a mature, comprehensive, in-process hardware security program takes time and is a process that goes beyond a single product design lifecycle. It’s a journey.

Knowing where to start and what goals to set can also be difficult. To make it easier for you, the Cycuity team has identified and defined four levels that you can use to assess your current capabilities and take incremental steps toward an end-to-end hardware security verification program.

Level 01 – Fundamental

The first level starts with creating security requirements and implementing specific features to meet them. Next, organizations must ensure that they properly integrate, configure, and verify these security features, including third-party and internal security IP addresses.

Level 01 – Checklist:

  • Establish and document security feature requirements
  • Implement hardware security features to meet requirements
  • Apply functional verification to validate that hardware security features are working

Ultimately, at this stage, the security functionality requirements should be clearly defined, allowing stakeholders to align with the protection needs of the end product, and then functionally verify their implementation.

Level 02 – Basic

In the next phase, it’s time to start proactively doing basic development and validation of security verification requirements. Organizations will also strengthen the maturity of their security documentation at this level by documenting threat models and security verification requirements.

Level 02 – Checklist:

  • Establish and document security verification requirements and threat model
  • Identify and implement hardware protection mechanisms to counter potential threats
  • Apply ad-hoc best-effort security validation for part of the requirements

Listing all security verification requirements at this level will allow organizations to proactively identify security vulnerabilities earlier in the design process before they become serious “security surprises” that lead to costly responses and missed deadlines.

Level 03 – Advanced

SoC integration and configuration can introduce a security weakness during the design lifecycle. At this point, it’s essential to start becoming more systematic when checking hardware security. Ensuring that there are no unmitigated security vulnerabilities when implementing security features reduces risk. Nevertheless, security weaknesses manifest themselves in the interactions between components, so verification efforts should evolve the entire system and be performed periodically.

Level 03 – Checklist:

  • Develop and implement a security audit plan that encompasses all security audit requirements that have been established and documented
  • Regularly and systematically apply security verification during the design lifecycle
  • Document the results of the security verification process before the tape-out

A fully integrated security verification program will also help you when exiting tape. It allows teams and organizations to confidently demonstrate that they have made an effort to detect and correct the broadest set of potential hardware weaknesses before signing on and that all hardware security requirements have been met.

Level 04 – Complete

The final key area, and another difficult one to address, is the introduction of a metrics-driven approach that transforms the program into one that provides and demonstrates end-to-end holistic governance.

Level 03 – Checklist:

  • Establish, track and report on security measures around verification, including coverage of industry standards such as:
  • Ensure that security governance extends from requirements to registration for manufacturing
  • Mandate full compliance with all security verification requirements by requiring security approval

Introducing metrics is very effective in measuring the status of a security program and tracking progress towards a well-defined exit from tape. However, the benefits of this process extend beyond a team or an organization. With external stakeholders, such as partners or certification services more concerned than ever with device security, this approach provides a foundation to demonstrate that an organization is developing semiconductor chips with a framework and processes that verify firmly their security.

Advancing Hardware Security Maturity with the Help of Cycuity

Cycuity offers best practice solutions and services to support customers at all stages of their hardware security maturity journey, helping them to:

  • Define comprehensive and verifiable security requirements.
  • Automate security verification during all phases of chip development.
  • Make data-driven approval decisions, backed by full traceability.

By sufficiently maturing a hardware security maturity program, organizations can discover and mitigate issues before the silicon and demonstrate their commitment to developing reliable electronics products for external partners and consumers.

Learn more about advance the maturity of your hardware security program.

Jim Robinson

(All posts)

Jim Robinson is Director of Security Application Engineering at Cycuity.


About Author

Comments are closed.