Direct links from the subject.
| Property | Value |
|---|---|
|
The subject is an instance of a class. |
|
|
The subject is an instance of a class. |
An idea or notion; a unit of thought. |
|
A human-readable name for the subject. |
PR.AA-04.1: Identity assertions shall be protected, conveyed, and verified |
|
PR.AA-04.1 |
|
|
http://cyfun.data.gift/data/loc_CyFun2025_Booklet_ESSENTIAL_E_p92 |
|
|
Relates a concept to a concept that is more general in meaning. |
|
|
A general note, for any purpose. |
The goal of this control is to ensure that identity assertions — claims about the identity of a user, device, or process — are protected against tampering, securely transmitted, and reliably verified before granting access to critical systems or data. Definition: An identity assertion is a digital statement used during authentication that confirms the identity of auser,device,orprocess.Ittypicallyincludesinformationsuchastheidentityprovider,authenticationmethod, and validity period, and is used to grant access to systems or services. To achieve this goal, the organisation should: - Protect IdentityAssertions Identity assertions should be protected from tampering, theft, or misuse. Strong encryption (e.g. TLS 1.2 or higher) and digital signatures should be applied. Identity providers should complywith the eIDAS Regulation (e.g. itsme®, SPID, FranceConnect). These practices align with ENISA’s Digital Identity and Trust Services guidance. - Convey IdentityAssertions Securely Identitydata should be transmitted using secure protocols such as SAML2.0 orOpenID Connect.Token expo- sure in URLs should be avoided; HTTP headers or POST methods should be used. For cross-border identity federation, eIDAS nodes should be used to ensure secure interoperability between EU member states. - Verify IdentityAssertions All assertions should be validated before access is granted. This includes verifying digital signatures using trusted certificate authorities listed in the EU Trusted List (EUTL), checking token claims (issuer, audience, expiration), and validating against eIDAS metadata. Qualified Trust Service Providers (QTSPs) should be used for issuing and verifying identity credentials. - Ensure OT-Specific Feasibility In OT environments, identity assertions should be integrated into secure access gateways or jump servers. Where direct integration is not feasible, identityverification should occur at the interface layer, with logging and monitoring in place. - Align with ENISA Guidance These practices are supported by ENISA’s NIS2 Technical Implementation Guidance and its work on secure digital identity frameworks under the eIDAS and European Digital Identity regulations. |
|
A general note, for any purpose. |
The goal of this control is to ensure that identity assertions — claims about the identity of a user, device, or process — are protected against tampering, securely transmitted, and reliably verified before granting access to critical systems or data. Definition: An identity assertion is a digital statement used during authentication that confirms the identity of auser,device,orprocess.Ittypicallyincludesinformationsuchastheidentityprovider,authenticationmethod, and validity period, and is used to grant access to systems or services. To achieve this goal, the organisation should: • Protect IdentityAssertions Identity assertions should be protected from tampering, theft, or misuse. Strong encryption (e.g. TLS 1.2 or higher) and digital signatures should be applied. Identity providers should complywith the eIDAS Regulation (e.g. itsme®, SPID, FranceConnect). These practices align with ENISA’s Digital Identity and Trust Services guidance. • Convey IdentityAssertions Securely Identitydata should be transmitted using secure protocols such as SAML2.0 orOpenID Connect.Token expo- sure in URLs should be avoided; HTTP headers or POST methods should be used. For cross-border identity federation, eIDAS nodes should be used to ensure secure interoperability between EU member states. • Verify IdentityAssertions All assertions should be validated before access is granted. This includes verifying digital signatures using trusted certificate authorities listed in the EU Trusted List (EUTL), checking token claims (issuer, audience, expiration), and validating against eIDAS metadata. Qualified Trust Service Providers (QTSPs) should be used for issuing and verifying identity credentials. • Ensure OT-Specific Feasibility In OT environments, identity assertions should be integrated into secure access gateways or jump servers. Where direct integration is not feasible, identityverification should occur at the interface layer, with logging and monitoring in place. • Align with ENISA Guidance These practices are supported by ENISA’s NIS2 Technical Implementation Guidance and its work on secure digital identity frameworks under the eIDAS and European Digital Identity regulations. |
|
A general note, for any purpose. |
The goal of this control is to ensure that identity assertions — claims about the identity of a user, device, or process — are protected against tampering, securely transmitted, and reliably verified before granting access to critical systems or data. Definition: An identity assertion is a digital statement used during authentication that confirms the identity of auser,device,orprocess.Ittypicallyincludesinformationsuchastheidentityprovider,authenticationmethod, and validity period, and is used to grant access to systems or services. To achieve this goal, the organisation should: - Protect IdentityAssertions Identity assertions should be protected from tampering, theft, or misuse. Strong encryption (e.g. TLS 1.2 or higher) and digital signatures should be applied. Identity providers should complywith the eIDAS Regulation (e.g. itsme®, SPID, FranceConnect). These practices align with ENISA’s Digital Identity and Trust Services guidance. - Convey IdentityAssertions Securely Identitydata should be transmitted using secure protocols such as SAML2.0 orOpenID Connect.Token expo- sure in URLs should be avoided; HTTP headers or POST methods should be used. For cross-border identity federation, eIDAS nodes should be used to ensure secure interoperability between EU member states. - Verify IdentityAssertions All assertions should be validated before access is granted. This includes verifying digital signatures using trusted certificate authorities listed in the EU Trusted List (EUTL), checking token claims (issuer, audience, expiration), and validating against eIDAS metadata. Qualified Trust Service Providers (QTSPs) should be used for issuing and verifying identity credentials. - Ensure OT-Specific Feasibility In OT environments, identity assertions should be integrated into secure access gateways or jump servers. Where direct integration is not feasible, identityverification should occur at the interface layer, with logging and monitoring in place. - Align with ENISA Guidance These practices are supported by ENISA’s NIS2 Technical Implementation Guidance and its work on secure digital identity frameworks under the eIDAS and European Digital Identity regulations. |
|
A general note, for any purpose. |
<div><p>The goal of this control is to ensure that identity assertions — claims about the identity of a user, device, or process — are protected against tampering, securely transmitted, and reliably verified before granting access to critical systems or data. Definition: An identity assertion is a digital statement used during authentication that confirms the identity of auser,device,orprocess.Ittypicallyincludesinformationsuchastheidentityprovider,authenticationmethod, and validity period, and is used to grant access to systems or services. To achieve this goal, the organisation should:</p><ul><li>Protect IdentityAssertions Identity assertions should be protected from tampering, theft, or misuse. Strong encryption (e.g. TLS 1.2 or higher) and digital signatures should be applied. Identity providers should complywith the eIDAS Regulation (e.g. itsme®, SPID, FranceConnect). These practices align with ENISA’s Digital Identity and Trust Services guidance.</li><li>Convey IdentityAssertions Securely Identitydata should be transmitted using secure protocols such as SAML2.0 orOpenID Connect.Token expo- sure in URLs should be avoided; HTTP headers or POST methods should be used. For cross-border identity federation, eIDAS nodes should be used to ensure secure interoperability between EU member states.</li><li>Verify IdentityAssertions All assertions should be validated before access is granted. This includes verifying digital signatures using trusted certificate authorities listed in the EU Trusted List (EUTL), checking token claims (issuer, audience, expiration), and validating against eIDAS metadata. Qualified Trust Service Providers (QTSPs) should be used for issuing and verifying identity credentials.</li><li>Ensure OT-Specific Feasibility In OT environments, identity assertions should be integrated into secure access gateways or jump servers. Where direct integration is not feasible, identityverification should occur at the interface layer, with logging and monitoring in place.</li><li>Align with ENISA Guidance These practices are supported by ENISA’s NIS2 Technical Implementation Guidance and its work on secure digital identity frameworks under the eIDAS and European Digital Identity regulations.</li></ul></div> |
|
A notation, also known as classification code, is a string of characters such as "T58.5" or "303.4833" used to uniquely identify a concept within the scope of a given concept scheme. |
PR.AA-04.1 |
|
skos:prefLabel, skos:altLabel and skos:hiddenLabel are pairwise disjoint properties. |
Identity assertion protection |
|
A resource has no more than one value of skos:prefLabel per language tag, and no more than one value of skos:prefLabel without language tag. |
Identity assertions shall be protected, conveyed, and verified |
|
Relates a resource (for example a concept) to a concept scheme in which it is included. |
|
|
Relates a resource (for example a concept) to a concept scheme in which it is included. |
http://cyfun.data.gift/data/CyFun2025_delta_IMPORTANT_to_ESSENTIAL |
|
Relates a resource (for example a concept) to a concept scheme in which it is included. |
|
|
The number of triples associated with the subject. |
17 |
|
Specifies the dataset the subject is part of. |
Resultaten 1 - 19 of 19
Inverse links to the subject.
| Property | Subject |
|---|---|
|
Relates a concept to a concept that is more specific in meaning. |
Resultaten 1 - 1 of 1