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.3: A ccess rights, privileges and authorisations shall be restricted to the systems and specific information needed to perform the tasks (the principle of Least Privilege). |
|
PR.AA-05.3 |
|
|
http://cyfun.data.gift/data/loc_CyFun2025_Booklet_ESSENTIAL_E_p94 |
|
|
http://cyfun.data.gift/data/loc_CyFun2025_Booklet_BASIC_E_p29 |
|
|
http://cyfun.data.gift/data/loc_CyFun2025_Booklet_IMPORTANT_E_p67 |
|
|
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 access rights, privileges, and authorisations are restricted to only the systems and specific information needed to perform assigned tasks, following the principle of least privilege. To achieve this goal, the following should be considered: - Apply Least Privilege - Access rights should be limited to the minimum necessary for users, systems, and services. - Accounts should start with low privileges, and be elevated only when justified. - Just-in-time access should be used to limit the duration of elevated privileges. - Define and Manage Permissions - Access rights should be clearly defined based on roles and responsibilities. - An inventory of accounts and their permissions should be maintained and kept up to date. - Separate accounts should be used for contractors and third parties to ensure traceability. - Enforce Access Controls - Role-based or attribute-based access control models should be implemented where feasible. - Internet access points and external connections should be limited to what is strictly necessary. - Harden Systems - Systems should be hardened to support access control by: - Disabling unused ports and services - Restricting Bluetooth where not needed - Limiting legacy protocols such as FTP unless securely configured - Review and Adapt Access - Access rights should be reviewed regularly and adjusted based on role changes, project completion, or security assessments. - Access should be revoked immediately when no longer needed. - OT-Specific Considerations In OT environments, access control should still follow the principle of least privilege. Where technical limita- tions exist, previously defined OT access control measures (see PR.AA-01.1 and PR.AA-05.1) should be applied to ensure secure and traceable access. |
|
A general note, for any purpose. |
The goal of this control is to ensure that access rights, privileges, and authorisations are restricted to only the systems and specific information needed to perform assigned tasks, following the principle of least privilege. To achieve this goal, the following should be considered: • Apply Least Privilege o Access rights should be limited to the minimum necessary for users, systems, and services. o Accounts should start with low privileges, and be elevated only when justified. o Just-in-time access should be used to limit the duration of elevated privileges. • Define and Manage Permissions o Access rights should be clearly defined based on roles and responsibilities. o An inventory of accounts and their permissions should be maintained and kept up to date. o Separate accounts should be used for contractors and third parties to ensure traceability. • Enforce Access Controls o Role-based or attribute-based access control models should be implemented where feasible. o Internet access points and external connections should be limited to what is strictly necessary. • Harden Systems o Systems should be hardened to support access control by: - Disabling unused ports and services - Restricting Bluetooth where not needed - Limiting legacy protocols such as FTP unless securely configured • Review and Adapt Access o Access rights should be reviewed regularly and adjusted based on role changes, project completion, or security assessments. o Access should be revoked immediately when no longer needed. • OT-Specific Considerations In OT environments, access control should still follow the principle of least privilege. Where technical limita- tions exist, previously defined OT access control measures (see PR.AA-01.1 and PR.AA-05.1) should be applied to ensure secure and traceable access. |
|
A general note, for any purpose. |
<div><p>The goal of this control is to ensure that access rights, privileges, and authorisations are restricted to only the systems and specific information needed to perform assigned tasks, following the principle of least privilege. To achieve this goal, the following should be considered:</p><ul><li>Apply Least Privilege<ul><li>Access rights should be limited to the minimum necessary for users, systems, and services.</li><li>Accounts should start with low privileges, and be elevated only when justified.</li><li>Just-in-time access should be used to limit the duration of elevated privileges.</li></ul></li><li>Define and Manage Permissions<ul><li>Access rights should be clearly defined based on roles and responsibilities.</li><li>An inventory of accounts and their permissions should be maintained and kept up to date.</li><li>Separate accounts should be used for contractors and third parties to ensure traceability.</li></ul></li><li>Enforce Access Controls<ul><li>Role-based or attribute-based access control models should be implemented where feasible.</li><li>Internet access points and external connections should be limited to what is strictly necessary.</li></ul></li><li>Harden Systems<ul><li>Systems should be hardened to support access control by:<ul><li>Disabling unused ports and services</li><li>Restricting Bluetooth where not needed</li><li>Limiting legacy protocols such as FTP unless securely configured</li></ul></li></ul></li><li>Review and Adapt Access<ul><li>Access rights should be reviewed regularly and adjusted based on role changes, project completion, or security assessments.</li><li>Access should be revoked immediately when no longer needed.</li></ul></li><li>OT-Specific Considerations In OT environments, access control should still follow the principle of least privilege. Where technical limita- tions exist, previously defined OT access control measures (see PR.AA-01.1 and PR.AA-05.1) should be applied to ensure secure and traceable access.</li></ul></div> |
|
A general note, for any purpose. |
The goal of this control is to ensure that access rights, privileges, and authorisations are restricted to only the systems and specific information needed to perform assigned tasks, following the principle of least privilege. To achieve this goal, the following should be considered: - Apply Least Privilege - Access rights should be limited to the minimum necessary for users, systems, and services. - Accounts should start with low privileges, and be elevated only when justified. - Just-in-time access should be used to limit the duration of elevated privileges. - Define and Manage Permissions - Access rights should be clearly defined based on roles and responsibilities. - An inventory of accounts and their permissions should be maintained and kept up to date. - Separate accounts should be used for contractors and third parties to ensure traceability. - Enforce Access Controls - Role-based or attribute-based access control models should be implemented where feasible. - Internet access points and external connections should be limited to what is strictly necessary. - Harden Systems - Systems should be hardened to support access control by: - Disabling unused ports and services - Restricting Bluetooth where not needed - Limiting legacy protocols such as FTP unless securely configured - Review and Adapt Access - Access rights should be reviewed regularly and adjusted based on role changes, project completion, or security assessments. - Access should be revoked immediately when no longer needed. - OT-Specific Considerations In OT environments, access control should still follow the principle of least privilege. Where technical limita- tions exist, previously defined OT access control measures (see PR.AA-01.1 and PR.AA-05.1) should be applied to ensure secure and traceable access. |
|
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.3 |
|
skos:prefLabel, skos:altLabel and skos:hiddenLabel are pairwise disjoint properties. |
Least privilege enforcement |
|
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. |
A ccess rights, privileges and authorisations shall be restricted to the systems and specific information needed to perform the tasks (the principle of Least Privilege). |
|
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. |
|
|
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. |
|
|
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. |
|
|
1 |
|
|
The number of triples associated with the subject. |
23 |
|
Specifies the dataset the subject is part of. |
Resultaten 1 - 25 of 25
Inverse links to the subject.
| Property | Subject |
|---|---|
|
Relates a concept to a concept that is more specific in meaning. |
Resultaten 1 - 1 of 1