☰
Navigation :

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


Use Case

Security Monitoring, Compliance

Category

GDPR, Operations

Security Impact

In addition to the general security benefits, this detection will help the data privacy officer of an organization in their GDPR requirements to detect if any new applications or service providers have been connected to push or pull personal data without the proper documentation. This helps to trigger the update of the documentation and engage the DPO, enabling continuous monitoring to detect unauthorized and undocumented new applications that do not follow corporate processes.

Alert Volume

Low

SPL Difficulty

Basic

Data Availability

Bad

Journey

Stage 4

Data Sources

Network Communication

   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 Help

This 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

| `Load_Sample_Log_Data(Sample Firewall 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.
| stats count min(_time) as earliest max(_time) as maxtime  by src_ip, dest_ip
Next we use stats to caluate the earliest and the latest time we've seen this calculation.
| eventstats max(maxtime) as maxtime
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.
| lookup gdpr_system_category host as dest_ip | search category=*
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.
| where earliest>relative_time(maxtime, "-1d@d")
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

index=* ((tag=traffic tag=communicate) sourcetype=zscalernss-fw OR sourcetype=pan*traffic OR sourcetype=opsec OR sourcetype=cisco*) src_ip=* dest_ip=*
First we bring in our basic dataset. In this case, Firewall Data.
| stats count min(_time) as earliest max(_time) as maxtime  by src_ip, dest_ip
Next we use stats to caluate the earliest and the latest time we've seen this calculation.
| lookup gdpr_system_category host as dest_ip | search category=*
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.
| where earliest>relative_time(now(), "-1d@d")
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