In-Scope System with Windows Update Disabled
In-Scope System with Windows Update Disabled
Description
Any GDPR-tagged systems not receiving updates could jeopardize your GDPR status due to Article 32. Detect systems where the Windows Update service is disabled.
Content Mapping
This content is not mapped to any local saved search. Add mapping
GDPR Relevance |
---|
Problem:Keeping up with patch maintenance is a critical part of effective cyber-hygiene. Windows-based systems are especially at risk when unpatched, considering the number and frequency of exploits that use Windows vulnerabilities to establish a foothold, move laterally, or propagate. Windows-based systems that stop updating may be the target of malicious activity -- or, the same type of event may simply be the result of an environmental change, other configuration issue on the host, or scheduled downtime. If the update service itself it disabled on the host, then it may indicate a compromised system. Impact:Unpatched systems put data at risk. For any unpatched environments/systems that are involved in processing personal data, this situation can be critical, and especially so in a GDPR context, since any GDPR-tagged systems not receiving updates could jeopardize a state of compliance. Article 32 of the GDPR requires that organizations regularly test, assess and evaluate effectiveness of implemented technical and organizational security controls. In the event that a Supervisory Authority executes powers to place an organization within the scope of a privacy audit, the organization must demonstrate compliance (Article 58). If the organization faces a personal data breach and individuals are impacted, those individuals have the right to demand compensation for material and non-material damage caused by the breach. The organization must prove that they have understood and addressed the risk appropriately and deployed proper countermeasures (Article 82). Resolution Path:The data mapping exercise from the DPO can inform which Windows-based systems are in-scope -- that is, those systems that are associated with the GDPR category. From there, identify the in-scope systems where updates are not occurring, pinpoint the root issue for updates not occurring, and remediate those hosts by configuring them or the environment appropriately, depending on what the root issue turns out to be. |
How to Implement |
---|
First, use your data mapping results to build a lookup that associates systems to their GDPR category. If you are using the Windows Forwarder with the WinHostMon://Service input configured, this search should work automatically. If you're using another source to detect Service status, you may need to adjust the search string to match your data source. |
Known False Positives |
---|
No known false positives at this time. |
How To Respond |
---|
When Windows Update is disabled, the immediate question is why. Ask the user if they disabled it, look for software installations that might have done it, or look for any errors related to the Windows Update Service (wuauserv.exe). |
Help |
---|
In-Scope System with Windows Update Disabled HelpThis example leverages the Simple Search search assistant. Our example dataset is a collection of anonymized Windows Service 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 standard sourcetypes. |
SPL for In-Scope System with Windows Update Disabled
Demo Data
| First we bring in our basic demo dataset. This dataset includes service status reported via WinHostMon (a part of the Universal Forwarder). We're using a macro called Load_Sample_Log_Data to wrap around | inputlookup, just so it is cleaner for the demo data. |
| Then search for where the service doesn't start automatically |
| 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. |
| Here we use the stats command to calculate what the earliest and the latest time is that we have seen this combination of fields. |
| Next we calculate the most recent value in our demo dataset |
| We end by seeing if the earliest time we've seen this value is within the last day of the end of our demo dataset. |
Live Data
| First we bring in our basic dataset of service status reported via WinHostMon (a part of the Universal Forwarder). We also search for where the service doesn't start automatically |
| Bucket (aliased to bin) allows us to group events based on _time, effectively flattening the actual _time value to the same day. |
| Stats summarizes the status of across the entire environment for better performance. |
| 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. |
| Here we use the stats command to calculate what the earliest and the latest time is that we have seen this combination of fields. |
| We end by seeing if the earliest time we've seen this value is within the last day. |
Screenshot of Demo Data
