Alert Suppression Experience in socfortress_CoPilot Open Source SIEM Stack

[shaker402]

Is your feature request related to a problem? Please describe.

The current alert system in the socfortress_CoPilot Open Source SIEM Stack can sometimes lead to alert fatigue, making it difficult for cybersecurity professionals to effectively triage and resolve alerts.

Describe the solution you'd like

I would like to see an alert suppression experience similar to the one in Microsoft Defender. This feature should provide tighter control and granularity, allowing users to tune alerts and manage them in advance by streamlining the alert queue and hiding or resolving alerts automatically when a certain expected behavior occurs and rule conditions are met.

The alert suppression feature should also offer the ability to create rule conditions based on evidence types, such as files, processes, scheduled tasks, and others that can trigger alerts. After creating a rule, users should be able to apply the rule on the selected alert or any alert type that meets the rule conditions to suppress the alert.

Describe alternatives you've considered

An alternative could be to improve the current alert system by adding more customization options and filters. However, the alert suppression experience as described above would provide a more comprehensive solution.

Additional context

The new alert suppression function in Microsoft Defender is available by default, but users can switch back to the previous experience via the Microsoft 365 Defender portal by navigating to Settings > Endpoints > Alert suppression, then switch off the “new suppression rules creation enabled” toggle.

In the IOCs section, users can set multiple rule conditions, by selecting Choose IOCs. Use AND, OR and grouping options to build a relationship between these multiple evidence types that cause the alert.

The new experience also allows users to set the scope by selecting specific devices or the entire organization, or by user. Security admins can also prevent IOCs from being blocked in the future.

This feature would greatly enhance the user experience and efficiency of the socfortress_CoPilot Open Source SIEM Stack.

[chadhardcastle]

Why not tune at the source? If your alerts are coming from a combination of Wazuh and/or Graylog you can easily tune the rules to filter out false positives and benign/expected behavior. You can also automate a lot of alerts based on distinct variables using SOAR's like Shuffle etc. I get advanced filtering directly in CoPilot would be great, but the bigger issue is noise from the source that should be tuned out or automated away. Just a thought. Forgive me if I am off kilter on what the request is.

[shaker402]

Dear @chadhardcastle Thank you for your insightful comment. You’ve rightly pointed out the importance of tuning at the source to manage alert noise. This is indeed a best practice we encourage. The feature request for an enhanced alert suppression experience in socfortress_CoPilot is intended to complement, not replace, source-level tuning.

The goal is to provide users with more flexibility and control over their alerts directly within the SIEM, especially for complex environments where multiple sources are involved. This includes the ability to suppress alerts from known trusted sources like specific device IPs, as you mentioned.

We believe that this feature, combined with effective tuning at the source, can provide a more comprehensive and efficient alert management experience. We appreciate your feedback and will take it into account as we continue to improve our system.

[shaker402]

Absolutely, the ability to create suppression rules for specific alerts that are known to be innocuous is a key feature of an effective alert management system. Here’s how I envision this feature working in the socfortress_CoPilot Open Source SIEM Stack:

Feature Description: The enhancement involves allowing users to create suppression rules for specific alerts that are known to be innocuous, such as known tools or processes within the organization. Users should be able to create a suppression condition using the following attributes:

File SHA1 File name (with wildcard support) Folder path (with wildcard support) IP address URL (with wildcard support) Command line (with wildcard support) An AND operator should be applied between each condition, meaning suppression occurs only if all conditions are met. Users should also be able to select the Triggering IOC.

This feature would provide users with greater control over their alert management, reducing noise and improving the efficiency of incident response.

[shaker402]

like , false login from trusted corporate network devices , we can just tune alerts if the device name = ? and agent =? and Ip address ,etc