data.gift
  • Datasets

http://cyfun.data.gift/data/requirement_PR_AA_02_2

http://cyfun.data.gift/data/requirement_PR_AA_02_2
Concept

  • http://cyfun.data.gift/data/CyFun2025

    • External link
    • Internal link
  • http://cyfun.data.gift/data/CyFun2025_delta_IMPORTANT_to_ESSENTIAL

    • External link
    • Internal link
  • http://cyfun.data.gift/data/CyFun2025_ESSENTIAL

    • External link
    • Internal link

  • http://cyfun.data.gift/data/subcategory_PR.AA-02

    • External link
    • Internal link

Properties and relations

Direct links from the subject.

Property Value

type

The subject is an instance of a class.

  • External link
  • Internal link

http://cyfun.data.gift/ontology#Requirement

  • External link
  • Internal link

type

The subject is an instance of a class.

  • External link
  • Internal link

Concept

An idea or notion; a unit of thought.

  • External link
  • Internal link

label

A human-readable name for the subject.

  • External link
  • Internal link

PR.AA-02.2: The organisation shall ensure that unique credentials are used for each authenti- cated user, device, and process interacting with the organisation's critical systems. These credentials shall be verified, and the unique identifiers shall be captured during system interactions. Exceptions may be made for emergency access ("break- glass" procedures), provided such access is strictly controlled, logged, and reviewed.

http://cyfun.data.gift/ontology#requirementId

  • External link
  • Internal link

PR.AA-02.2

http://cyfun.data.gift/ontology#foundIn

  • External link
  • Internal link

http://cyfun.data.gift/data/loc_CyFun2025_Booklet_ESSENTIAL_E_p87

  • External link
  • Internal link

has broader

Relates a concept to a concept that is more general in meaning.

  • External link
  • Internal link

http://cyfun.data.gift/data/subcategory_PR.AA-02

  • External link
  • Internal link

note

A general note, for any purpose.

  • External link
  • Internal link

The goal of this control is to ensure that each user, device, and process interacting with critical systems is uniquely identifiable and authenticated. This supports accountability, traceability, and secure access, while allowing for controlled exceptions in emergencies. To achieve this goal, the organisation should: - Assign Unique Credentials Each user, device, and automated process should have its own unique credentials. Shared accounts should be avoided. All credentials should be verified before access is granted. - Implement Strong Authentication Multi-Factor Authentication (MFA – PR.AA-03.2) has to be used wherever feasible. Authentication mecha- nisms should be resistant to replay attacks and credential reuse. These practices align with ENISA’s Secure UserAuthentication Guidelines, which recommend layered and context-aware authentication for critical systems. - Enforce Credential Management Practices Password policies and credential rotation should be enforced. Credentials should be reviewed and updated regularly, especially after role changes or offboarding. This supports the principles outlined in ENISA’s NIS2 Technical Implementation Guidance, which emphasise secure identity lifecycle management. - ApplyAccess Control and Monitoring Access should follow the Principle of Least Privilege. Logs and audit trails should be continuously monitored to detect anomalies. Suspicious activity should be investigated promptly. - Control EmergencyAccess ("Break-Glass") Emergency access should be granted only through designated break-glass accounts.These accounts should be tightly controlled, time-limited, fully logged, and reviewed after use. Justification and approval should be required for each instance. - Promote UserAwareness and Training Personnel should be trained on the importance of using individual credentials and reporting suspicious access. Awareness should include the risks of credential sharing and misuse. - Ensure OT-Specific Feasibility In OTenvironments, unique credentials should be implemented in a waythat respects operational constraints and system limitations. Coordination with engineering teams may be required.

note

A general note, for any purpose.

  • External link
  • Internal link

The goal of this control is to ensure that each user, device, and process interacting with critical systems is uniquely identifiable and authenticated. This supports accountability, traceability, and secure access, while allowing for controlled exceptions in emergencies. To achieve this goal, the organisation should: • Assign Unique Credentials Each user, device, and automated process should have its own unique credentials. Shared accounts should be avoided. All credentials should be verified before access is granted. • Implement Strong Authentication Multi-Factor Authentication (MFA – PR.AA-03.2) has to be used wherever feasible. Authentication mecha- nisms should be resistant to replay attacks and credential reuse. These practices align with ENISA’s Secure UserAuthentication Guidelines, which recommend layered and context-aware authentication for critical systems. • Enforce Credential Management Practices Password policies and credential rotation should be enforced. Credentials should be reviewed and updated regularly, especially after role changes or offboarding. This supports the principles outlined in ENISA’s NIS2 Technical Implementation Guidance, which emphasise secure identity lifecycle management. • ApplyAccess Control and Monitoring Access should follow the Principle of Least Privilege. Logs and audit trails should be continuously monitored to detect anomalies. Suspicious activity should be investigated promptly. • Control EmergencyAccess ("Break-Glass") Emergency access should be granted only through designated break-glass accounts.These accounts should be tightly controlled, time-limited, fully logged, and reviewed after use. Justification and approval should be required for each instance. • Promote UserAwareness and Training Personnel should be trained on the importance of using individual credentials and reporting suspicious access. Awareness should include the risks of credential sharing and misuse. • Ensure OT-Specific Feasibility In OTenvironments, unique credentials should be implemented in a waythat respects operational constraints and system limitations. Coordination with engineering teams may be required.

note

A general note, for any purpose.

  • External link
  • Internal link

