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.5: The security for connections with external systems shall be verified and framed by documented agreements. |
|
PR.AA-03.5 |
|
|
http://cyfun.data.gift/data/loc_CyFun2025_Booklet_ESSENTIAL_E_p91 |
|
|
Relates a concept to a concept that is more general in meaning. |
|
|
A general note, for any purpose. |
<div><p>The goal of this control is to ensure that all connections with external systems are secured through verified security controls and governed by documented agreements. This reduces the risk of unauthorised access, data leakage, and supply chain compromise. To achieve this goal, the organisation should:</p><ul><li>Control and Document All External Interactions All interactions between internal systems and external parties (e.g.vendors, partners, cloud services) should be identified, controlled, and documented to ensure traceability and accountability.</li><li>Verify Security Controls of External Parties Before establishing any connection, the external party’s security posture should be verified through third- party assessments, audits, certifications (e.g. CyFun®), or technical documentation such as M154. These documents should describe security architecture, access controls, encryption, and monitoring.</li><li>Establish Documented Agreements Formal agreements (e.g. contracts, SLAs, DPAs) should define securityrequirements, roles and responsibilities, data exchange protocols, incident response procedures, and termination conditions.</li><li>SpecifyAccess Control Requirements Agreements should include technical restrictions such as IP whitelisting, role-based access control, data handling rules, and encryption requirements for data in transit and at rest.</li><li>Monitor and Review External Connections All external connections should be continuouslymonitored foranomalies orpolicyviolations.Agreements and technical documentation (e.g. M154) should be reviewed periodically and updated as needed. Any changes in the external system’s security posture should trigger a reassessment.</li><li>Ensure OT-Specific Considerations In OTenvironments, external access should be routed through secure gateways orjump servers. Shared access (e.g. for vendor-managed PLCs) should be logged, time-limited, and protected by strong authentication.</li><li>Align with ENISA Guidance These practices align with ENISA’s Technical Implementation Guidance on Cybersecurity Risk Management Measures, which recommends verifying third-party security, formalising responsibilities through contracts, and continuously monitoring external dependencies.</li></ul></div> |
|
A general note, for any purpose. |
The goal of this control is to ensure that all connections with external systems are secured through verified security controls and governed by documented agreements. This reduces the risk of unauthorised access, data leakage, and supply chain compromise. To achieve this goal, the organisation should: - Control and Document All External Interactions All interactions between internal systems and external parties (e.g.vendors, partners, cloud services) should be identified, controlled, and documented to ensure traceability and accountability. - Verify Security Controls of External Parties Before establishing any connection, the external party’s security posture should be verified through third- party assessments, audits, certifications (e.g. CyFun®), or technical documentation such as M154. These documents should describe security architecture, access controls, encryption, and monitoring. - Establish Documented Agreements Formal agreements (e.g. contracts, SLAs, DPAs) should define securityrequirements, roles and responsibilities, data exchange protocols, incident response procedures, and termination conditions. - SpecifyAccess Control Requirements Agreements should include technical restrictions such as IP whitelisting, role-based access control, data handling rules, and encryption requirements for data in transit and at rest. - Monitor and Review External Connections All external connections should be continuouslymonitored foranomalies orpolicyviolations.Agreements and technical documentation (e.g. M154) should be reviewed periodically and updated as needed. Any changes in the external system’s security posture should trigger a reassessment. - Ensure OT-Specific Considerations In OTenvironments, external access should be routed through secure gateways orjump servers. Shared access (e.g. for vendor-managed PLCs) should be logged, time-limited, and protected by strong authentication. - Align with ENISA Guidance These practices align with ENISA’s Technical Implementation Guidance on Cybersecurity Risk Management Measures, which recommends verifying third-party security, formalising responsibilities through contracts, and continuously monitoring external dependencies. |
|
A general note, for any purpose. |
The goal of this control is to ensure that all connections with external systems are secured through verified security controls and governed by documented agreements. This reduces the risk of unauthorised access, data leakage, and supply chain compromise. To achieve this goal, the organisation should: • Control and Document All External Interactions All interactions between internal systems and external parties (e.g.vendors, partners, cloud services) should be identified, controlled, and documented to ensure traceability and accountability. • Verify Security Controls of External Parties Before establishing any connection, the external party’s security posture should be verified through third- party assessments, audits, certifications (e.g. CyFun®), or technical documentation such as M154. These documents should describe security architecture, access controls, encryption, and monitoring. • Establish Documented Agreements Formal agreements (e.g. contracts, SLAs, DPAs) should define securityrequirements, roles and responsibilities, data exchange protocols, incident response procedures, and termination conditions. • SpecifyAccess Control Requirements Agreements should include technical restrictions such as IP whitelisting, role-based access control, data handling rules, and encryption requirements for data in transit and at rest. • Monitor and Review External Connections All external connections should be continuouslymonitored foranomalies orpolicyviolations.Agreements and technical documentation (e.g. M154) should be reviewed periodically and updated as needed. Any changes in the external system’s security posture should trigger a reassessment. • Ensure OT-Specific Considerations In OTenvironments, external access should be routed through secure gateways orjump servers. Shared access (e.g. for vendor-managed PLCs) should be logged, time-limited, and protected by strong authentication. • Align with ENISA Guidance These practices align with ENISA’s Technical Implementation Guidance on Cybersecurity Risk Management Measures, which recommends verifying third-party security, formalising responsibilities through contracts, and continuously monitoring external dependencies. |
|
A general note, for any purpose. |
The goal of this control is to ensure that all connections with external systems are secured through verified security controls and governed by documented agreements. This reduces the risk of unauthorised access, data leakage, and supply chain compromise. To achieve this goal, the organisation should: - Control and Document All External Interactions All interactions between internal systems and external parties (e.g.vendors, partners, cloud services) should be identified, controlled, and documented to ensure traceability and accountability. - Verify Security Controls of External Parties Before establishing any connection, the external party’s security posture should be verified through third- party assessments, audits, certifications (e.g. CyFun®), or technical documentation such as M154. These documents should describe security architecture, access controls, encryption, and monitoring. - Establish Documented Agreements Formal agreements (e.g. contracts, SLAs, DPAs) should define securityrequirements, roles and responsibilities, data exchange protocols, incident response procedures, and termination conditions. - SpecifyAccess Control Requirements Agreements should include technical restrictions such as IP whitelisting, role-based access control, data handling rules, and encryption requirements for data in transit and at rest. - Monitor and Review External Connections All external connections should be continuouslymonitored foranomalies orpolicyviolations.Agreements and technical documentation (e.g. M154) should be reviewed periodically and updated as needed. Any changes in the external system’s security posture should trigger a reassessment. - Ensure OT-Specific Considerations In OTenvironments, external access should be routed through secure gateways orjump servers. Shared access (e.g. for vendor-managed PLCs) should be logged, time-limited, and protected by strong authentication. - Align with ENISA Guidance These practices align with ENISA’s Technical Implementation Guidance on Cybersecurity Risk Management Measures, which recommends verifying third-party security, formalising responsibilities through contracts, and continuously monitoring external dependencies. |
|
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.5 |
|
skos:prefLabel, skos:altLabel and skos:hiddenLabel are pairwise disjoint properties. |
External system connection security |
|
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 security for connections with external systems shall be verified and framed by documented agreements. |
|
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_IMPORTANT_to_ESSENTIAL |
|
Relates a resource (for example a concept) to a concept scheme in which it is included. |
|
|
The number of triples associated with the subject. |
17 |
|
Specifies the dataset the subject is part of. |
Resultaten 1 - 19 of 19
Inverse links to the subject.
| Property | Subject |
|---|---|
|
Relates a concept to a concept that is more specific in meaning. |
Resultaten 1 - 1 of 1