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. |
DE.CM-03.2: End point and network protection tools that monitor end-user behaviour for danger- ous activity shall be managed. |
|
DE.CM-03.2 |
|
|
http://cyfun.data.gift/data/loc_CyFun2025_Booklet_ESSENTIAL_E_p150 |
|
|
http://cyfun.data.gift/data/loc_CyFun2025_Booklet_IMPORTANT_E_p101 |
|
|
Relates a concept to a concept that is more general in meaning. |
|
|
A general note, for any purpose. |
This control builds on DE.CM-03.1 byshifting the focus from implementation to ongoing management of mon- itoring tools. The goal of this control is to ensure that tools used to monitor user behaviour and detect harmful activity on devices and networks are properly maintained and actively managed. This supports the continued effectiveness of the tools as threats evolve, and ensures that the alerts they produce are accurate, relevant, and helpful for identifying real security risks. To achieve this goal, consider the following: - Tools that monitordevices such as laptops, mobile phones, and servers should be regularlychecked to confirm theyareworking properly, updatedwith the latest threat information, and able to detect newtypes ofattacks. - A central system should be used to collect and analyse logs from different sources. These logs should be complete, up to date, and useful for identifying suspicious activity. - Logs related to system access, such as login attempts or access outside normal hours, should be reviewed regularly. Alerts should be set up to notify security teams of unusual patterns. - Tools that analyse userbehaviourshould be fine-tuned overtime. Securityteams should reviewalerts, adjust detection rules to reduce false alarms, and improve accuracy. - Deception tools, such as fake systems or files designed to attract attackers, should be monitored closely. Alerts from these tools are often early signs of a real attack and should be treated as high priority. - Security teams should regularly assess howwell all monitoring tools are performing, update detection rules, and ensure the tools are integrated with incident response processes. - Roles and responsibilities for monitoring and responding to alerts should be clearly defined. Staff should be trained to use the tools effectively and respond appropriately to incidents. |
|
A general note, for any purpose. |
This control builds on DE.CM-03.1 byshifting the focus from implementation to ongoing management of mon- itoring tools. The goal of this control is to ensure that tools used to monitor user behaviour and detect harmful activity on devices and networks are properly maintained and actively managed. This supports the continued effectiveness of the tools as threats evolve, and ensures that the alerts they produce are accurate, relevant, and helpful for identifying real security risks. To achieve this goal, consider the following: • Tools that monitordevices such as laptops, mobile phones, and servers should be regularlychecked to confirm theyareworking properly, updatedwith the latest threat information, and able to detect newtypes ofattacks. • A central system should be used to collect and analyse logs from different sources. These logs should be complete, up to date, and useful for identifying suspicious activity. • Logs related to system access, such as login attempts or access outside normal hours, should be reviewed regularly. Alerts should be set up to notify security teams of unusual patterns. • Tools that analyse userbehaviourshould be fine-tuned overtime. Securityteams should reviewalerts, adjust detection rules to reduce false alarms, and improve accuracy. • Deception tools, such as fake systems or files designed to attract attackers, should be monitored closely. Alerts from these tools are often early signs of a real attack and should be treated as high priority. • Security teams should regularly assess howwell all monitoring tools are performing, update detection rules, and ensure the tools are integrated with incident response processes. • Roles and responsibilities for monitoring and responding to alerts should be clearly defined. Staff should be trained to use the tools effectively and respond appropriately to incidents. |
|
A general note, for any purpose. |
<div><p>This control builds on DE.CM-03.1 byshifting the focus from implementation to ongoing management of mon- itoring tools. The goal of this control is to ensure that tools used to monitor user behaviour and detect harmful activity on devices and networks are properly maintained and actively managed. This supports the continued effectiveness of the tools as threats evolve, and ensures that the alerts they produce are accurate, relevant, and helpful for identifying real security risks. To achieve this goal, consider the following:</p><ul><li>Tools that monitordevices such as laptops, mobile phones, and servers should be regularlychecked to confirm theyareworking properly, updatedwith the latest threat information, and able to detect newtypes ofattacks.</li><li>A central system should be used to collect and analyse logs from different sources. These logs should be complete, up to date, and useful for identifying suspicious activity.</li><li>Logs related to system access, such as login attempts or access outside normal hours, should be reviewed regularly. Alerts should be set up to notify security teams of unusual patterns.</li><li>Tools that analyse userbehaviourshould be fine-tuned overtime. Securityteams should reviewalerts, adjust detection rules to reduce false alarms, and improve accuracy.</li><li>Deception tools, such as fake systems or files designed to attract attackers, should be monitored closely. Alerts from these tools are often early signs of a real attack and should be treated as high priority.</li><li>Security teams should regularly assess howwell all monitoring tools are performing, update detection rules, and ensure the tools are integrated with incident response processes.</li><li>Roles and responsibilities for monitoring and responding to alerts should be clearly defined. Staff should be trained to use the tools effectively and respond appropriately to incidents.</li></ul></div> |
|
A general note, for any purpose. |
This control builds on DE.CM-03.1 byshifting the focus from implementation to ongoing management of mon- itoring tools. The goal of this control is to ensure that tools used to monitor user behaviour and detect harmful activity on devices and networks are properly maintained and actively managed. This supports the continued effectiveness of the tools as threats evolve, and ensures that the alerts they produce are accurate, relevant, and helpful for identifying real security risks. To achieve this goal, consider the following: - Tools that monitordevices such as laptops, mobile phones, and servers should be regularlychecked to confirm theyareworking properly, updatedwith the latest threat information, and able to detect newtypes ofattacks. - A central system should be used to collect and analyse logs from different sources. These logs should be complete, up to date, and useful for identifying suspicious activity. - Logs related to system access, such as login attempts or access outside normal hours, should be reviewed regularly. Alerts should be set up to notify security teams of unusual patterns. - Tools that analyse userbehaviourshould be fine-tuned overtime. Securityteams should reviewalerts, adjust detection rules to reduce false alarms, and improve accuracy. - Deception tools, such as fake systems or files designed to attract attackers, should be monitored closely. Alerts from these tools are often early signs of a real attack and should be treated as high priority. - Security teams should regularly assess howwell all monitoring tools are performing, update detection rules, and ensure the tools are integrated with incident response processes. - Roles and responsibilities for monitoring and responding to alerts should be clearly defined. Staff should be trained to use the tools effectively and respond appropriately to incidents. |
|
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. |
DE.CM-03.2 |
|
skos:prefLabel, skos:altLabel and skos:hiddenLabel are pairwise disjoint properties. |
Endpoint and network protection management |
|
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. |
End point and network protection tools that monitor end-user behaviour for danger- ous activity shall be managed. |
|
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. |
|
|
The number of triples associated with the subject. |
19 |
|
Specifies the dataset the subject is part of. |
Resultaten 1 - 21 of 21
Inverse links to the subject.
| Property | Subject |
|---|---|
|
Relates a concept to a concept that is more specific in meaning. |
Resultaten 1 - 1 of 1