Security Requirements & Compliance Targets

Stages

2. Threat Modelling & Attack Surface Analysis^A
3. Security Requirements & Compliance Targets (this stage)^A
4. Security Architecture^A

Product and assurance milestones

• Assurance and compliance plan agreed (AP)

Security engineering milestones

• Security objectives agreed (OA)
• Threat model baselined (TM)
• Security requirements baselined (RB)
• Security architecture approved (AA)

Disciplines

• Product security management^A
  • Threat Modelling & Attack Surface Analysis: maturity 0.3, Outlined. Security priorities set from the threat model; the review board has held its first review and the assurance targets are outlined.
  • Security Requirements & Compliance Targets: maturity 0.3, Outlined. Security priorities set from the threat model; the review board has held its first review and the assurance targets are outlined.
  • Security Architecture: maturity 0.5, Analysed. Requirements, assurance plan and security architecture reviewed by the board; residual risks listed with owners.
• Threat analysis and risk assessment^A
  • Threat Modelling & Attack Surface Analysis: maturity 0.5, Analysed. Threat model analysed and baselined: attack paths rated for every asset and each high risk given a treatment; the requirements and the architecture are checked against it.; Threat model approved (milestone for one item)
  • Security Requirements & Compliance Targets: maturity 0.5, Analysed. Threat model analysed and baselined: attack paths rated for every asset and each high risk given a treatment; the requirements and the architecture are checked against it.
  • Security Architecture: maturity 0.5, Analysed. Threat model analysed and baselined: attack paths rated for every asset and each high risk given a treatment; the requirements and the architecture are checked against it.
• Security architecture^A
  • Threat Modelling & Attack Surface Analysis: maturity 0.0, Planned. Architecture questions raised in threat modelling: the assets that need a root of trust and the trust boundaries to respect, with the architecture effort estimated; no option drawn yet.
  • Security Requirements & Compliance Targets: maturity 0.3, Outlined. Root of trust, trust domains and isolation options outlined against the draft requirements and the chip architecture.
  • Security Architecture: maturity 0.5, Analysed. Security architecture approved: every requirement allocated to an element, and the root of trust, boot chain, key hierarchy and lifecycle states specified.; Security architecture approved (milestone for one item)
• Cryptography and countermeasures^A
  • Threat Modelling & Attack Surface Analysis: maturity 0.0, Planned. Cryptographic needs noted from the threat model: which assets need confidentiality, integrity or authentication, and whether side-channel and fault resistance are in scope; no algorithm chosen yet.
  • Security Requirements & Compliance Targets: maturity 0.3, Outlined. Algorithms, key sizes and random number needs outlined from the draft requirements, enough to classify the cryptographic functions for export.
  • Security Architecture: maturity 0.5, Analysed. Cryptographic design, key management and countermeasure specifications approved: each side-channel and fault threat has a countermeasure or an accepted risk.^A
• Secure hardware design^D
  • Threat Modelling & Attack Surface Analysis: maturity 0.0, Planned. Security hardware scope estimated from the assets: the blocks the root of trust, fuses and isolation will need, and whether security IP will be bought; no block outlined yet.
  • Security Requirements & Compliance Targets: maturity 0.3, Outlined. Root of trust, fuse controller and isolation blocks outlined; candidate security IP and its provenance evidence listed.
  • Security Architecture: maturity 0.5, Analysed. Block structure and interfaces fixed with the approved architecture; security IP chosen and its provenance checked; RTL started.
• Security firmware and secure boot^D
  • Threat Modelling & Attack Surface Analysis: maturity 0.0, Planned. Boot and update needs noted from the threat model: what the boot chain must protect, how updates must be authenticated and a first estimate of the firmware effort; no boot flow yet.
  • Security Requirements & Compliance Targets: maturity 0.3, Outlined. Secure boot flow, update and anti-rollback approach outlined against the draft requirements.
  • Security Architecture: maturity 0.5, Analysed. Secure boot specification approved with the architecture; the structure of the boot ROM code and security firmware set and coding started.
• Security verification^A
  • Threat Modelling & Attack Surface Analysis: maturity 0.0, Planned. Verification approach agreed with the threat model: which threats need formal proof, negative tests or fault injection, with the effort and tools to budget; no traceability yet.
  • Security Requirements & Compliance Targets: maturity 0.3, Outlined. Traceability matrix started: each requirement linked to its threat, with a verification method outlined.
  • Security Architecture: maturity 0.5, Analysed. Security verification plan approved: properties, negative and abuse tests, fault models and the environment structure defined for every requirement.
• Secure debug and test access^A
  • Threat Modelling & Attack Surface Analysis: maturity 0.0, Planned. Debug and test ports listed as attack paths in the threat model, and the need for authenticated debug and lifecycle states agreed; no access design yet.
  • Security Requirements & Compliance Targets: maturity 0.3, Outlined. Debug and test access paths, and the lifecycle states that open or close them, outlined from the draft requirements.
  • Security Architecture: maturity 0.5, Analysed. Debug and lifecycle state specification approved: the test, debug and key access of each state defined, and every transition one way or authenticated.
• Security evaluation and penetration testing^O
  • Security Requirements & Compliance Targets: maturity 0.0, Planned. Attack testing scope agreed with the requirements: the attack potential to test against, whether an outside laboratory is needed, and the samples and rigs to budget; no test strategy yet.
  • Security Architecture: maturity 0.3, Outlined. Attack test strategy outlined from the threat model and the draft architecture: which attacks, at which attack potential, on which samples.
• Supply chain security and provisioning^A
  • Security Requirements & Compliance Targets: maturity 0.0, Planned. Provisioning needs taken from the requirements: which keys and identities each part needs, the sites that will handle them and a first cost estimate; no flow outlined yet.
  • Security Architecture: maturity 0.3, Outlined. Provisioning flow outlined from the key management specification: where keys are generated, injected and recorded, and which sites handle secrets.
• Certification and assurance^A
  • Threat Modelling & Attack Surface Analysis: maturity 0.0, Planned. Schemes the target markets expect listed, with a first estimate of evaluation cost and time; no scheme or laboratory chosen yet.
  • Security Requirements & Compliance Targets: maturity 0.3, Outlined. Schemes, target assurance levels and the evaluation laboratory chosen; the evidence each scheme needs outlined.
  • Security Architecture: maturity 0.3, Outlined. Schemes, target assurance levels and the evaluation laboratory chosen; the evidence each scheme needs outlined.
• Regulatory and export compliance^A
  • Threat Modelling & Attack Surface Analysis: maturity 0.0, Planned. Target markets confirmed and the security regulations that may apply to each identified for review, with the export questions the cryptography will raise noted; nothing classified yet.
  • Security Requirements & Compliance Targets: maturity 0.3, Outlined. Security regulations and export rules for each target market listed; the cryptographic functions classified for export.
  • Security Architecture: maturity 0.3, Outlined. Security regulations and export rules for each target market listed; the cryptographic functions classified for export.