Expected Host Not Reporting

Description

Discovers hosts that are longer reporting events but should be submitting log events. This rule is used to monitor hosts that you know should be providing a constant stream of logs in order to determine why the host has failed to provide log data.

Content Mapping

This content is not mapped to any local saved search. Add mapping


Use Case

Security Monitoring, Compliance

Category

Operations, GDPR

Alert Volume

Discovers hosts that are longer reporting events but should be submitting log events. This rule is used to monitor hosts that you know should be providing a constant stream of logs in order to determine why the host has failed to provide log data.

SPL Difficulty

Advanced

Journey

Stage 4

MITRE ATT&CK Tactics

Defense Evasion

MITRE ATT&CK Techniques

Disabling Security Tools

Disable or Modify Tools

MITRE Threat Groups

BRONZE BUTLER
FIN6
Gamaredon Group
Gorgon Group
Kimsuky
Lazarus Group
Night Dragon
Putter Panda
Rocke
Turla
Wizard Spider

Data Sources

Any Splunk Logs

   GDPR Relevance

Problem:

Many compliance and regulatory frameworks contain clauses specifying requirements for central logging of event data, as well as retention periods and use of that data to assist in detecting data breaches and investigation and handling of threats. These regulations also specify that a mechanism exist to notify when critical systems stop forwarding event data. For example, tracking of “initialization, stopping, or pausing of audit logs”. This is directly related to the fact that commonly, the intent behind disruption to event data forwarding is malicious, e.g. an attempt to evade a preventive measure or to avoid detection.

Impact:

The GDPR requires that organizations collect the full audit trail of data processing activities of involved systems and applications. This can impact the organization via a wide array of GDPR articles. If breached, Article 33 requires organizations to inform the authorities, including details about the nature of the breach, such as how many individuals have been affected. The same requirement is in Article 34 for when organizations must identify which individuals are affected, in order to notify them if there is a high risk related to their individual data. If organizations do not store the requisite logs and are therefore not able to proper scope the impact, data privacy officers will need to assume the worst case scenario: all personal data that was stored or processed in the breached environment or accessible by the breached user was affected. In addition, Article 32 requires implementation of proper security controls, and for organizations to monitor, test, and demonstrate their effectiveness. If an organization experiences that logging stops for a particular host or set of hosts, then the organization will not be able to prove the status and effectiveness of the applied security controls on those systems, in the event of damage claims (Article 82) or privacy audits (Article 58). If the organization lacks host logs and corresponding application logs, they will not be able to prove which records have been processed, such as proving that a record was deleted according to an individual's delete request (Article 17) or proving compliance with a processing restriction requested by an individual (Article 18 and Article 21). If a host does not report event data, a processor cannot prove that only authorized individuals have accessed the data (Article 28).

Resolution Path:

Identify all GDPR-relevant IT assets from the data mapping exercise conducted by the Data Privacy Officer’s team -- that is, all IT assets that are relevant to the full audit trail of data processing activities. This includes not only data stores and repositories that house sensitive PD / PII, but also any technologies that are involved in the processing, storage, transmission, receipt, rendering, encrypt/decrypt, relaying, and any other function that involves handling that data in any capacity. Ensure that those assets are configured properly to report logging activity to an appropriate central repository. Monitor for changes in logging status, adjust for known outages, and prioritize incident response for any failures to report by hosts that are not scheduled for downtime.