Version 3.5

What's new in CDC Version 3.5

January 2024

Highlights

Enhanced Incident Closure Workflow

Now, when an alert closure is initiated via a playbook or API (no\t manually by a user), the system will automatically check if all associated alerts within the incident are closed. If they are, the alert and the entire incident will be closed. Manual closure by users via the UI remains unchanged.

Observable Management: Introducing "Ignorelist" for Improved Accuracy

Users can now refine observables processing with the new "Ignorelist" feature. This feature prevents certain pre-defined observable values from being falsely flagged or categorized, thereby enhancing the accuracy of observables management.
Configurable Setting:
•Access the "Ignorelist" setting via the CDC settings or Grouping Management.
•Perform add, edit, or remove actions on blocklisted observable values.
•Specify both a value and type (e.g., IP address, Domain) for each entry, ensuring uniqueness to avoid duplicates.
•The UI for "grouping blocklist" should mirror the design and functionality of the current ‘Observables Management’ for a consistent experience.
Capabilities:
•Blocklisting should ignore case sensitivity, matching variants such as "unknown", "Unknown", and "uNkNoWn" as the same entry.
•Blocklisted values are still extracted as observables to maintain consistent behavior.
Default "Ignorelist" Values:
•Account Name: unknown
•Source IP: 0.0.0.0 or unknown
•Destination IP: 0.0.0.0 or unknown
•Destination MAC Address: 00:00:00:00:00:00
•Source MAC Address: 00:00:00:00:00:00

Advanced Grouping Rule Customization for Platform Managers

Platform managers now have the ability to influence grouping rules further, allowing for criteria such as company and use case to be factored into the alert attachment process.
For illustration, below are sample rule configurations:
Example Grouping Configurations:

• For Use Cases UC1, UC3, UC7:

  • If 'Source IP' matches one of the given criteria, group under "Grouping for UC1/UC3/UC7".

• For Use Case UC2:

  • Utilize 'Host' along with 'useCase,company' criteria to group accordingly under "Grouping for UC2".
    This new functionality aims to enhance the "added to case" capability, providing a more tailored and streamlined grouping process.

Alert Grouping Flexibility

Enhanced Alert Grouping now permits grouping based on parameters beyond observable matches, improving alert management efficiency and effectiveness.

"Related Incidents" Tab Optimization

Revised the algorithm for the "Related Incidents" tab to improve relevancy by excluding "alert tags" from the incident similarity assessment. Now, the "Overlap %" metric within the Incident and Alert pages is purely based on observable similarity.

Streamlined Incident Closure Process

Added a prompt for users detaching the last alert in an incident, offering an option to close the incident immediately. This saves time by avoiding extra steps and ensures the incident closure workflow is more efficient. If the user opts to close the incident, a manual selection of the closure reason is required, along with a summary note stating "Alerts moved to other incident."

Enhanced Incident Classification and Type Consistency

Introduced automatic incident classification, which mirrors the classification of the first alert attached, streamlining the incident management process. This enables a uniform incident categorization for efficient resolution and accurate reporting.

• Unified Classification Options
  'Alert Classification' and 'Incident Type' fields now display identical options to maintain consistency.

  • Users can edit the 'Alert Classification' options.

  • 'Incident Type' options are directly derived from 'Alert Classification' options.

  • Changes to 'Incident Type' to "Unclassified" are not permitted.

• Automatic 'Incident Type' Setting
  The 'Incident Type' for an incident is automatically determined by the first alert's classification.

  • Users can adjust the 'Incident Type' using a dropdown menu on the incident page.

  • Modifications to the 'Incident Type' won’t affect the current incident data or associated alerts.

  • Incidents cannot be closed or escalated with 'Incident Type' as ‘Unclassified’.

  • Automatic closures via API with "Unclassified" type will proceed without manual reclassification.

• Restrictions for 'Unclassified' Incidents

  • Escalating or closing incidents labeled as ‘Unclassified’ is restricted.

  • Users must select an alternative 'Incident Type' before proceeding with escalation or closure.

• Controlled 'Incident Type' Modifications

  • Modifying 'Incident Type' on the incident page is straightforward with a dropdown list.

  • Changing 'Incident Type' to ‘Unclassified’ through any interface or connector is prohibited.