Expected Host Not Reporting - in Category

Description

GDPR requires an audit trail for all activities, which means we should be receiving events constantly. Find GDPR-tagged systems that are no longer reporting events but should be.


Use Case

Compliance

Category

GDPR

Security Impact

GDPR requires that you collect the full audit trail of data processing activities and involved systems. If you're breached - Article 33 requires you 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 your organization has to identify which individuals are affected. If you do not have the logs and can't scope it down, you have to assume the worst case scenario: that all the data was affected. In addition: article 32 requires that you implement proper security controls and test their effectiveness. If you stop seeing logs for a host, then you will not be able to prove the status of the applied security controls on their machine, in case of damage claims (82) or privacy audits (58). Penultimately: if you lack host logs, you can't prove which records have been processed, such as proving that you delete a record according an individual's delete request (Article 17) or proving that you complied with a processing restriction requested by an individual (Article 18 and Article 21). Finally: if a host does not report it's event data – a processor can't prove that only authorized individuals have accessed the data.

Alert Volume

Low (?)

SPL Difficulty

Medium

Journey

Stage 4

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.

   How to Implement

First, use your data mapping results to build a lookup that associates systems to their GDPR category. All that is required for this search is to have a valid GDPR lookup, and then any logs in Splunk.

   Known False Positives

The only known situation is where the host goes offline, but you are still tracking it as being required and in scope.

   How To Respond

When this alert fires, the first task will be to see if the host is still alive. If it is, you will need to see if Splunk is still running, or if there are other interruptions to logging. Stopped logging services can indicate an intrusion, so keep an eye out for any indications of malicious behavior.

   Help

Expected Host Not Reporting - in Category Help

This example leverages the Simple Search assistant. Our example dataset is the result of the live search (querying basic logs in Splunk), after a host goes offline.

SPL for Expected Host Not Reporting - in Category

Demo Data

First we bring in our basic demo dataset, which is just a count of events per host (see the live search for detail). We're using a macro called Load_Sample_Log_Data to wrap around | inputlookup, just so it is cleaner for the demo data.
We're filtering for hosts that have always sent us data, and are not currently sending us data.
Next we look up the host in the GDPR categorization lookup. Because we only care about GDPR hosts for this example, we filter for only the hosts that are in scope for GDPR.

Live Data

First we bring in our historical dataset, going back about 7 days.
Then we pull in the number of events seen per host from the last couple of hours.
Now we can use stats to pull those two tstats (with prestats=t) into the light, giving us the recent number, and the historical number per host.
We're filtering for hosts that have always sent us data, and are not currently sending us data.
Finally we look up the host in the GDPR categorization lookup. Because we only care about GDPR hosts for this example, we filter for only the hosts that are in scope for GDPR.

Screenshot of Demo Data