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-01.1: Identities and credentials for authorised users, services, and hardware shall be managed. |
|
PR.AA-01.1 |
|
|
http://cyfun.data.gift/data/loc_CyFun2025_Booklet_IMPORTANT_E_p61 |
|
|
http://cyfun.data.gift/data/loc_CyFun2025_Booklet_BASIC_E_p25 |
|
|
http://cyfun.data.gift/data/loc_CyFun2025_Booklet_ESSENTIAL_E_p83 |
|
|
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 identities and credentials for authorised users, services, and hardware are properlymanaged to prevent unauthorised access and support secure operations in both ICTand OTenvi- ronments. To achieve this goal, the following should be considered: • Access Requests and Authorisation o Access should be formally requested, documented, and approved by system or data owners. o Access rights should follow the principle of least privilege. • Identity and Credential Management o Individual user accounts should be used; sharing passwords should be avoided. o Default passwords should be changed before systems are activated. o Unused accounts should be disabled immediately. o Administrator accounts should be limited, reviewed regularly, and not used for daily tasks. • Password Policy o Strong password rules should be enforced. o Passwords should be changed regularly or immediately after suspected compromise. o A formal password policy should be in place (See also: CyFun® Toolbox on www.cyfun.eu). o Rights and privileges should be assigned through user groups. • Device and Hardware Identity o Each authorised device should have a unique identifier (e.g. MAC address, serial number). o Devices should be physically labelled to support inventory and maintenance. • Shared Access to PLCs/HMIs (OT-Specific Measures) o If individual accounts are not feasible, the principle of least privilege should still apply. o A secure jump server or HMI front-end should be used to control access, log activity, and add authen- tication layers. • Secure Remote Access o Technical requirements for remote access should be clearly defined and documented. o Secure methods such as VPNs, encrypted protocols (e.g. SSH, TLS), and multi-factor authentication (MFA – see also PR.AA-03.2) should be used. o Remote access should be monitored and logged. |
|
A general note, for any purpose. |
<div><p>The goal of this control is to ensure that identities and credentials for authorised users, services, and hardware are properlymanaged to prevent unauthorised access and support secure operations in both ICTand OTenvi- ronments. To achieve this goal, the following should be considered:</p><ul><li>Access Requests and Authorisation<ul><li>Access should be formally requested, documented, and approved by system or data owners.</li><li>Access rights should follow the principle of least privilege.</li></ul></li><li>Identity and Credential Management<ul><li>Individual user accounts should be used; sharing passwords should be avoided.</li><li>Default passwords should be changed before systems are activated.</li><li>Unused accounts should be disabled immediately.</li><li>Administrator accounts should be limited, reviewed regularly, and not used for daily tasks.</li></ul></li><li>Password Policy<ul><li>Strong password rules should be enforced.</li><li>Passwords should be changed regularly or immediately after suspected compromise.</li><li>A formal password policy should be in place (See also: CyFun® Toolbox on www.cyfun.eu).</li><li>Rights and privileges should be assigned through user groups.</li></ul></li><li>Device and Hardware Identity<ul><li>Each authorised device should have a unique identifier (e.g. MAC address, serial number).</li><li>Devices should be physically labelled to support inventory and maintenance.</li></ul></li><li>Shared Access to PLCs/HMIs (OT-Specific Measures)<ul><li>If individual accounts are not feasible, the principle of least privilege should still apply.</li><li>A secure jump server or HMI front-end should be used to control access, log activity, and add authen- tication layers.</li></ul></li><li>Secure Remote Access<ul><li>Technical requirements for remote access should be clearly defined and documented.</li><li>Secure methods such as VPNs, encrypted protocols (e.g. SSH, TLS), and multi-factor authentication (MFA – see also PR.AA-03.2) should be used.</li><li>Remote access should be monitored and logged.</li></ul></li></ul></div> |
|
A general note, for any purpose. |
The goal of this control is to ensure that identities and credentials for authorised users, services, and hardware are properlymanaged to prevent unauthorised access and support secure operations in both ICTand OTenvi- ronments. To achieve this goal, the following should be considered: - Access Requests and Authorisation - Access should be formally requested, documented, and approved by system or data owners. - Access rights should follow the principle of least privilege. - Identity and Credential Management - Individual user accounts should be used; sharing passwords should be avoided. - Default passwords should be changed before systems are activated. - Unused accounts should be disabled immediately. - Administrator accounts should be limited, reviewed regularly, and not used for daily tasks. - Password Policy - Strong password rules should be enforced. - Passwords should be changed regularly or immediately after suspected compromise. - A formal password policy should be in place (See also: CyFun® Toolbox on www.cyfun.eu). - Rights and privileges should be assigned through user groups. - Device and Hardware Identity - Each authorised device should have a unique identifier (e.g. MAC address, serial number). - Devices should be physically labelled to support inventory and maintenance. - Shared Access to PLCs/HMIs (OT-Specific Measures) - If individual accounts are not feasible, the principle of least privilege should still apply. - A secure jump server or HMI front-end should be used to control access, log activity, and add authen- tication layers. - Secure Remote Access - Technical requirements for remote access should be clearly defined and documented. - Secure methods such as VPNs, encrypted protocols (e.g. SSH, TLS), and multi-factor authentication (MFA – see also PR.AA-03.2) should be used. - Remote access should be monitored and logged. |
|
A general note, for any purpose. |
The goal of this control is to ensure that identities and credentials for authorised users, services, and hardware are properlymanaged to prevent unauthorised access and support secure operations in both ICTand OTenvi- ronments. To achieve this goal, the following should be considered: - Access Requests and Authorisation - Access should be formally requested, documented, and approved by system or data owners. - Access rights should follow the principle of least privilege. - Identity and Credential Management - Individual user accounts should be used; sharing passwords should be avoided. - Default passwords should be changed before systems are activated. - Unused accounts should be disabled immediately. - Administrator accounts should be limited, reviewed regularly, and not used for daily tasks. - Password Policy - Strong password rules should be enforced. - Passwords should be changed regularly or immediately after suspected compromise. - A formal password policy should be in place (See also: CyFun® Toolbox on www.cyfun.eu). - Rights and privileges should be assigned through user groups. - Device and Hardware Identity - Each authorised device should have a unique identifier (e.g. MAC address, serial number). - Devices should be physically labelled to support inventory and maintenance. - Shared Access to PLCs/HMIs (OT-Specific Measures) - If individual accounts are not feasible, the principle of least privilege should still apply. - A secure jump server or HMI front-end should be used to control access, log activity, and add authen- tication layers. - Secure Remote Access - Technical requirements for remote access should be clearly defined and documented. - Secure methods such as VPNs, encrypted protocols (e.g. SSH, TLS), and multi-factor authentication (MFA – see also PR.AA-03.2) should be used. - Remote access should be monitored and logged. |
|
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-01.1 |
|
skos:prefLabel, skos:altLabel and skos:hiddenLabel are pairwise disjoint properties. |
Identity and credential 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. |
Identities and credentials for authorised users, services, and hardware shall be managed. |
|
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