[Security Solution] [Attack discovery] Attack discovery

[andrew-goldstein]

[Security Solution] [Attack discovery] Attack discovery

Summary

This PR renames the Attack discovery Security Solution feature from its original name, AI Insights.

Above: Attack discovery in the Security Solution

Attack discovery uses AI to identify active attacks in the environment, without the time (or prior experience) required to manually investigate individual alerts in Elastic Security, identify if they are related, and document the identified attack progression.

While users can ask the Assistant to find these progressions today, Attack discovery is a dedicated UI to identify these progressions and action them accordingly. This feature adds a new page, Attack discovery, to the Security Solution's global navigation.

Attack discoveries are generated from Large Language Models (LLMs) to identify attack progressions in alert data, and to correlate and identify related entities and events. When possible, attack progressions are attributed to threat actors.

Details

Users may generate attack discoveries from a variety of LLMs, configured via Connectors:

Above: LLM selection via the connectors popup menu

Clicking on the title of an attack discovery toggles the discovery between the collapsed and expanded state:

Above: Collapsing / expanding an attack discovery (animated gif)

The first three discoveries displayed on the Attack discoveries page are expanded by default. Any additional discoveries that appear after the first three must be expanded manually.

Attack discoveries provide a summary of the entities impacted by an attack. Clicking on an entity, i.e. a hostname or username, displays the entity flyout with the entity's risk summary:

Above: Clicking on a host in the summary of the attack discovery reveals the host risk summary (animated gif)

Hover over fields in the discovery's summary or details to reveal pivot actions for investigations:

Above: Hovering over fields in the details of an attack discovery reveals pivot actions (animated gif)

Attack discoveries are generated from alerts provided as context to the selected LLM. The alert data provided to the LLM is anonymized automatically. Anonymization is configured via the same anonymization settings as the Assistant. Users may override the defaults to allow or deny specific alert fields, and to toggle anonymization on or off for specific fields.

Click the Anonymization toggle to show or hide the actual values sent to the LLM:

Above: Toggling anonymization to reveal the actual values sent to the LLM (animated gif)

Empty prompt

At the start of a session, or when a user selects a connector that doesn't (yet) have any attack discoveries, an empty prompt is displayed.

The animated counter in the empty prompt counts up until it displays the maximum number of alerts that will be sent to the LLM:

Above: An animated counter displays the maximum number of alerts that will be sent to the LLM (animiated gif)

The Settings section of this PR details how users configure the number of alerts sent to the LLM. The animated counter in the empty prompt immediately re-animates to the newly-selected number when the setting is updated.

Take action workflows

The Take action popover displays the following actions:

• Add to new case
• Add to existing case
• View in AI Assistant

Above: The Take action popover

Add to new case

Clicking the Add to new case action displays the Create case flyout.

Above: The Add to new case workflow

An Alerts were added to <case name> toast is displayed when the case is created:

Above: Case creation toast

A markdown representation of the attack discovery is added to the case:

Above: A markdown representation of an attack discovery in a case

The alerts correlated to generate the discovery are attached to the case:

Above: Attack discovery alerts attached to a case

Add to existing case

Clicking the Add to existing case action displays the Select case popover.

Above: The Select case popover

When users select an existing case, a markdown representation of the attack discovery, and the alerts correlated to generate the discovery are attached to the case, as described above in the Add to new case section.

View in AI Assistant

The View in AI Assistant action in the Take action popover, and two additional View in AI Assistant affordances that appear in each discovery have the same behavior:

Clicking View in AI Assistant opens the assistant and adds the attack discovery as context to the current conversation.

Above: An attack discovery added as context to the current conversation

Clicking on the attack discovery in the assistant expands it to reveal a preview of the discovery.

Above: An expanded attack discovery preview in the assistant

The expanded attack discovery preview reveals the number of anonymzied fields from the discovery that were made available to the conversation. This feature ensures discoveries are added to a conversation with the anonymized field values.

An attack discovery viewed in the AI assistant doesn't become part of the conversation until the user submits it by asking a question, e.g. How do I remediate this?.

Attack discoveries provided as context to a conversation are formatted as markdown when sent to the LLM:

Above: Attack discoveries provided as context to a conversation are formatted as markdown

Users may toggle anonymization in the conversation to reveal the original field values.

Above: Revealing the original field values of an attack discovery added as markdown to a conversation (animated gif)

Alerts tab

The Alerts tab displays the alerts correlated to generate the discovery.

Above: The alerts correlated to generate the attack discovery in the Alerts tab

The View details, Investigate in timeline, and overflow row-level alert actions displayed in the Alerts tab are the same actions available on the Cases's page's Alerts tab:

Above: Row-level actions are the same as the Cases pages Alert's tab

Investigate in Timeline

Click an attack discovery's Investigate in Timeline button to begin an investigation of an discovery's alerts in Timeline. Alert IDs are queried via the Alert Ids filter:

Above: Clicking Investigate in Timeline (animated gif)

The alerts from the attack discovery are explained via row renderers in Timeline:

Above: Row rendered attack discovery alerts in Timeline

Attack Chain

