[UX] Threat Intelligence-based detection

[xeniatup]

With new security threats emerging over time (such as unusual domains, malware signatures, or IP addresses associated with known threat actor) users want to be able to detect those threats in their log data. Threat intel feeds provide customers with a continuous stream of up-to-date information about emerging cyber threats, vulnerabilities, and attack patterns.
One way customers can utilize these feeds is by integrating them into detectors in the form of queries/rules. By doing so, they can automatically flag IoCs containing malicious IP addresses, file hashes, DNS, block-listed emails seen in their logs data.

Additional context around leveraging threat intelligence feeds:
opensearch-project/security-analytics#671
opensearch-project/security-analytics#669
opensearch-project/security-analytics#672

Create detector - Step 1 Define detector

• The threat intel feeds are included as new Detection type on the detector level and is currently available for standard log types.
• The “Detection” section is renamed to Detection rules, and a new section for Threat intelligence feeds is displayed if user selects one of the standard log types for the Detection rules detection.
• By default the checkbox to enable threat intelligence in the detector is checked, but user can opt out from integrating with the feeds.
• A link to documentation with a list of the threat intel feeds that we currently support is provided.

Create detector - Step 2 Alert triggers

• Alerts on the findings originating from the threat intel feeds are included as a part of the second step in the “Create detector” as an additional trigger.
• If user opted out from integrating the detector with the feeds on the previous step, the second trigger doesn’t show on the page, and each new trigger can be only created with a trigger condition for detection rules.
• When a new trigger is created it is defaults to “Detection rules” detection type, and user can change the type of trigger to “Threat intelligence”.
• The trigger name is not a part of “Trigger condition” accordion, but it comes prefilled with a generic default (Trigger 1, Trigger 2, etc.).
• The Notification section is changed to a toggle switch (ON by default) to reinforce the recommendation to configure notification (the notification channel is mandatory unless the toggle switch is OFF).
• Given the increasing complexity of the trigger configuration user can clone a trigger (en example of a use case is to use the same trigger condition, but to notify through a different channel).

Findings list and details

• As the findings that are generated from the threat intel feeds are unrelated to the detection rules, there is no rule name to display for a finding. As the rule name is readily available in the Finding details flyout we remove the column for one from the list view.
• We introduce a new column and a search bar filter for “Detection type” that includes “Detection rules” and “Threat intelligence”.
• In the list views for the findings we show HIGH for the severity of the findings detected from Threat intelligence.
• The “Rule severity” column is renamed to a broader “Severity”

• In the finding details panel we replace the rule information with the Threat intel feed information (a short description and a link to documentation).
• Log type is no longer relevant for all of the finding, so it is replaced with “Detection type” for both finding types.

In “Create trigger alert” flyout we align with the structure from the “Create detector” - Step 2": For threat intel we only allow an alert trigger on any match with the feeds, not a specific value.

View/Edit detector

• As the Threat intelligence detection is enabled on the detector level (See “Create detector”, step 1) we include “Threat intelligence” in the Detector details.
• For the detectors configured for custom log types the "Threat intelligence" section is not displayed.

View detector

Edit detector

[dblock]

Thanks for opening this. Catch All Triage - 1 2 3 4 5

[xeniatup]

Implemented in 2.12