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
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