When alerts are indicative of attack tactics, those tactics are displayed in the discovery's Attack Chain section:

Above: An attack discovery with tactics in the Attack chain

The Attack Chain section will be hidden if an attack discovery is not indicative of specific tactics.

Mini attack chain

Every attack discovery includes a mini attack chain that visually summarizes the tactics in a discovery. Hovering over the mini attack chain reveals a tooltip with the details:

Above: The mini attack chain tooltip

Storage

The latest attack discoveries generated for each connector are cached in the browser's session storage in the following key:

elasticAssistantDefault.attackDiscovery.default.cachedAttackDiscoveries

Caching attack discoveries in session storage makes it possible to immediately display the latest when users return to the Attack discoveries page from other pages in the security solution (e.g. Cases).

Above: Cached attack discoveries from session storage are immediately displayed when users navigate back to Attack discoveries (animated gif)

While waiting for a connector to generate results, users may view the cached results from other connectors.

Cached attack discoveries are immediately available, even after a full page refresh, as long as the browser session is still active.

Approximate time remaining / Above average time counters

Some LLMs may take seconds, or even minutes to generate attack discoveries. To help users anticipate the time it might take to generate new discoveries, the page displays a Approximate time remaining: mm:ss countdown timer that counts down to zero from the average time it takes to generate discoveries for the selected LLM:

Above: The Approximate time remaining: mm:ss countdown counter (animated gif)

If the LLM doesn't generate attack discoveries before the counter reaches zero, the text will change from Approximate time remaining: mm:ss to Above average time: mm:ss, and start counting up from 00:00 until the attack discoveries are generated:

Above: The Above average time: mm:ss counter (animated gif)

The first time attack discoveries are generated for a model, the Approximate time remaining: mm:ss counter is not displayed.

Average time is calculated over the last 5 generations on the selected connector. This is illustrated by clicking on the (?) information icon next to the timer. The popover displays the average time, and the time in seconds for the last 5 runs:

Above: Clicking on the (?) information icon displays the average time, and the duration / datetimes for the last 5 generations

The time and duration of the last 5 generations (for each connector) are persisted in the browser's local storage in the following key:

elasticAssistantDefault.attackDiscovery.default.generationIntervals

Errors

When attack discovery generation fails, an error toaster is displayed to explain the failure:

Above: An error toast explains why attack discovery generation failed

Feature flag

The attackDiscoveryEnabled feature flag must be enabled to view the Attack discovery link in the Security Solution's global navigation.

Add the attackDiscoveryEnabled feature flag to the xpack.securitySolution.enableExperimental setting in config/kibana.yml (or config/kibana.dev.yml in local development environments), per the example below:

xpack.securitySolution.enableExperimental: ['attackDiscoveryEnabled']

Settings

The number of alerts sent as context to the LLM is configured by Knowledge Base > Alerts slider in the screenshot below:

• The slider has a range of 10 - 100 alerts (default: 20)

Up to n alerts (as determined by the slider) that meet the following criteria will be returned:

• The kibana.alert.workflow_status must be open
• The alert must have been generated in the last 24 hours
• The alert must NOT be a kibana.alert.building_block_type alert
• The n alerts are ordered by kibana.alert.risk_score, to prioritize the riskiest alerts

License

An Enterprise license is required to use Attack discovery.

The following empty view is displayed for users who don't have an Enterprise license:

How it works

• Users navigate to the Attack discovery page: x-pack/plugins/security_solution/public/attack_discovery/pages/index.tsx

• When users click the Generate button(s) on the Attack discovery page, attack discoveries are fetched via the useAttackDiscovery hook in x-pack/plugins/security_solution/public/attack_discovery/use_attack_discovery/index.tsx.

• The fetchAttackDiscoveries function makes an http POST request is made to the /internal/elastic_assistant/attack_discovery route. Requests include the following parameters:

  • actionTypeId, determines temperature and other connector-specific request parameters
  • alertsIndexPattern, the alerts index for the current Kibana Space, e.g. .alerts-security.alerts-default
  • anonymizationFields, the user's Allowed and (when applicable Anonymized ) fields in the Anonymization settings, e.g. ["@timestamp", "cloud.availability_zone", "file.name", "user.name", ...]
  • connectorId, id of the connector to generate the attack discoveries
  • size, the maximum number of alerts to generate attack discoveries from. This numeric value is set by the slider in the user's Knowledge Base > Alerts setting, e.g. 20
  • replacements, an optional Record<string, string> collection of replacements that's always empty in the current implementation. When non-empty, this collection enables new attack discoveries to be generated using existing replacements.

"replacements": {
    "e4f935c0-5a80-47b2-ac7f-816610790364": "Host-itk8qh4tjm",
    "cf61f946-d643-4b15-899f-6ffe3fd36097": "rpwmjvuuia",
    "7f80b092-fb1a-48a2-a634-3abc61b32157": "6astve9g6s",
    "f979c0d5-db1b-4506-b425-500821d00813": "Host-odqbow6tmc",
    // ...
},

• The postAttackDiscoveryRoute function in x-pack/plugins/elastic_assistant/server/routes/attack_discovery/post_attack_discovery.ts handles the request.

