User Logged into In-Scope System They Should Not Have
User Logged into In-Scope System They Should Not Have
Description
Follow your GDPR requirement and action your data mapping exercise by tracking employee/vendor/supplier access to systems, to ensure that they are authorized to view the data present on any systems they log into.
Content Mapping
This content is not mapped to any local saved search. Add mapping
GDPR Relevance |
---|
Problem:Under the GDPR, organizations are required to maintain a complete audit trail about the authorized access of employees/vendors/suppliers to systems and applications that process personal data. Impact:Per GDPR Article 15, individuals have the right to ask an organization where their data is stored. In order to fulfill such a request, an organization will need to identify which vendors and processors have accessed the personal data in question, and also identify and report on which other services the personal data in question is processed regularly. When processing personal data on behalf of a controller - there will also be a requirement to prove that only authorized individuals have accessed the data in question (Article 28). If there is an audit trail that shows unauthorized access, then this will need to be documented and reported to the data privacy authorities. |
How to Implement |
---|
First, use the results of the data mapping exercise from your data privacy officer to build a lookup that associates systems to the GDPR category. Then do the same for users. Use your data mapping results to build a lookup that associates systems to their GDPR category, and the same for users. At that point, as long as you have the data onboarded with common information model compliance, everything should go smoothly! |
Known False Positives |
---|
This will fire when someone is not in the documented list, so the most common scenario is that the documented list is just old. You can think about automating the update of the authorized user list and pull it from the source where you DPO holds the definitive record of authorized users. Another option is to generalize and enrich the information to departments who are allowed access by enriching the username with the department names. |
How To Respond |
---|
The most likely scenario when this alert fires is that the documentation is simply out of date. Look for indications that someone should be added to the documentation or removed, but validate with your data protection officer or their team before doing so. |
Help |
---|
User Logged into In-Scope System They Should Not Have HelpThis example leverages the Simple Search assistant. Our example dataset is a collection of anonymized Windows Authentication logs, during which someone logs into a new system. Our live search looks for Windows Authentication activity across any index in the standard sourcetype. |
SPL for User Logged into In-Scope System They Should Not Have
Demo Data
| First we bring in our basic demo dataset. This dataset includes interactive logins from Windows Security logs. 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 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. |
| Next we look up the user in the GDPR categorization lookup. |
| Because a user or host can belong to many different categories, we use mvexpand to split them into a multi-value field. |
| Finally we look for users who don't have a matching GDPR category, or who aren't authorized for any GDPR information at all. |
Live Data
| First we bring in our basic dataset. This dataset includes logins from Windows Security logs. |
| Bucket (aliased to bin) allows us to group events based on _time, effectively flattening the actual _time value to the same hour. |
| Now we summarize the number of logins by user, or destination. |
| 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. |
| Next we look up the user in the GDPR categorization lookup. |
| Because a user or host can belong to many different categories, we use mvexpand to split them into a multi-value field. |
| Finally we look for users who don't have a matching GDPR category, or who aren't authorized for any GDPR information at all. |
Screenshot of Demo Data
