There are various approaches that organizations can take to help ensure that alert severity is properly assessed and to mitigate the impact of alert fatigue.
- One approach is to use a standardized system for evaluating and assigning severity levels to alerts. For example, organizations may use a scale such as the one defined in the National Institute of Standards and Technology (NIST) Cybersecurity Framework, which assigns severity levels based on the potential impact and likelihood of an incident.
Another approach is to use automated tools or algorithms to help determine the severity of alerts. These tools can analyze the data and context associated with an alert and associated with threat intelligence to help determine its likelihood and impact, which can help reduce subjectivity and improve the accuracy of the severity assessment.
To fight alert fatigue, organizations can adopt a number of strategies, such as:
Prioritizing alerts: By prioritizing alerts based on their severity and likelihood of impact, organizations can focus their attention on the most critical incidents and reduce the number of lower-priority alerts that need to be reviewed.
Implementing automated triage and response: Automated tools can help analyze and respond to lower-priority alerts, freeing up time and resources for security analysts to focus on more critical incidents.
Providing ongoing training and support for security analysts: Ensuring that security analysts have the necessary knowledge and skills to effectively evaluate and respond to alerts can help reduce the burden of alert fatigue.
Implementing a robust incident response process: A well-defined and standardized incident response process can help ensure that incidents are handled in an efficient and consistent manner, reducing the need for analysts to constantly reevaluate and respond to alerts.
Correlating alerts to stories rather than the alert itself. Evaluate based on stories rather than individual alerts.
Leverage AI to identify normal things in your alerts.
Search for a product comparison in Network Monitoring Software
IT Support and Network Admin at Escuela Carlos Pereyra
User
Top 5
2022-01-25T14:18:21Z
Jan 25, 2022
I think first of all you need to establish what resources you want to handle in your operation and then how important is each. Once you get it a try based on a "Venn diagram" or an "Eisenhower chart" to apply the resolution tools fatigue is coming from not knowing what tool should use or if the resource with an incident is in danger or not.
Only then you can configure some rules, the information coming from there is gonna give the necessary details for making more decisions.
Maybe, I'm very subjective but there is a very large group of solutions and strategies. Not always it's gonna be the same scenario.
So what you need is a criterion, professional skills, and then... being patient and embracing yourself
I think as long as you do this thing manually, you will always have to be subjective. One will always say alerts from critical assets first, setting them with higher priority.
But the concept of threat intelligence will help. Threat intelligence feeds will help in improving information about the threats you are handling. Without this, your assets and rules you set will always say "hey, this is a serious malicious activity" with brief information unlike when you get feeds from various sources of threat intelligence.
Fighting alert fatigue - It's good to have playbooks do some repetitive work. If an alert is generated, instead of jumping into all of them as analyst, playbook will help you automate some activities like checking file hashes in virus total. At least in the end one will be getting alerts that matters most and with sufficient information added by playbooks.
I&T Design & Execution Reliability Engineering Leader at a financial services firm with 10,001+ employees
Real User
2022-01-26T13:13:01Z
Jan 26, 2022
It depends on the information in your current alerts. E.g if the alert has the priority or the severity field, it will be normal to use this field.
I will assume tha in your current alert system you do not have the severity or priority field.
The next option would be to look at the alert code. Most alarms have a number or a code, indicating the alarm, and it is the reference to documentation - what this alarm means and how to resolve it.
I would then recommend to use this code. Get a list of alarm codes, discuss and determine the severity for this code. Once you have this, you should be able to use this list to match alarms and set the automatic severity, timelines, etc.
Information Security Manager at a retailer with 10,001+ employees
Real User
Top 5
2022-02-01T21:45:11Z
Feb 1, 2022
1. Original thresholds from your tool.
2. Number #1 plus an internal business sense for each asset (other tools, CMDB attribute, SID - Security ID and/or classification tags (baseline, stringent, internet-facing, workstation...).
3. A combination of both, for example, and an extra risk-machine indicator, vulnerability exposure, correlation together with other critical processes.
4. Using a reference framework (NIST) or a mandate from regulators (SEC, ENISA, PCI, HIPAA, ...).
For alert fatigue, you'll need to optimize step-by-step (manual or using automatic/AI features) controls, tunning false-positive and filtering inconsistencies based on PDCA/baby-steps/Continuous Improvement models.
IT Security Coordinator at a healthcare company with 10,001+ employees
Real User
2022-01-24T14:08:16Z
Jan 24, 2022
I think the first step is configuration.
When teams are 1st deploying a new tool, working closely with the vendor to set up the best configuration possible to tune down the alerting for the least false positives, is critical to the success of your soc.
Even paying the extra for a 3rd party tool configuration assessment can be the difference in millions of alerts from vendor recommended alerting.
Then there is a phase of "tuning" where you are in the monitor mode to see what the worst and best alerting is and you go from 80% to 90% false positives. That last 10% is hardest with each tool and causes the most work and the most pain, but if successful you have less critical alerting firing off each device.
Feeding this to the SIEM is where you get the biggest bang for your buck when doing correlation of events, setting proper alerting triggers even for critical alerts can help you prioritize even those.
If you are looking for 10 alerts in the SEIM out of 6 million, you have to prioritize what sets those 10 above the rest so they stick out the most, critical assets, hashtags, threat feeds, UEBA, etc. - all of the things mentioned above are critical to that endeavor.
What are IT alerting and incident management? IT alerting is a process by which the software that is responsible for monitoring the health of an IT system generates alerts that notify the appropriate teams when an incident occurs.
There are various approaches that organizations can take to help ensure that alert severity is properly assessed and to mitigate the impact of alert fatigue.
- One approach is to use a standardized system for evaluating and assigning severity levels to alerts. For example, organizations may use a scale such as the one defined in the National Institute of Standards and Technology (NIST) Cybersecurity Framework, which assigns severity levels based on the potential impact and likelihood of an incident.
Another approach is to use automated tools or algorithms to help determine the severity of alerts. These tools can analyze the data and context associated with an alert and associated with threat intelligence to help determine its likelihood and impact, which can help reduce subjectivity and improve the accuracy of the severity assessment.
To fight alert fatigue, organizations can adopt a number of strategies, such as:
I think first of all you need to establish what resources you want to handle in your operation and then how important is each. Once you get it a try based on a "Venn diagram" or an "Eisenhower chart" to apply the resolution tools fatigue is coming from not knowing what tool should use or if the resource with an incident is in danger or not.
Only then you can configure some rules, the information coming from there is gonna give the necessary details for making more decisions.
Maybe, I'm very subjective but there is a very large group of solutions and strategies. Not always it's gonna be the same scenario.
So what you need is a criterion, professional skills, and then... being patient and embracing yourself
Good luck!
Hi @Evgeny Belenky,
I think as long as you do this thing manually, you will always have to be subjective. One will always say alerts from critical assets first, setting them with higher priority.
But the concept of threat intelligence will help. Threat intelligence feeds will help in improving information about the threats you are handling. Without this, your assets and rules you set will always say "hey, this is a serious malicious activity" with brief information unlike when you get feeds from various sources of threat intelligence.
Fighting alert fatigue - It's good to have playbooks do some repetitive work. If an alert is generated, instead of jumping into all of them as analyst, playbook will help you automate some activities like checking file hashes in virus total. At least in the end one will be getting alerts that matters most and with sufficient information added by playbooks.
@Robert Cheruiyot thank you for such an in-detail answer!
It depends on the information in your current alerts. E.g if the alert has the priority or the severity field, it will be normal to use this field.
I will assume tha in your current alert system you do not have the severity or priority field.
The next option would be to look at the alert code. Most alarms have a number or a code, indicating the alarm, and it is the reference to documentation - what this alarm means and how to resolve it.
I would then recommend to use this code. Get a list of alarm codes, discuss and determine the severity for this code. Once you have this, you should be able to use this list to match alarms and set the automatic severity, timelines, etc.
1. Original thresholds from your tool.
2. Number #1 plus an internal business sense for each asset (other tools, CMDB attribute, SID - Security ID and/or classification tags (baseline, stringent, internet-facing, workstation...).
3. A combination of both, for example, and an extra risk-machine indicator, vulnerability exposure, correlation together with other critical processes.
4. Using a reference framework (NIST) or a mandate from regulators (SEC, ENISA, PCI, HIPAA, ...).
For alert fatigue, you'll need to optimize step-by-step (manual or using automatic/AI features) controls, tunning false-positive and filtering inconsistencies based on PDCA/baby-steps/Continuous Improvement models.
I think the first step is configuration.
When teams are 1st deploying a new tool, working closely with the vendor to set up the best configuration possible to tune down the alerting for the least false positives, is critical to the success of your soc.
Even paying the extra for a 3rd party tool configuration assessment can be the difference in millions of alerts from vendor recommended alerting.
Then there is a phase of "tuning" where you are in the monitor mode to see what the worst and best alerting is and you go from 80% to 90% false positives. That last 10% is hardest with each tool and causes the most work and the most pain, but if successful you have less critical alerting firing off each device.
Feeding this to the SIEM is where you get the biggest bang for your buck when doing correlation of events, setting proper alerting triggers even for critical alerts can help you prioritize even those.
If you are looking for 10 alerts in the SEIM out of 6 million, you have to prioritize what sets those 10 above the rest so they stick out the most, critical assets, hashtags, threat feeds, UEBA, etc. - all of the things mentioned above are critical to that endeavor.
Hi @Evgeny Belenky,
Below are a few strategies if taken into account can reduce cybersecurity alert fatigue in SOC.
1. Threat intelligence
2. Native integration
3. Machine learning
4. Watchlists
5. UEBA (User and Entity Behavior Analytics)
6. Automation