Decision-Driven Alert Framework

Share on facebook
Share on google
Share on twitter
Share on linkedin
Alert Framework
April 16, 2020

Decision-Driven Cybersecurity Alert Framework

Below is an alert framework that I have found exceptionally powerful for getting my teams focused on making decisions and taking action when a cybersecurity alert fires. The core ethos is “Take Action and Protect”.  To do that, you need a process that:

  • Improves detection fidelity
  • Communicates institutional knowledge
  • Empowers taking action

Cybersecurity Alert Framework

Title

The title for this alert framework should be informative and succinct. It should target a singular event, i.e. “Non-SA Bastion Log-on” rather than a generic reference, i.e. “Bastion Log-ons”.

Goal

The goal is the intended purpose of the alert. It is a simple, plaintext description of the type of behavior we are attempting to detect with the alert. (It should make sense at 3AM with a head cold.)

Categorization

This is the parent and child category as mapped to the MITRE ATT&CK, Pre-ATT&CK, or MOBILE ATT&CK framework. If it does not map to the framework, simply state that and record where you think it is most closely related.

Alert Abstract

The alert abstract is a high-level walkthrough of how the alert framework functions. This describes what the alert is looking for, what technical data sources are used, any enrichment that occurs, and any false positive minimization steps.

Technical Context

Technical Context provides detailed information and background needed for a responder to understand all components of the alert framework. This should appropriately link to any platform or tooling knowledge and should include information about the direct aspects of the alert. The goal of the Technical Context section is to provide a self-contained reference for a responder to make a judgment call on any potential alert, even if they do not have direct subject matter expertise.

Blind Spots and Assumptions

Blind Spots and Assumptions are the recognized issues, assumptions, and areas where an alert may not fire. No alert is perfect, and identifying assumptions and blind spots can help other engineers understand how an alert may fail to fire or be defeated by an adversary.

False Positives

False Positives are the known instances of an alert misfiring due to a misconfiguration, idiosyncrasy in the environment, or other non-malicious scenarios. The False Positives section notes uniqueness to your own environment and should include the defining characteristics of any activity that could generate a false positive alert.

Validation

Validation is the steps required to generate a representative true positive event that triggers this alert framework. This is similar to a unit test and describes how an engineer can cause the alert to fire. This can be a walkthrough of steps used to generate an alert, a script to trigger the alert (such as Red Canary’s Atomic Red Team Tests). LINK

To perform positive validation:

  • Generate a scenario where a true positive would be generated.
  • Document the process of your testing scenario.
  • From a testing device, generate a true positive alert.
  • Validate the true positive alert was detected by the strategy.

Urgency

Priority describes the alerting level of the alert. This is set as “Severity” in Splunk ES and the combination of the “Severity” of the alert and the “Priority” of the identity or device will generate an updated “Urgency”. The Urgency will impact the SLA and after-hours response time.

Incident Response

This is what we expect the responder to do once the alert has fired. This should include the steps for continuing or completing the investigation and/or the decision we expect the responder to take.

Risk Scoring

Provide a brief explanation of the number of risk points that are assigned to the assets because of this event.


Additional Resources

Additional Resources are any other internal, external, or technical references that may be useful for understanding the alert framework.

Reference and Credit

Inspiration for this came from the Team at Palantir Technologies I migrated all me detection logic/signals to match this new format. Simple, Elegant, Powerful. MEDIUM LINK

As always, credit is deserved to the MITRE ATT&CK team. Twitter LINK

Originally published www.medium.com and www.conorsherman.com and has been republished with permission

lou@cdg.io

lou@cdg.io

Incident Response

If you think you have been the victim of a cyber attack, contact us right now.

  • Determining the extent of a breach
  • Performing a full-scope response from Identification to Recovery
  • Incident Response retainer services, including IR preparation for your team

Contact CDG

We mobilize and launch a complete investigation of any suspected incident within 24 hours.

  • Determining the extent of a breach
  • Performing a full-scope response from Identification to Recovery
  • Incident Response retainer services, including IR preparation for your team