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.1: Access permissions, rights, and authorisations shall be defined, managed, enforced and reviewed. |
|
PR.AA-05.1 |
|
|
http://cyfun.data.gift/data/loc_CyFun2025_Booklet_BASIC_E_p28 |
|
|
http://cyfun.data.gift/data/loc_CyFun2025_Booklet_IMPORTANT_E_p66 |
|
|
http://cyfun.data.gift/data/loc_CyFun2025_Booklet_ESSENTIAL_E_p93 |
|
|
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 permissions, rights, and authorisations are clearly defined, properly managed, consistently enforced, and regularly reviewed to protect systems and data from unauthor- ised access. To achieve this goal, the following should be considered: • Access Definition and Management o Access lists for systems (e.g. files, servers, software, databases) should be created and reviewed regularly. o Reviews should be supported by tools such as Active Directory analysis. o Permission management procedures should be documented and updated as needed. • Access Review and Revocation o Logical and physical access rights should be reviewed periodicallyandwheneverroles change orindividuals leave the organisation. o Unnecessary privileges should be revoked immediately. • UserAccount Practices o Each user, including contractors, should have a separate account to ensure accountability. o Where technically feasible, appropriate authentication measures should be applied. o Guest accounts should be restricted to minimum required privileges (e.g. internet access only). o Single Sign-On (SSO) should be used where appropriate. • Authorisation Criteria Authorisation decisions should consider characteristics such as geolocation, time of access, and the security posture of the requesting device. • OT-Specific Considerations o In environments where individual accounts are not technically feasible — such as shared access to PLCs or HMIs, access should be limited to essential functions only, and enforced through secure methods like a jump server or HMI front-end that logs activity, restricts access by role or time, and adds an extra authentication layer (e.g. badge or PIN). o Authentication methods should align with the capabilities of OT systems. o Access to OT systems should be logged and monitored where possible. |
|
A general note, for any purpose. |
<div><p>The goal of this control is to ensure that access permissions, rights, and authorisations are clearly defined, properly managed, consistently enforced, and regularly reviewed to protect systems and data from unauthor- ised access. To achieve this goal, the following should be considered:</p><ul><li>Access Definition and Management<ul><li>Access lists for systems (e.g. files, servers, software, databases) should be created and reviewed regularly.</li><li>Reviews should be supported by tools such as Active Directory analysis.</li><li>Permission management procedures should be documented and updated as needed.</li></ul></li><li>Access Review and Revocation<ul><li>Logical and physical access rights should be reviewed periodicallyandwheneverroles change orindividuals leave the organisation.</li><li>Unnecessary privileges should be revoked immediately.</li></ul></li><li>UserAccount Practices<ul><li>Each user, including contractors, should have a separate account to ensure accountability.</li><li>Where technically feasible, appropriate authentication measures should be applied.</li><li>Guest accounts should be restricted to minimum required privileges (e.g. internet access only).</li><li>Single Sign-On (SSO) should be used where appropriate.</li></ul></li><li>Authorisation Criteria Authorisation decisions should consider characteristics such as geolocation, time of access, and the security posture of the requesting device.</li><li>OT-Specific Considerations<ul><li>In environments where individual accounts are not technically feasible — such as shared access to PLCs or HMIs, access should be limited to essential functions only, and enforced through secure methods like a jump server or HMI front-end that logs activity, restricts access by role or time, and adds an extra authentication layer (e.g. badge or PIN).</li><li>Authentication methods should align with the capabilities of OT systems.</li><li>Access to OT systems should be logged and monitored where possible.</li></ul></li></ul></div> |
|
A general note, for any purpose. |
The goal of this control is to ensure that access permissions, rights, and authorisations are clearly defined, properly managed, consistently enforced, and regularly reviewed to protect systems and data from unauthor- ised access. To achieve this goal, the following should be considered: - Access Definition and Management - Access lists for systems (e.g. files, servers, software, databases) should be created and reviewed regularly. - Reviews should be supported by tools such as Active Directory analysis. - Permission management procedures should be documented and updated as needed. - Access Review and Revocation - Logical and physical access rights should be reviewed periodicallyandwheneverroles change orindividuals leave the organisation. - Unnecessary privileges should be revoked immediately. - UserAccount Practices - Each user, including contractors, should have a separate account to ensure accountability. - Where technically feasible, appropriate authentication measures should be applied. - Guest accounts should be restricted to minimum required privileges (e.g. internet access only). - Single Sign-On (SSO) should be used where appropriate. - Authorisation Criteria Authorisation decisions should consider characteristics such as geolocation, time of access, and the security posture of the requesting device. - OT-Specific Considerations - In environments where individual accounts are not technically feasible — such as shared access to PLCs or HMIs, access should be limited to essential functions only, and enforced through secure methods like a jump server or HMI front-end that logs activity, restricts access by role or time, and adds an extra authentication layer (e.g. badge or PIN). - Authentication methods should align with the capabilities of OT systems. - Access to OT systems should be logged and monitored where possible. |
|
A general note, for any purpose. |
The goal of this control is to ensure that access permissions, rights, and authorisations are clearly defined, properly managed, consistently enforced, and regularly reviewed to protect systems and data from unauthor- ised access. To achieve this goal, the following should be considered: - Access Definition and Management - Access lists for systems (e.g. files, servers, software, databases) should be created and reviewed regularly. - Reviews should be supported by tools such as Active Directory analysis. - Permission management procedures should be documented and updated as needed. - Access Review and Revocation - Logical and physical access rights should be reviewed periodicallyandwheneverroles change orindividuals leave the organisation. - Unnecessary privileges should be revoked immediately. - UserAccount Practices - Each user, including contractors, should have a separate account to ensure accountability. - Where technically feasible, appropriate authentication measures should be applied. - Guest accounts should be restricted to minimum required privileges (e.g. internet access only). - Single Sign-On (SSO) should be used where appropriate. - Authorisation Criteria Authorisation decisions should consider characteristics such as geolocation, time of access, and the security posture of the requesting device. - OT-Specific Considerations - In environments where individual accounts are not technically feasible — such as shared access to PLCs or HMIs, access should be limited to essential functions only, and enforced through secure methods like a jump server or HMI front-end that logs activity, restricts access by role or time, and adds an extra authentication layer (e.g. badge or PIN). - Authentication methods should align with the capabilities of OT systems. - Access to OT systems should be logged and monitored where possible. |
|
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.1 |
|
skos:prefLabel, skos:altLabel and skos:hiddenLabel are pairwise disjoint properties. |
Access permissions management |
|
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. |
Access permissions, rights, and authorisations shall be defined, managed, enforced and reviewed. |
|
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