New Connection to In-Scope Device
New Connection to In-Scope Device
Description
Alert Data Protection Officers to new systems that become involved in processing GDPR-scoped data via network communication logs, so DPOs can ensure the systems are authorized and documented.
Content Mapping
This content is not mapped to any local saved search. Add mapping
GDPR Relevance |
---|
Problem:Data Protection Officers need to be alerted when new systems become involved in processing personal data under the scope of the GDPR, in order to ensure the systems are authorized and processing is properly documented. Impact:In addition to general security benefits, this detection will help inform the data privacy officer whether any new connections have been established to applications or service providers. For these connections, pushing or pulling personal data can be out of compliance. Under Article 30, organizations are required to maintain a record of processing activities, including the name and contact details of the controller, the purposes of the processing, description of the categories of data subjects and personal data processed. Additionally, they must maintain record of categories of recipients to whom the personal data have been or will be disclosed, including recipients in third countries or international. Detecting any new connected applications or service providers which might not be whitelisted or documented, can indicate a potential state of non-compliance state and the Data Privacy Officer will be required to follow up and document. This situation may not impact organizations who employ fewer than 250 persons and therefore may not have critical categories of personal data for processing. |
How to Implement |
---|
First, use your data mapping results to build a lookup that associates systems to their GDPR category. This search should work out of the box with Palo Alto Networks firewalls, and with any other device that uses the Splunk common information model. Just make sure you use a Splunk Add-on that maps them to the Common Information Model (search on Splunkbase!) |
Known False Positives |
---|
No known false positives at this time. |
How To Respond |
---|
When a new host connects to an in-scope GDPR system, check to make sure it is documented. |
Help |
---|
New Connection to In-Scope Device HelpThis example leverages the Simple Search search assistant. Our example dataset is a collection of anonymized Firewall logs (onboarded in accordance with our Data Onboarding Guides), during which someone does something bad. Our live search looks for the same behavior using the standardized sourcetypes for Firewalls or the Common Information Model. |
SPL for New Connection to In-Scope Device
Demo Data
| First we bring in our basic dataset. In this case, Firewall Data. We're using a macro called Load_Sample_Log_Data to wrap around | inputlookup, just so it is cleaner for the demo data. |
| Next we use stats to caluate the earliest and the latest time we've seen this calculation. |
| Eventstats allows us to look across the entire dataset and determine what the largest "latest" time is. This step is only necessary when you don't have fresh data, so it really only applies to the demo 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. |
| Finally, we filter for events where the earliest time seen is within a day of the latest time seen (aka, this is the first time we've seen this). |
Live Data
| First we bring in our basic dataset. In this case, Firewall Data. |
| Next we use stats to caluate the earliest and the latest time we've seen this calculation. |
| 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. |
| Finally, we filter for events where the earliest time is within the last day (aka, this is the first time we've seen this). |
Screenshot of Demo Data
