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.3: System credentials shall be deactivated after a specified period of inactivity unless it would compromise the safe operation of (critical) processes. |
|
PR.AA-01.3 |
|
|
http://cyfun.data.gift/data/loc_CyFun2025_Booklet_ESSENTIAL_E_p85 |
|
|
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 system credentials are deactivated after a defined period of inactivity, unless doing so would compromise the safe operation of critical processes. This helps reduce the risk of un- authorised access while maintaining operational continuity. To achieve this goal, the organisation should: - Use Service Accounts forAutomated Operations Service accounts should be used to run applications, services, or automated tasks. These accounts should be configured with minimal permissions, isolated from user accounts, and monitored separately to support auditability and secure automation. - Apply the Principle of Least Privilege Service accounts should only have the permissions necessary for their function. This limits potential misuse and supports secure operations in both IT and OT environments. - Monitor and Audit Service Account Activity Actions performed by service accounts should be logged and reviewed regularly. This improves traceability and helps detect anomalies or misuse. - Implement Credential Inactivity Policies System credentials, including those of service and user accounts, should be automatically deactivated after a defined period of inactivity. Exceptions should be documented and justified, especiallyin OTenvironments where continuous operation is critical. - Establish Formal Access Procedures for External Parties External access should follow a defined process, including role-based access levels, authorisation steps, identity verification, and awareness training. Monitoring and revocation mechanisms should be in place to manage access violations. - Ensure OT-Specific Considerations InOTenvironments,credentialdeactivationpoliciesshouldaccountforsystemuptimerequirements,vendor- managed components, and legacy systems. Coordination with engineering teams may be necessary to avoid operational disruptions. |
|
A general note, for any purpose. |
The goal of this control is to ensure that system credentials are deactivated after a defined period of inactivity, unless doing so would compromise the safe operation of critical processes. This helps reduce the risk of un- authorised access while maintaining operational continuity. To achieve this goal, the organisation should: • Use Service Accounts forAutomated Operations Service accounts should be used to run applications, services, or automated tasks. These accounts should be configured with minimal permissions, isolated from user accounts, and monitored separately to support auditability and secure automation. • Apply the Principle of Least Privilege Service accounts should only have the permissions necessary for their function. This limits potential misuse and supports secure operations in both IT and OT environments. • Monitor and Audit Service Account Activity Actions performed by service accounts should be logged and reviewed regularly. This improves traceability and helps detect anomalies or misuse. • Implement Credential Inactivity Policies System credentials, including those of service and user accounts, should be automatically deactivated after a defined period of inactivity. Exceptions should be documented and justified, especiallyin OTenvironments where continuous operation is critical. • Establish Formal Access Procedures for External Parties External access should follow a defined process, including role-based access levels, authorisation steps, identity verification, and awareness training. Monitoring and revocation mechanisms should be in place to manage access violations. • Ensure OT-Specific Considerations InOTenvironments,credentialdeactivationpoliciesshouldaccountforsystemuptimerequirements,vendor- managed components, and legacy systems. Coordination with engineering teams may be necessary to avoid operational disruptions. |
|
A general note, for any purpose. |
The goal of this control is to ensure that system credentials are deactivated after a defined period of inactivity, unless doing so would compromise the safe operation of critical processes. This helps reduce the risk of un- authorised access while maintaining operational continuity. To achieve this goal, the organisation should: - Use Service Accounts forAutomated Operations Service accounts should be used to run applications, services, or automated tasks. These accounts should be configured with minimal permissions, isolated from user accounts, and monitored separately to support auditability and secure automation. - Apply the Principle of Least Privilege Service accounts should only have the permissions necessary for their function. This limits potential misuse and supports secure operations in both IT and OT environments. - Monitor and Audit Service Account Activity Actions performed by service accounts should be logged and reviewed regularly. This improves traceability and helps detect anomalies or misuse. - Implement Credential Inactivity Policies System credentials, including those of service and user accounts, should be automatically deactivated after a defined period of inactivity. Exceptions should be documented and justified, especiallyin OTenvironments where continuous operation is critical. - Establish Formal Access Procedures for External Parties External access should follow a defined process, including role-based access levels, authorisation steps, identity verification, and awareness training. Monitoring and revocation mechanisms should be in place to manage access violations. - Ensure OT-Specific Considerations InOTenvironments,credentialdeactivationpoliciesshouldaccountforsystemuptimerequirements,vendor- managed components, and legacy systems. Coordination with engineering teams may be necessary to avoid operational disruptions. |
|
A general note, for any purpose. |
<div><p>The goal of this control is to ensure that system credentials are deactivated after a defined period of inactivity, unless doing so would compromise the safe operation of critical processes. This helps reduce the risk of un- authorised access while maintaining operational continuity. To achieve this goal, the organisation should:</p><ul><li>Use Service Accounts forAutomated Operations Service accounts should be used to run applications, services, or automated tasks. These accounts should be configured with minimal permissions, isolated from user accounts, and monitored separately to support auditability and secure automation.</li><li>Apply the Principle of Least Privilege Service accounts should only have the permissions necessary for their function. This limits potential misuse and supports secure operations in both IT and OT environments.</li><li>Monitor and Audit Service Account Activity Actions performed by service accounts should be logged and reviewed regularly. This improves traceability and helps detect anomalies or misuse.</li><li>Implement Credential Inactivity Policies System credentials, including those of service and user accounts, should be automatically deactivated after a defined period of inactivity. Exceptions should be documented and justified, especiallyin OTenvironments where continuous operation is critical.</li><li>Establish Formal Access Procedures for External Parties External access should follow a defined process, including role-based access levels, authorisation steps, identity verification, and awareness training. Monitoring and revocation mechanisms should be in place to manage access violations.</li><li>Ensure OT-Specific Considerations InOTenvironments,credentialdeactivationpoliciesshouldaccountforsystemuptimerequirements,vendor- managed components, and legacy systems. Coordination with engineering teams may be necessary to avoid operational disruptions.</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-01.3 |
|
skos:prefLabel, skos:altLabel and skos:hiddenLabel are pairwise disjoint properties. |
Inactive credential deactivation |
|
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. |
System credentials shall be deactivated after a specified period of inactivity unless it would compromise the safe operation of (critical) processes. |
|
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