The goal of this control is to ensure that each user, device, and process interacting with critical systems is uniquely identifiable and authenticated. This supports accountability, traceability, and secure access, while allowing for controlled exceptions in emergencies. To achieve this goal, the organisation should: - Assign Unique Credentials Each user, device, and automated process should have its own unique credentials. Shared accounts should be avoided. All credentials should be verified before access is granted. - Implement Strong Authentication Multi-Factor Authentication (MFA – PR.AA-03.2) has to be used wherever feasible. Authentication mecha- nisms should be resistant to replay attacks and credential reuse. These practices align with ENISA’s Secure UserAuthentication Guidelines, which recommend layered and context-aware authentication for critical systems. - Enforce Credential Management Practices Password policies and credential rotation should be enforced. Credentials should be reviewed and updated regularly, especially after role changes or offboarding. This supports the principles outlined in ENISA’s NIS2 Technical Implementation Guidance, which emphasise secure identity lifecycle management. - ApplyAccess Control and Monitoring Access should follow the Principle of Least Privilege. Logs and audit trails should be continuously monitored to detect anomalies. Suspicious activity should be investigated promptly. - Control EmergencyAccess ("Break-Glass") Emergency access should be granted only through designated break-glass accounts.These accounts should be tightly controlled, time-limited, fully logged, and reviewed after use. Justification and approval should be required for each instance. - Promote UserAwareness and Training Personnel should be trained on the importance of using individual credentials and reporting suspicious access. Awareness should include the risks of credential sharing and misuse. - Ensure OT-Specific Feasibility In OTenvironments, unique credentials should be implemented in a waythat respects operational constraints and system limitations. Coordination with engineering teams may be required.

note

A general note, for any purpose.

  • External link
  • Internal link

<div><p>The goal of this control is to ensure that each user, device, and process interacting with critical systems is uniquely identifiable and authenticated. This supports accountability, traceability, and secure access, while allowing for controlled exceptions in emergencies. To achieve this goal, the organisation should:</p><ul><li>Assign Unique Credentials Each user, device, and automated process should have its own unique credentials. Shared accounts should be avoided. All credentials should be verified before access is granted.</li><li>Implement Strong Authentication Multi-Factor Authentication (MFA – PR.AA-03.2) has to be used wherever feasible. Authentication mecha- nisms should be resistant to replay attacks and credential reuse. These practices align with ENISA’s Secure UserAuthentication Guidelines, which recommend layered and context-aware authentication for critical systems.</li><li>Enforce Credential Management Practices Password policies and credential rotation should be enforced. Credentials should be reviewed and updated regularly, especially after role changes or offboarding. This supports the principles outlined in ENISA’s NIS2 Technical Implementation Guidance, which emphasise secure identity lifecycle management.</li><li>ApplyAccess Control and Monitoring Access should follow the Principle of Least Privilege. Logs and audit trails should be continuously monitored to detect anomalies. Suspicious activity should be investigated promptly.</li><li>Control EmergencyAccess ("Break-Glass") Emergency access should be granted only through designated break-glass accounts.These accounts should be tightly controlled, time-limited, fully logged, and reviewed after use. Justification and approval should be required for each instance.</li><li>Promote UserAwareness and Training Personnel should be trained on the importance of using individual credentials and reporting suspicious access. Awareness should include the risks of credential sharing and misuse.</li><li>Ensure OT-Specific Feasibility In OTenvironments, unique credentials should be implemented in a waythat respects operational constraints and system limitations. Coordination with engineering teams may be required.</li></ul></div>

notation

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.

  • External link
  • Internal link

PR.AA-02.2

alternative label

skos:prefLabel, skos:altLabel and skos:hiddenLabel are pairwise disjoint properties.

  • External link
  • Internal link

Unique credential enforcement

preferred label

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.

  • External link
  • Internal link

The organisation shall ensure that unique credentials are used for each authenti- cated user, device, and process interacting with the organisation's critical systems. These credentials shall be verified, and the unique identifiers shall be captured during system interactions. Exceptions may be made for emergency access ("break- glass" procedures), provided such access is strictly controlled, logged, and reviewed.

is in scheme

Relates a resource (for example a concept) to a concept scheme in which it is included.

  • External link
  • Internal link

http://cyfun.data.gift/data/CyFun2025

  • External link
  • Internal link

is in scheme

Relates a resource (for example a concept) to a concept scheme in which it is included.

  • External link
  • Internal link

http://cyfun.data.gift/data/CyFun2025_delta_IMPORTANT_to_ESSENTIAL

  • External link
  • Internal link

is in scheme

Relates a resource (for example a concept) to a concept scheme in which it is included.

  • External link
  • Internal link

http://cyfun.data.gift/data/CyFun2025_ESSENTIAL

  • External link
  • Internal link

http://cyfun.data.gift/ontology#level

  • External link
  • Internal link

http://cyfun.data.gift/data/level_ESSENTIAL

  • External link
  • Internal link

triple count

The number of triples associated with the subject.

  • External link
  • Internal link

17

in dataset

Specifies the dataset the subject is part of.

  • External link
  • Internal link

http://data.gift/d/datasets/69E8863AA6CE46D9ACD13109

  • External link
  • Internal link

Resultaten 1 - 19 of 19

References

Inverse links to the subject.

Property Subject

http://cyfun.data.gift/ontology#hasRequirement

  • External link
  • Internal link

http://cyfun.data.gift/data/subcategory_PR.AA-02

  • External link
  • Internal link

has narrower

Relates a concept to a concept that is more specific in meaning.

  • External link
  • Internal link

http://cyfun.data.gift/data/subcategory_PR.AA-02

  • External link
  • Internal link

Resultaten 1 - 1 of 1

© 2024 redpencil.io. All rights reserved.