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-03.3: The organisation shall define, document, and implement usage restrictions, connec- tion requirements, and authorisation procedures for remote access to its critical systems. These controls shall ensure that only approved users can connect, using secure methods, with access limited to what is necessary for their role. |
|
PR.AA-03.3 |
|
|
http://cyfun.data.gift/data/loc_CyFun2025_Booklet_ESSENTIAL_E_p90 |
|
|
http://cyfun.data.gift/data/loc_CyFun2025_Booklet_IMPORTANT_E_p65 |
|
|
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 remote access to critical systems is tightly controlled through defined usage restrictions, secure connection methods, and formal authorisation procedures.This helps prevent unau- thorised access and limits exposure to cyber threats. To achieve this goal, the organisation should: • Define Usage Restrictions Identifywhich systems are critical (e.g. OTsystems, production servers, financial databases). Definewho may accessthemremotely(e.g.specificroles,third-partyvendors).Limitaccesstoapprovedtimeframesandrestrict it to only the systems and functions necessary for the user’s role. • Set Secure Connection Requirements Remote access should be established using secure methods such as VPNs with strong encryption, TLS/SSH, orjump servers forOTenvironments.All remote access should be protected byMulti-FactorAuthentication (MFA), in line with PR.AA-03.2. Devices used for remote access should meet endpoint security requirements (e.g. antivirus, patching). • Document and Approve Access A remote access policy should define request and approval procedures, roles, and technical requirements. Aregisterof remote users should be maintained, including access scope, approval dates, and reviewtimelines. • Monitor and ReviewAccess All remote sessions should be logged, capturing user identity, time, duration, and systems accessed. Logs should be reviewed regularlyforanomalies. Remote access permissions and configurations should be audited periodically. • Apply OT-Specific Controls For OT systems, access should be routed through secure front-end interfaces or jump servers. If shared accounts are required (e.g. for PLCs or HMIs), access should be logged, time-limited, protected by MFA at the jump server level, and follow the principle of least privilege. • Align with ENISA Guidance These practices align with ENISA’s NIS2 Technical Implementation Guidance, which recommends secure remote access policies, strong authentication, and continuous monitoring as part of cybersecurity risk management for critical systems. |
|
A general note, for any purpose. |
The goal of this control is to ensure that remote access to critical systems is tightly controlled through defined usage restrictions, secure connection methods, and formal authorisation procedures.This helps prevent unau- thorised access and limits exposure to cyber threats. To achieve this goal, the organisation should: - Define Usage Restrictions Identifywhich systems are critical (e.g. OTsystems, production servers, financial databases). Definewho may accessthemremotely(e.g.specificroles,third-partyvendors).Limitaccesstoapprovedtimeframesandrestrict it to only the systems and functions necessary for the user’s role. - Set Secure Connection Requirements Remote access should be established using secure methods such as VPNs with strong encryption, TLS/SSH, orjump servers forOTenvironments.All remote access should be protected byMulti-FactorAuthentication (MFA), in line with PR.AA-03.2. Devices used for remote access should meet endpoint security requirements (e.g. antivirus, patching). - Document and Approve Access A remote access policy should define request and approval procedures, roles, and technical requirements. Aregisterof remote users should be maintained, including access scope, approval dates, and reviewtimelines. - Monitor and ReviewAccess All remote sessions should be logged, capturing user identity, time, duration, and systems accessed. Logs should be reviewed regularlyforanomalies. Remote access permissions and configurations should be audited periodically. - Apply OT-Specific Controls For OT systems, access should be routed through secure front-end interfaces or jump servers. If shared accounts are required (e.g. for PLCs or HMIs), access should be logged, time-limited, protected by MFA at the jump server level, and follow the principle of least privilege. - Align with ENISA Guidance These practices align with ENISA’s NIS2 Technical Implementation Guidance, which recommends secure remote access policies, strong authentication, and continuous monitoring as part of cybersecurity risk management for critical systems. |
|
A general note, for any purpose. |
<div><p>The goal of this control is to ensure that remote access to critical systems is tightly controlled through defined usage restrictions, secure connection methods, and formal authorisation procedures.This helps prevent unau- thorised access and limits exposure to cyber threats. To achieve this goal, the organisation should:</p><ul><li>Define Usage Restrictions Identifywhich systems are critical (e.g. OTsystems, production servers, financial databases). Definewho may accessthemremotely(e.g.specificroles,third-partyvendors).Limitaccesstoapprovedtimeframesandrestrict it to only the systems and functions necessary for the user’s role.</li><li>Set Secure Connection Requirements Remote access should be established using secure methods such as VPNs with strong encryption, TLS/SSH, orjump servers forOTenvironments.All remote access should be protected byMulti-FactorAuthentication (MFA), in line with PR.AA-03.2. Devices used for remote access should meet endpoint security requirements (e.g. antivirus, patching).</li><li>Document and Approve Access A remote access policy should define request and approval procedures, roles, and technical requirements. Aregisterof remote users should be maintained, including access scope, approval dates, and reviewtimelines.</li><li>Monitor and ReviewAccess All remote sessions should be logged, capturing user identity, time, duration, and systems accessed. Logs should be reviewed regularlyforanomalies. Remote access permissions and configurations should be audited periodically.</li><li>Apply OT-Specific Controls For OT systems, access should be routed through secure front-end interfaces or jump servers. If shared accounts are required (e.g. for PLCs or HMIs), access should be logged, time-limited, protected by MFA at the jump server level, and follow the principle of least privilege.</li><li>Align with ENISA Guidance These practices align with ENISA’s NIS2 Technical Implementation Guidance, which recommends secure remote access policies, strong authentication, and continuous monitoring as part of cybersecurity risk management for critical systems.</li></ul></div> |
|
A general note, for any purpose. |
The goal of this control is to ensure that remote access to critical systems is tightly controlled through defined usage restrictions, secure connection methods, and formal authorisation procedures.This helps prevent unau- thorised access and limits exposure to cyber threats. To achieve this goal, the organisation should: - Define Usage Restrictions Identifywhich systems are critical (e.g. OTsystems, production servers, financial databases). Definewho may accessthemremotely(e.g.specificroles,third-partyvendors).Limitaccesstoapprovedtimeframesandrestrict it to only the systems and functions necessary for the user’s role. - Set Secure Connection Requirements Remote access should be established using secure methods such as VPNs with strong encryption, TLS/SSH, orjump servers forOTenvironments.All remote access should be protected byMulti-FactorAuthentication (MFA), in line with PR.AA-03.2. Devices used for remote access should meet endpoint security requirements (e.g. antivirus, patching). - Document and Approve Access A remote access policy should define request and approval procedures, roles, and technical requirements. Aregisterof remote users should be maintained, including access scope, approval dates, and reviewtimelines. - Monitor and ReviewAccess All remote sessions should be logged, capturing user identity, time, duration, and systems accessed. Logs should be reviewed regularlyforanomalies. Remote access permissions and configurations should be audited periodically. - Apply OT-Specific Controls For OT systems, access should be routed through secure front-end interfaces or jump servers. If shared accounts are required (e.g. for PLCs or HMIs), access should be logged, time-limited, protected by MFA at the jump server level, and follow the principle of least privilege. - Align with ENISA Guidance These practices align with ENISA’s NIS2 Technical Implementation Guidance, which recommends secure remote access policies, strong authentication, and continuous monitoring as part of cybersecurity risk management for critical systems. |
|
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-03.3 |
|
skos:prefLabel, skos:altLabel and skos:hiddenLabel are pairwise disjoint properties. |
Remote access restrictions and authorisation |
|
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. |
The organisation shall define, document, and implement usage restrictions, connec- tion requirements, and authorisation procedures for remote access to its critical systems. These controls shall ensure that only approved users can connect, using secure methods, with access limited to what is necessary for their role. |
|
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. |
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. |
|
|
1 |
|
|
The number of triples associated with the subject. |
21 |
|
Specifies the dataset the subject is part of. |
Resultaten 1 - 23 of 23
Inverse links to the subject.
| Property | Subject |
|---|---|
|
Relates a concept to a concept that is more specific in meaning. |
Resultaten 1 - 1 of 1