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-05.6: Separation of duties (SoD) shall be ensured in the management of access rights. |
|
PR.AA-05.6 |
|
|
http://cyfun.data.gift/data/loc_CyFun2025_Booklet_ESSENTIAL_E_p96 |
|
|
http://cyfun.data.gift/data/loc_CyFun2025_Booklet_IMPORTANT_E_p70 |
|
|
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 no single individual has full control over critical systems or processes by enforcing Separation of Duties (SoD). This should reduce the risk of errors, fraud, and misuse of access rights. To achieve this goal, the organisation should: - Define Separation of Duties - Responsibilities should be divided so that key tasks are performed by different individuals. - SoD should include: - Operational and system support roles should be assigned to different individuals. - System support tasks should require oversight or dual control. - A single person should not initiate and approve the same transaction. - Access control and audit functions should be handled by separate roles. - Manage Access Rights Appropriately - Role-Based Access Control (RBAC) should be used to assign permissions based on job roles. - The principle of least privilege should be applied to limit access to what is strictly necessary. - Access rights should be reviewed regularly, especially for critical systems and high-risk roles. - Separate tools or accounts should be used for administrative and audit functions where feasible. - Apply Controls for System Administrators - Administrative responsibilities should be split to prevent full control by a single individual. - Administrators should use separate accounts for regular and privileged tasks. - All administrative actions should be logged and reviewed by an independent party. - Administrators managing access should not be responsible for auditing that access. - Ensure Feasibility in OT Environments - In OT systems, SoD should be adapted to operational and safety constraints. - Where full separation is not feasible, compensating controls such as dual approval, logging, and external review should be implemented. - Align with ENISA Guidance These practices align with ENISA’s Security Measures for Operators of Essential Services, which highlight the importance of Separation of Duties (SoD) and Role-Based Access Control (RBAC) in reducing access- related risks across ICT and OT environments. |
|
A general note, for any purpose. |
<div><p>The goal of this control is to ensure that no single individual has full control over critical systems or processes by enforcing Separation of Duties (SoD). This should reduce the risk of errors, fraud, and misuse of access rights. To achieve this goal, the organisation should:</p><ul><li>Define Separation of Duties<ul><li>Responsibilities should be divided so that key tasks are performed by different individuals.</li><li>SoD should include:<ul><li>Operational and system support roles should be assigned to different individuals.</li><li>System support tasks should require oversight or dual control.</li><li>A single person should not initiate and approve the same transaction.</li><li>Access control and audit functions should be handled by separate roles.</li></ul></li></ul></li><li>Manage Access Rights Appropriately<ul><li>Role-Based Access Control (RBAC) should be used to assign permissions based on job roles.</li><li>The principle of least privilege should be applied to limit access to what is strictly necessary.</li><li>Access rights should be reviewed regularly, especially for critical systems and high-risk roles.</li><li>Separate tools or accounts should be used for administrative and audit functions where feasible.</li></ul></li><li>Apply Controls for System Administrators<ul><li>Administrative responsibilities should be split to prevent full control by a single individual.</li><li>Administrators should use separate accounts for regular and privileged tasks.</li><li>All administrative actions should be logged and reviewed by an independent party.</li><li>Administrators managing access should not be responsible for auditing that access.</li></ul></li><li>Ensure Feasibility in OT Environments<ul><li>In OT systems, SoD should be adapted to operational and safety constraints.</li><li>Where full separation is not feasible, compensating controls such as dual approval, logging, and external review should be implemented.</li></ul></li><li>Align with ENISA Guidance These practices align with ENISA’s Security Measures for Operators of Essential Services, which highlight the importance of Separation of Duties (SoD) and Role-Based Access Control (RBAC) in reducing access- related risks across ICT and OT environments.</li></ul></div> |
|
A general note, for any purpose. |
The goal of this control is to ensure that no single individual has full control over critical systems or processes by enforcing Separation of Duties (SoD). This should reduce the risk of errors, fraud, and misuse of access rights. To achieve this goal, the organisation should: • Define Separation of Duties o Responsibilities should be divided so that key tasks are performed by different individuals. o SoD should include: - Operational and system support roles should be assigned to different individuals. - System support tasks should require oversight or dual control. - A single person should not initiate and approve the same transaction. - Access control and audit functions should be handled by separate roles. • Manage Access Rights Appropriately o Role-Based Access Control (RBAC) should be used to assign permissions based on job roles. o The principle of least privilege should be applied to limit access to what is strictly necessary. o Access rights should be reviewed regularly, especially for critical systems and high-risk roles. o Separate tools or accounts should be used for administrative and audit functions where feasible. • Apply Controls for System Administrators o Administrative responsibilities should be split to prevent full control by a single individual. o Administrators should use separate accounts for regular and privileged tasks. o All administrative actions should be logged and reviewed by an independent party. o Administrators managing access should not be responsible for auditing that access. • Ensure Feasibility in OT Environments o In OT systems, SoD should be adapted to operational and safety constraints. o Where full separation is not feasible, compensating controls such as dual approval, logging, and external review should be implemented. • Align with ENISA Guidance These practices align with ENISA’s Security Measures for Operators of Essential Services, which highlight the importance of Separation of Duties (SoD) and Role-Based Access Control (RBAC) in reducing access- related risks across ICT and OT environments. |
|
A general note, for any purpose. |
The goal of this control is to ensure that no single individual has full control over critical systems or processes by enforcing Separation of Duties (SoD). This should reduce the risk of errors, fraud, and misuse of access rights. To achieve this goal, the organisation should: - Define Separation of Duties - Responsibilities should be divided so that key tasks are performed by different individuals. - SoD should include: - Operational and system support roles should be assigned to different individuals. - System support tasks should require oversight or dual control. - A single person should not initiate and approve the same transaction. - Access control and audit functions should be handled by separate roles. - Manage Access Rights Appropriately - Role-Based Access Control (RBAC) should be used to assign permissions based on job roles. - The principle of least privilege should be applied to limit access to what is strictly necessary. - Access rights should be reviewed regularly, especially for critical systems and high-risk roles. - Separate tools or accounts should be used for administrative and audit functions where feasible. - Apply Controls for System Administrators - Administrative responsibilities should be split to prevent full control by a single individual. - Administrators should use separate accounts for regular and privileged tasks. - All administrative actions should be logged and reviewed by an independent party. - Administrators managing access should not be responsible for auditing that access. - Ensure Feasibility in OT Environments - In OT systems, SoD should be adapted to operational and safety constraints. - Where full separation is not feasible, compensating controls such as dual approval, logging, and external review should be implemented. - Align with ENISA Guidance These practices align with ENISA’s Security Measures for Operators of Essential Services, which highlight the importance of Separation of Duties (SoD) and Role-Based Access Control (RBAC) in reducing access- related risks across ICT and OT environments. |
|
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-05.6 |
|
skos:prefLabel, skos:altLabel and skos:hiddenLabel are pairwise disjoint properties. |
Separation of duties |
|
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. |
Separation of duties (SoD) shall be ensured in the management of access rights. |
|
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_BASIC_to_IMPORTANT |
|
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. |
|
|
The number of triples associated with the subject. |
19 |
|
Specifies the dataset the subject is part of. |
Resultaten 1 - 21 of 21
Inverse links to the subject.
| Property | Subject |
|---|---|
|
Relates a concept to a concept that is more specific in meaning. |
Resultaten 1 - 1 of 1