• The inputs and outputs to/from this route are defined by the OpenAPI schema in x-pack/packages/kbn-elastic-assistant-common/impl/schemas/attack_discovery/post_attack_discovery_route.schema.yaml.

node scripts/generate_openapi --rootDir ./x-pack/packages/kbn-elastic-assistant-common

• The postAttackDiscoveryRoute route handler function in x-pack/plugins/elastic_assistant/server/routes/attack_discovery/post_attack_discovery.ts invokes the attack-discovery tool, defined in x-pack/plugins/security_solution/server/assistant/tools/attack_discovery/attack_discovery_tool.ts.

The attack-discovery tool is registered by the Security Solution. Note: The attack-discovery tool is only used by the attack discovery page. It is not used to generate new attack discoveries from the context of an assistant conversation, but that feature could be enabled in a future release.

• The attack-discovery tool uses a LangChain OutputFixingParser to create a prompt sandwich with the following parts:

  ______________________________________________________
 /                                                      \
|     Attack discovery JSON formatting instructions     | (1)
 \ _____________________________________________________/
 +-----------------------------------------------------+
 |    Attack discovery prompt                          |  (2)
 +-----------------------------------------------------+
 /                                                     \
|     Anonymized Alerts                                |   (3)
 \_____________________________________________________/

• The Attack discovery JSON formatting instructions in section (1) of the prompt sandwich are defined in the getOutputParser() function in x-pack/plugins/security_solution/server/assistant/tools/attack_discovery/get_output_parser.ts. This function creates a LangChain StructuredOutputParser from a Zod schema. This parser validates responses from the LLM to ensure they are formatted as JSON representing an attack discovery.

• The Attack discovery prompt in section (2) of the prompt sandwich is defined in the getAttackDiscoveryPrompt() function in x-pack/plugins/security_solution/server/assistant/tools/attack_discovery/get_attack_discovery_prompt.ts. This part of the prompt sandwich includes instructions for correlating alerts, and additional instructions to the LLM for formatting JSON.

• The Anonymized Alerts in section (3) of the prompt sandwich are returned by the getAnonymizedAlerts() function in x-pack/plugins/security_solution/server/assistant/tools/attack_discovery/get_anonymized_alerts.ts. The allow lists configured by the user determine which alert fields will be included and anonymized.

• The postAttackDiscoveryRoute route handler returns the attack discoveries generated by the attack-discovery tool to the client (browser).

• Attack discoveries are rendered in the browser via the AttackDiscoveryPanel component in x-pack/plugins/security_solution/public/attack_discovery/attack_discovery_panel/index.tsx

• The AttackDiscoveryTab tab in x-pack/plugins/security_solution/public/attack_discovery/attack_discovery_panel/tabs/attack_discovery_tab/index.tsx includes the Summary and Details section of the attack discovery.

• The AttackDiscoveryMarkdownFormatter in x-pack/plugins/security_solution/public/attack_discovery/attack_discovery_markdown_formatter/index.tsx renders hover actions on entities (like hostnames and usernames) and other fields in the attack discovery.

• The AttackDiscoveryPanel component makes use of the useAssistantOverlay hook in x-pack/packages/kbn-elastic-assistant/impl/assistant/use_assistant_overlay/index.tsx to register the attack discovery as context with the assistant. This registration process makes it possible to view discoveries in the assistant, and ask questions like "How do I remediate this?". In this feature, the useAssistantOverlay hook was enhanced to accept anonymizaton replacements. This enables an assistant conversation to (re)use replacements originally generated for an attack discovery.

[elasticmachine]

Pinging @elastic/security-solution (Team: SecuritySolution)

[andrew-goldstein]

Files by Code Owner

elastic/security-threat-hunting-explore

• x-pack/packages/security-solution/features/src/assistant/kibana_sub_features.ts
• x-pack/plugins/security_solution/public/common/components/navigation/security_side_nav/categories.ts

[semd]

LGTM.
Thanks @andrew-goldstein for pointing out elastic/security-threat-hunting-explore files. Github is not doing a great job with the file filter:

😂

[stephmilovic]

Great work Andrew. Ran locally and all works as expected. LGTM

[kibana-ci]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: 1c00115
• Cloud Deployment

Failed CI Steps

• Jest Tests #4

Test Failures

• [job] [logs] Jest Tests #4 / SyncAlertsToggle it shows the correct labels

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
securitySolution	5457	5458	+1

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
securitySolution	17.4MB	17.4MB	+1.3KB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
securitySolution	82.6KB	82.7KB	+79.0B
securitySolutionEss	15.5KB	15.5KB	+10.0B
securitySolutionServerless	19.1KB	19.1KB	+10.0B
total			+99.0B

History

• 💛 Build #206377 was flaky 2d4289f3bab58f3172d78925aee76499e3dd50ef
• 💛 Build #206288 was flaky f6501693a237ec769842c6d12b3256dae1dc545f

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @andrew-goldstein

[andrew-goldstein]

💚 All backports created successfully

Status	Branch	Result
✅	8.14

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation