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-05.4: No one shall have administrative privileges for routine day-to-day tasks. |
|
PR.AA-05.4 |
|
|
http://cyfun.data.gift/data/loc_CyFun2025_Booklet_BASIC_E_p30 |
|
|
http://cyfun.data.gift/data/loc_CyFun2025_Booklet_IMPORTANT_E_p68 |
|
|
http://cyfun.data.gift/data/loc_CyFun2025_Booklet_ESSENTIAL_E_p95 |
|
|
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 prevent the use of administrative privileges for routine, day-to-day tasks, thereby reducing the risk of misuse or exploitation by attackers. To ensure this goal is met, the organisation should consider the following: • Account Separation and Privilege Management o Administrative and general user accounts should be strictly separated. o Dedicated administrator accounts should be used only for system management and administrative tasks. o User accounts should not have administrative privileges. • Access Restrictions and Security Measures o Unique local administrator passwords should be created for each system. o Unused accounts should be promptly disabled. o Internet browsing from administrative accounts should be prohibited to reduce exposure to web-based threats. • OT-Specific Considerations o In OT environments, administrative access should be limited to essential personnel and functions. o Where shared access is necessary, secure access methods (e.g. jump servers, session logging) should be used to enforce accountability and reduce risk. |
|
A general note, for any purpose. |
The goal of this control is to prevent the use of administrative privileges for routine, day-to-day tasks, thereby reducing the risk of misuse or exploitation by attackers. To ensure this goal is met, the organisation should consider the following: - Account Separation and Privilege Management - Administrative and general user accounts should be strictly separated. - Dedicated administrator accounts should be used only for system management and administrative tasks. - User accounts should not have administrative privileges. - Access Restrictions and Security Measures - Unique local administrator passwords should be created for each system. - Unused accounts should be promptly disabled. - Internet browsing from administrative accounts should be prohibited to reduce exposure to web-based threats. - OT-Specific Considerations - In OT environments, administrative access should be limited to essential personnel and functions. - Where shared access is necessary, secure access methods (e.g. jump servers, session logging) should be used to enforce accountability and reduce risk. |
|
A general note, for any purpose. |
The goal of this control is to prevent the use of administrative privileges for routine, day-to-day tasks, thereby reducing the risk of misuse or exploitation by attackers. To ensure this goal is met, the organisation should consider the following: - Account Separation and Privilege Management - Administrative and general user accounts should be strictly separated. - Dedicated administrator accounts should be used only for system management and administrative tasks. - User accounts should not have administrative privileges. - Access Restrictions and Security Measures - Unique local administrator passwords should be created for each system. - Unused accounts should be promptly disabled. - Internet browsing from administrative accounts should be prohibited to reduce exposure to web-based threats. - OT-Specific Considerations - In OT environments, administrative access should be limited to essential personnel and functions. - Where shared access is necessary, secure access methods (e.g. jump servers, session logging) should be used to enforce accountability and reduce risk. |
|
A general note, for any purpose. |
<div><p>The goal of this control is to prevent the use of administrative privileges for routine, day-to-day tasks, thereby reducing the risk of misuse or exploitation by attackers. To ensure this goal is met, the organisation should consider the following:</p><ul><li>Account Separation and Privilege Management<ul><li>Administrative and general user accounts should be strictly separated.</li><li>Dedicated administrator accounts should be used only for system management and administrative tasks.</li><li>User accounts should not have administrative privileges.</li></ul></li><li>Access Restrictions and Security Measures<ul><li>Unique local administrator passwords should be created for each system.</li><li>Unused accounts should be promptly disabled.</li><li>Internet browsing from administrative accounts should be prohibited to reduce exposure to web-based threats.</li></ul></li><li>OT-Specific Considerations<ul><li>In OT environments, administrative access should be limited to essential personnel and functions.</li><li>Where shared access is necessary, secure access methods (e.g. jump servers, session logging) should be used to enforce accountability and reduce risk.</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-05.4 |
|
skos:prefLabel, skos:altLabel and skos:hiddenLabel are pairwise disjoint properties. |
Administrative privilege restriction |
|
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. |
No one shall have administrative privileges for routine day-to-day tasks. |
|
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