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.2: Multi-Factor Authentication (MFA) shall be required to access the organisation's networks remotely. |
|
PR.AA-03.2 |
|
|
http://cyfun.data.gift/data/loc_CyFun2025_Booklet_BASIC_E_p27 |
|
|
http://cyfun.data.gift/data/loc_CyFun2025_Booklet_ESSENTIAL_E_p89 |
|
|
http://cyfun.data.gift/data/loc_CyFun2025_Booklet_IMPORTANT_E_p64 |
|
|
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 protect the organisation’s networks by requiring multi-factor authentication (MFA) for all remote access, thereby reducing the risk of unauthorised access and credential-based attacks. To achieve this goal, the following should be considered: • General MFA Enforcement o MFA should be enforced on all internet-facing systems, including email, VPNs, RDP, cloud services, and web portals. o All remote access, including access by third-party vendors and contractors, should require MFA. • MFATechnology Selection o MFA methods should be selected based on security strength, phishing resistance, and operational fit. o Common options include: - Hardware TOTP (Time-based One-Time Password) tokens — secure, limited phishing resistance - Authenticator apps (software TOTP) — widely used, moderate security - Passkeys — passwordless, user-friendly, cryptographically secure - FIDO2 (platform or hardware-based – Fast Identity Online 2) — strong cryptographic authentication - Push-based apps — convenient, but may be vulnerable to push fatigue o SMS and email-based MFA should be avoided due to security weaknesses. • Supporting Security Measures o Strong password policies should be enforced alongside MFA. o Users should be trained to log out of sessions explicitly. o Anti-malware tools and platforms should be kept up-to-date. o Regular phishing awareness training should be conducted. • OT-Specific MFA Considerations (see also PR.AA-01.1) o Shared Access to PLCs/HMIs - If individual accounts are not feasible, the principle of least privilege should be applied. - A secure jump server or HMI front-end should be used to control access, log activity, and add an authentication layer. o Secure Remote Access to OT Systems - Technical and procedural requirements for remote access should be clearly defined. - Secure protocols (e.g. VPN, SSH, TLS) should be used. - MFA should be enforced for all remote OT access, especially for third-party suppliers. - Just-In-Time (JIT) access controls should be used to grant temporary, time-limited access. - All remote access should be logged and monitored. o Integration and Compatibility - The MFA solution should be compatible with both IT and OT systems. - Integration should be tested in OT environments to avoid disruptions. - Where direct integration is not possible, secure intermediary platforms (e.g. jump servers) should be used. |
|
A general note, for any purpose. |
The goal of this control is to protect the organisation’s networks by requiring multi-factor authentication (MFA) for all remote access, thereby reducing the risk of unauthorised access and credential-based attacks. To achieve this goal, the following should be considered: - General MFA Enforcement - MFA should be enforced on all internet-facing systems, including email, VPNs, RDP, cloud services, and web portals. - All remote access, including access by third-party vendors and contractors, should require MFA. - MFATechnology Selection - MFA methods should be selected based on security strength, phishing resistance, and operational fit. - Common options include: - Hardware TOTP (Time-based One-Time Password) tokens — secure, limited phishing resistance - Authenticator apps (software TOTP) — widely used, moderate security - Passkeys — passwordless, user-friendly, cryptographically secure - FIDO2 (platform or hardware-based – Fast Identity Online 2) — strong cryptographic authentication - Push-based apps — convenient, but may be vulnerable to push fatigue - SMS and email-based MFA should be avoided due to security weaknesses. - Supporting Security Measures - Strong password policies should be enforced alongside MFA. - Users should be trained to log out of sessions explicitly. - Anti-malware tools and platforms should be kept up-to-date. - Regular phishing awareness training should be conducted. - OT-Specific MFA Considerations (see also PR.AA-01.1) - Shared Access to PLCs/HMIs - If individual accounts are not feasible, the principle of least privilege should be applied. - A secure jump server or HMI front-end should be used to control access, log activity, and add an authentication layer. - Secure Remote Access to OT Systems - Technical and procedural requirements for remote access should be clearly defined. - Secure protocols (e.g. VPN, SSH, TLS) should be used. - MFA should be enforced for all remote OT access, especially for third-party suppliers. - Just-In-Time (JIT) access controls should be used to grant temporary, time-limited access. - All remote access should be logged and monitored. - Integration and Compatibility - The MFA solution should be compatible with both IT and OT systems. - Integration should be tested in OT environments to avoid disruptions. - Where direct integration is not possible, secure intermediary platforms (e.g. jump servers) should be used. |
|
A general note, for any purpose. |
The goal of this control is to protect the organisation’s networks by requiring multi-factor authentication (MFA) for all remote access, thereby reducing the risk of unauthorised access and credential-based attacks. To achieve this goal, the following should be considered: - General MFA Enforcement - MFA should be enforced on all internet-facing systems, including email, VPNs, RDP, cloud services, and web portals. - All remote access, including access by third-party vendors and contractors, should require MFA. - MFATechnology Selection - MFA methods should be selected based on security strength, phishing resistance, and operational fit. - Common options include: - Hardware TOTP (Time-based One-Time Password) tokens — secure, limited phishing resistance - Authenticator apps (software TOTP) — widely used, moderate security - Passkeys — passwordless, user-friendly, cryptographically secure - FIDO2 (platform or hardware-based – Fast Identity Online 2) — strong cryptographic authentication - Push-based apps — convenient, but may be vulnerable to push fatigue - SMS and email-based MFA should be avoided due to security weaknesses. - Supporting Security Measures - Strong password policies should be enforced alongside MFA. - Users should be trained to log out of sessions explicitly. - Anti-malware tools and platforms should be kept up-to-date. - Regular phishing awareness training should be conducted. - OT-Specific MFA Considerations (see also PR.AA-01.1) - Shared Access to PLCs/HMIs - If individual accounts are not feasible, the principle of least privilege should be applied. - A secure jump server or HMI front-end should be used to control access, log activity, and add an authentication layer. - Secure Remote Access to OT Systems - Technical and procedural requirements for remote access should be clearly defined. - Secure protocols (e.g. VPN, SSH, TLS) should be used. - MFA should be enforced for all remote OT access, especially for third-party suppliers. - Just-In-Time (JIT) access controls should be used to grant temporary, time-limited access. - All remote access should be logged and monitored. - Integration and Compatibility - The MFA solution should be compatible with both IT and OT systems. - Integration should be tested in OT environments to avoid disruptions. - Where direct integration is not possible, secure intermediary platforms (e.g. jump servers) should be used. |
|
A general note, for any purpose. |
<div><p>The goal of this control is to protect the organisation’s networks by requiring multi-factor authentication (MFA) for all remote access, thereby reducing the risk of unauthorised access and credential-based attacks. To achieve this goal, the following should be considered:</p><ul><li>General MFA Enforcement<ul><li>MFA should be enforced on all internet-facing systems, including email, VPNs, RDP, cloud services, and web portals.</li><li>All remote access, including access by third-party vendors and contractors, should require MFA.</li></ul></li><li>MFATechnology Selection<ul><li>MFA methods should be selected based on security strength, phishing resistance, and operational fit.</li><li>Common options include:<ul><li>Hardware TOTP (Time-based One-Time Password) tokens — secure, limited phishing resistance</li><li>Authenticator apps (software TOTP) — widely used, moderate security</li><li>Passkeys — passwordless, user-friendly, cryptographically secure</li><li>FIDO2 (platform or hardware-based – Fast Identity Online 2) — strong cryptographic authentication</li><li>Push-based apps — convenient, but may be vulnerable to push fatigue</li></ul></li><li>SMS and email-based MFA should be avoided due to security weaknesses.</li></ul></li><li>Supporting Security Measures<ul><li>Strong password policies should be enforced alongside MFA.</li><li>Users should be trained to log out of sessions explicitly.</li><li>Anti-malware tools and platforms should be kept up-to-date.</li><li>Regular phishing awareness training should be conducted.</li></ul></li><li>OT-Specific MFA Considerations (see also PR.AA-01.1)<ul><li>Shared Access to PLCs/HMIs<ul><li>If individual accounts are not feasible, the principle of least privilege should be applied.</li><li>A secure jump server or HMI front-end should be used to control access, log activity, and add an authentication layer.</li></ul></li><li>Secure Remote Access to OT Systems<ul><li>Technical and procedural requirements for remote access should be clearly defined.</li><li>Secure protocols (e.g. VPN, SSH, TLS) should be used.</li><li>MFA should be enforced for all remote OT access, especially for third-party suppliers.</li><li>Just-In-Time (JIT) access controls should be used to grant temporary, time-limited access.</li><li>All remote access should be logged and monitored.</li></ul></li><li>Integration and Compatibility<ul><li>The MFA solution should be compatible with both IT and OT systems.</li><li>Integration should be tested in OT environments to avoid disruptions.</li><li>Where direct integration is not possible, secure intermediary platforms (e.g. jump servers) should be used.</li></ul></li></ul></li></ul></div> |
|
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.2 |
|
skos:prefLabel, skos:altLabel and skos:hiddenLabel are pairwise disjoint properties. |
MFA for remote network access |
|
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. |
Multi-Factor Authentication (MFA) shall be required to access the organisation's networks remotely. |
|
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