2. Open PowerShell as an administrator

3. Navigate to your downloads folder and extract the sysmon.zip file to a directory outside of your downloads.

PowerShell Command>

cd C:\Users\user\Downloads

Expand-Archive -Path “C:\Users\user\Downloads\Sysmon.zip” -DestinationPath “C:\Users\user\Documents\Sysmon”

4. Download a Sysmon configuration file. Two most common are as follows:

https://github.com/olafhartong/sysmon-modular/tree/master

https://github.com/SwiftOnSecurity/sysmon-config

In this case, we will be working with Olaf Hartong’s ‘sysmonconfig.xml’ file. Navigate to that file path and download the raw file and move the xml to the same directory where you extracted your sysmon executables.

5. Run the following command to complete the installation and configuration of sysmon

.\Sysmon64.exe -i sysmonconfig.xml

6. To confirm successful installation, open Event Viewer.

In Event Viewer, navigate to:

Applications and Services Logs → Microsoft → Windows → Sysmon → Operational

If you are able to access the above path and there are events populated, then congratulations, you have successfully installed and configured Sysmon!

To learn about what you’re seeing and fine tune the tool, I recommend reviewing the Microsoft Sysmon Documentation as well as the documentation/tutorials included with the configuration files.

Let’s start out by defining the resolution codes we typically see as the default:

True Positive — Confirmed malicious activity that triggered an alert

True Negative—No malicious activity has occurred and no alert was triggered

False Positive — An alert was triggered, but no malicious activity has occurred

False Negative — Malicious activity has occurred, but no alert has been triggered

In a large and complex security environment, these four codes can hinder understanding, efficiency, and resolution of security alerts. The issue arises when we have to question; How do we decide which rules need tuning? What do we do when the rule fired correctly, but the activity was benign? How do we create metrics based on alerts to better understand our security posture? Etc.

A better proposal may be to do away with the above resolution codes that are may be default in most SIEM, EDR, and IDS/IPS and replace them with resolution codes that better reflect security events and improve security efficiency.

Out of the four typical security resolution codes, True Negative and False Negative can be discarded. Due to the nature of a true negative, you will not have to worry about closing out a security alert with this closure code. Similarly, false negative could not be the closure code of a security alert as it would trigger no security alerts. A false negative would likely be discovered via threat hunting or during the course of investigation of other security alerts.

The following codes may better reflect the outcome of a security alert:

True Positive — Confirmed malicious activity that triggered an alert. Ex; An alert triggers due to a login to an admin account from an unexpected IP. Investigation confirms that a threat actor attempted the login.

Non-Malicious — Activity occurred and correctly triggered an alert, however the activity is expected/benign. Ex; An alert triggers due to a login to an admin account from an unexpected IP. Investigation shows that the user forgot to connect to the company VPN before logging in.

Penetration Testing — Malicious activity confirmed, however the activity was part of an authorized penetration test.

False Positive — An alert was triggered for events that should not trigger a security alert. Ex; An alert triggers for download of a malicious file based on the hash. Investigation shows that the associated hash was mislabeled as malicious.

Duplicate — This activity was already alerted on and investigated.

Using the above categories provides many benefits. Sometimes we have alerting rules that are quality and needed, but produce both true positive and non-malicious alerts. This is where differentiating between false positive and non-malicious resolution codes is helpful, especially to our detection engineers. Detection engineers can find alerts that were marked as false positives and review, tune, or remove the rules if needed. Whereas, if rules are marked as non-malicious, we will know that the activity needed to be investigated, but the activity was verified as expected or benign.

Additionally, this helps create metrics that more accurately represent security events. We now can identify how many alerts caught on to penetration tests, how many duplicate alerts we are handling, and how many alerts we are handling that should not have alerted in the first place.

As security professionals, we are always thinking about how we can enhance security processes within our organization. The out of the box, default configuration of tooling often does not meet the needs of a security organization. Deeper consideration into configurations such as alert resolution codes can streamline and improve many aspects of our security operations.