False positives and how to narrow a rule

A false positive is an alert on activity that is not what the rule is meant to find. Each one costs an analyst's time, and a rule that produces many of them is turned off or ignored, which is how real detections get missed. So the second question about any rule, after "does it catch the attack", is "how often does it fire on a normal system".

The only way to answer that is to run the rule on logs from systems where the activity did not happen. The challenges on this site do this with the logs of a clean Windows 10 client. In this lesson the events are registry writes (Sysmon Event ID 13, category: registry_set), with these fields:

• TargetObject: the full path of the registry value that was written.
• Details: the data that was written.
• Image: the program that wrote it.

Where false positives come from

• Text that is too short. TargetObject|contains: '\Run' matches \Run\, but also \RunOnce\, \RuntimeVersion and \RunLogonScriptSync. Adding the separators that surround the key in the path (\CurrentVersion\Run\) fixes this without losing anything.
• The activity is also normal. Installed programs add themselves to the Run key; that is the purpose of the key. A rule on the key alone fires for every installation. This is solved with more conditions about what was written or who wrote it, not with a shorter list of keys.
• Filters that are too wide. A filter removes normal cases, and everything it removes is also invisible when an attacker does it (lesson 4).

Order of work

1. Make the selection describe the activity precisely: the right field, the full path element, the right modifier. 2. Run it on normal logs and read every false positive. 3. Add a condition that separates the attack from the normal cases (what will run, from where), and only then a filter for named software, with its full path. 4. Write what remains in falsepositives, so whoever handles the alert knows.

In the exercise, step 1 is enough. The Run key challenge is steps 2 and 3.