Threats Section - commoncriteria/pp-template GitHub Wiki
Updated 11 June 2025
CC:2022: "The SPD describes the threats that are to be countered by the TOE, its operational environment, or a combination of the two. A threat consists of an adverse action performed by a threat agent on an asset. Adverse actions influence one or more properties of an asset from which that asset derives its value."
The Threats element can be defined in the usual three ways:
<section title="Threats" id="sec-uniqueId">
<sec:Threats>
<sec:threats title="Threats">In XML, the threats section consists of a <threats> element that contains one or more <threat> elements.
Each <threat> element has a name attribute and an optional id. The id is only needed if there is a reason to refer to the threat by other than its name elsewhere in the document. Which is very unlikely.
The threat name should be of the form T.THREATNAME where the threat name is unique in the document. Ideally, threat names should be common across all PPs so that they can be maintained in a library. So you should try to use threats that you've seen before.
In standard approach documents, each threat includes a description of the threat, a reference to one or more Objectives, and a rationale explaining how the Objective addresses the threat. The rationale is used to auto-generate the Security Objectives Rationale section.
<threat name="T.UPDATE_COMPROMISE">
<description>An attacker may attempt to provide a compromised update of TOE firmware.
Such updates can undermine the security functionality of the device if they are
unauthorized, unauthenticated, or are improperly validated using non-secure or
weak cryptography.</description>
<objective-refer ref="O.UPDATE_INTEGRITY">
<rationale>The threat T.UPDATE_COMPROMISE is countered by O.UPDATE_INTEGRITY as this
objective supports ensuring that platform firmware updates are authentic and
properly validated prior to installation.</rationale>
</objective-refer>
<objective-refer ref="O.STRONG_CRYPTOGRAPHY">
<rationale>The threat T.UPDATE_COMPROMISE is countered by O.STRONG_CRYPTOGRAPHY as this
objective supports use of proven, standards-based cryptographic mechanisms
for ensuring that updates are authentic and maintain their integrity.</rationale>
</objective-refer>
<objective-refer ref="O.ATTACK_DETECTION_AND_RESPONSE">
<rationale>The threat T.UPDATE_COMPROMISE is countered by O.ATTACK_DETECTION_AND_RESPONSE as this
objective supports detection and reporting of attempts to compromise the TOE.</rationale>
</objective-refer>
</threat>In Direct Rationale approach documents, each threat includes a description of the threat, mappings to the SFRs that address the threat, and a rationale explaining how the SFRs addresses the threat. The rationale is used to auto-generate the TOE Security Functional Requirements Rationale section, which is where the mapping of threats to SFRs is displayed.
<threat name="T.UPDATE_COMPROMISE">
<description>An attacker may attempt to provide a compromised update of TOE firmware.
Such updates can undermine the security functionality of the device if they are
unauthorized, unauthenticated, or are improperly validated using non-secure or
weak cryptography.</description>
<addressed-by>FCS_CKM_EXT.2 (when GPOS PP is Base-PP)</addressed-by>
<rationale>This SFR addresses the threat by requiring the TOE
to store sensitive data in the OS’ key storage.</rationale>
<addressed-by>FCS_CKM_EXT.2 (when App PP is Base-PP)</addressed-by>
<rationale>This SFR addresses the threat by requiring the TOE
or its platform to store sensitive data in the OS' key storage.</rationale>
<addressed-by>FCS_CKM_EXT.4 (when App PP is Base-PP)</addressed-by>
<rationale>This SFR addresses the threat by requiring the TOE
or its platform to zeroize key data when no longer needed.</rationale>
<addressed-by>FDP_RIP.2</addressed-by>
<rationale>This SFR addresses the threat by requiring the TOE or its platform to ensure that
residual data is purged from the system.</rationale>
</threat>The <from> tag is used to indicate that a PP-Module inherits a threat from a Base PP. Starting now, inherited threats are documented in the Threats section along with the threats that are specific to the PP-Module (in the past inherited threats were not displayed). If an inherited threat does not include a <description> tag, a boilerplate description is output. Naturally, the remainder of the information appears in the TOE Security Functional Requirements Rationale table.
<threat name="T.UNAUTHORIZED_ADMINISTRATOR_ACCESS">
<from base="ND"/>
<description>This threat from the Network Device cPP also applies to the functionality defined in this PP-Module.</description>
<addressed-by>FAU_GEN.1/AuthSvr</addressed-by>
<rationale>
Mitigates the threat by implementing an audit mechanism to detect potential misuse of the TOE.
</rationale>
<addressed-by>FCS_CKM.3</addressed-by>
<rationale>
Mitigates the threat by implementing a cryptographic key access control mechanism to prevent compromise
of the data in transit confidentiality mechanisms.
</rationale>
<addressed-by>FCS_STG_EXT.1</addressed-by>
<rationale>
Mitigates the threat by implementing a secure cryptographic key storage mechanism to prevent compromise
of the data in transit confidentiality mechanisms.
</rationale>
</threat>It is possible to inherit a single threat from more than one Base PP. To indicate this you simply add more than one <from> tag. And you can add a separate description for each <from> tag, or you can use a single description to cover all the Base PPs. Or you can probably do both (yes, you can have three descriptions if you really enjoy describing things). But there should be but one set of <addressed-by> SFRs for each threat.
<threat name="T.UNAUTHORIZED_ADMINISTRATOR_ACCESS">
<from base="ND"/>
<from base="mdf"/>
<description>This threat from the Network Device cPP and Mobile Device PP also applies to the functionality defined in this PP-Module. </description>
<addressed-by>FAU_GEN.1/AuthSvr</addressed-by>
....
</threat>