How can you prioritize network security alerts and notifications?

I agree with the statement, “define different categories of alerts based on their severity, impact, and urgency” ;however, we should not ignore the impact of a systems location in the network. Suffice to say, the critically of a device could be more impactful if a device was in the DMZ or potentially a public facing application. We should also seek to enrich the data by implementing vulnerability reporting in to the reporting that would help indicate the effectiveness of a potential incident from occurring. There are a lot of different approaches security teams can take. I appreciate the approach of the author when stating that the first step should be to categorize.

I believe you can also use solutions such as SIEMs or EDRs to automate these logs and prioritize them for you to reduce manual labor and save time.

Syslog (which is used in many types of network equipment for logging) supports varying facilities and levels. Setting the correct facility.level is the first step to categorising the alerts correctly so that the right triggers can be applied in accordance to the facility (category) and level (severity).

Use a threat model and understand the various TTPs of attackers. A good way to start: look at MITRE ATT&CK and the complementary framework: MITRE D3F3ND. Based on your threat model and understanding what your organisation is most likely to face, your SOC analysts will be better able to understand the likely causes of certain alerts and the likelihood they correspond to a possible attack that needs to be dealt with, a possible attack that was prevented by existing security tooling, or benign mistakes.

I think we can add one unique twist here "To Gamify.....the Prioritization of network security alerts and notifications" We can create a point system based on the severity of alerts. Critical issues score the highest, followed by high, medium, and low. Turn it into a monthly competition, and the team member with the highest score gets the "Security Guru" title for the next month. It's a fun way to keep everyone engaged, vigilant and prioritize alerts and notifications 24by7

Repeatability and standardization is key to ensuring nothing is missed when responding to an alert. This includes items such as gather telemetry data, establishing contextualization of the victim system and its user(s), understanding type of alert and how it relates to an attack life cycle, and ensuring that all data is packaged in a way that it can be further processed by a relevant responder. Standardized playbooks can be a useful tool for establishing such workflows, however one must remember that a playbook is not the be-all and end-all of incident response and alert management; one must not be blinded by a list of tasks and checklists, but rather ensure that they are thinking critically and dynamically.

The key is to establish a systematic approach to alert workflows. This stepwise methodology should be a part of your security playbooks and follow policies laid out by your company's Incident Response plan (IRP) and contingency plans (CP). They should guide security teams on what IOCs the alerts may indicate, and the steps needed to investigate and mitigate any threats.

Contd.. 3. "Network Traffic does not lie” Wherever event information is limited or falling short. Enable layer 4 and layer 7 flows to gain deeper visibility across all critical segments of the network. 4. Traditional SIEM rules are so déclassé in the current threat landscape, deploying a robust behaviour analytics platform will help address the grey area between the binaries(1 and 0) to gain more visibility including early indications of a threat. 5. Instead of relying on singular alerts use contextual enrichment to combine these alerts into threat chains for higher fidelity. There are a lot more to cover under response and recover. However the above ones are a good start to increase visibility and reduce noise of singular alerts.

Additionally, data sources from your network logs (i.e, traffic analyzers, firewall and IDS/IPS logs) should feed into your central monitoring and alerting system. The sources should be prioritized based on level of risk and potential threats. For example, you may choose to let your email gateway take precedence over firewalls and load balancers. You can also give them the same alert level. Overall, alert prioritization of data sources should be indicated by administrators and configured by network security.

In reality, not every organization has unlimited resources in terms of manpower, time, effort and tools so it is also important to prioritise and formulate the optimal combination of alert sources from various tools with the right prioritisation based on the organisation's risk appetite and compliance requirements.

I would start by classifying network alerts based on their severity and potential impact. Make sure that the most critical issues are addressed first. Automating this process can help sort and categorize these alerts, but it is also important to update your alert system on a regular cadence to make sure that it remains effective.

In collecting metrics one of the first things I point out is you are not collecting data to just collect it. You should be collecting information because you want to do something with it. You may look at your network traffic to see if you have bottlenecks at certain times of day or if your 3rd party SOC is alerting in a timely manner you when specific tools or incidents happen. The key point I tell my teams is anything you collect metrics on needs to be for a purpose and it needs to be data/devices that we own.

In an operational environment, visualizing alert metrics involves collecting and integrating data from various security tools, utilizing advanced visualization tools and dashboards for comprehensive analysis, implementing real-time monitoring solutions, setting up automated reporting mechanisms, fostering cross-functional collaboration, and conducting periodic reviews and analysis. This approach enables organizations to effectively interpret complex data, identify emerging threats, and strengthen their overall security posture.

This is the most critical step. One of the biggest pain points of incident response teams is the sheer volume of alerts that aren't actionable either due to false positives, misconfiguration, duplicative, etc. Active feedback is needed to continuously adjust them while ensuring leakage of false negatives is prevented. Using passive/log-only alerts is a good way to test addition of new alerts as well as retiring/removing redundant ones.

The goal is to ensure alerts are triggered by security events not network noise. Re-configuring your alerting parameters will be a process as you see what causes unnecessary alerts and mitigate them.

Agree with this step, have used this multiple times with internal testing tools to annotate the response time of my 3rd party SOC and how long it took for my deployed technologies in my stack to register an incident had occurred.

It’s also worth considering doing full response drills or table top exercises, working through the actual process on controller alerts, and using them to refine the process.

Training network security alert responders: Developing a robust network security alert program is to train the people who will be responsible for responding to alerts and notifications and ensuring that responders have the skills/knowledge to effectively manage alerts. Recommendations Make the training relevant to the responders' roles and responsibilities. Keep the training up-to-date with the latest threats and vulnerabilities. Provide responders with opportunities to practice their skills in a safe (sandbox) environment. Use a variety of training methods to reach responders with different learning styles. Assess responders' skills and knowledge on a regular basis. Provide responders with ongoing support and development opportunities.

Your description clearly outlines the training of alert responders. To enhance it, consider: Real-Time Drills: Conduct real-time drills to simulate actual alert scenarios, improving response readiness. Performance Metrics: Utilize metrics to evaluate responders’ efficiency, identifying areas for improvement. Continuous Learning: Incorporate lessons from past incidents into training modules for continual learning. Certification Programs: Encourage certifications in relevant areas to ensure a high level of expertise. Collaborative Learning: Promote knowledge-sharing among responders to foster a culture of continuous improvement. Technology Familiarization: Ensure responders are proficient with the tools and platforms used in alert management

Some of the non-IT elements/vendors may not support modifying "priority" in their systems. This one concern can be resolved by using SIEM. SIEM, in which you can set the priority depending upon Event / Elements / Group of Elements etc. will help in a high-level approach.

One the Critical steps is to review the near Realtime intelligence feedback from the systems to monitor extreme abnormalities. Also making sure you actively feed the data into machine learning models and provide an hybrid ecosystem with a semi supervised learning to detect alerts and threats in combination with metrics you are watching and machine learning driven insights. In my experience large scale botnet , spam trap servers and honeypots are easy to detect and discover with the help of models and real time intelligence where human capability doesn't scale.

We can consider using AI to prioritize security alerts. By implementing AI in security alert management, organizations can more effectively identify and respond to threats, minimize false positives, and optimize the allocation of resources to the most critical security issues. This approach not only enhances security but also makes the security team more efficient and responsive.