Skip to content

Conversation

@paul-tavares
Copy link
Contributor

@paul-tavares paul-tavares commented Apr 14, 2025

Summary

The following changes are in support of space awareness for response actions (currently behind feature flag: endpointManagementSpaceAwarenessEnabled). All response actions will now start to store agent policy information.

  • A new property will be stored in the Action Request document that captures policy information about each agent the action was sent to (agent.policy: []).
  • All response action client instances must now be initiated with a spaceId
  • A new method was added to the internal Fleet Services to retrieve all namespace's in use by a given integration type in the active space
  • The SentinelOne and Microsoft run host scripts were enhaced so that the host VM name includes the space id

Testing space awareness setup

Warning

Microsoft Defender response actions will fail with a message indicating that it was unable to find elastic agens for the MS agent ids provided on input. This error will persist until a new build of Elsaticsearch is released. A change was needed to the kibana_system role

Enable feature flags

xpack.securitySolution.enableExperimental:
  - endpointManagementSpaceAwarenessEnabled

xpack.fleet.enableExperimental:
  - useSpaceAwareness

Switch Fleet to Space aware

POST /internal/fleet/enable_space_awareness
Elastic-Api-Version: 1,

Add additional mappings for response actions

Note

Only needed until the Endpoint Package is updated with these mappings

Ensure that the Endpoint package is installed

Best way to do this is to create at least one integration policy in fleet.

Add mappings if not already included in index mapping

Tip

These instructions can be done from the Kibana Dev tools console

Ensure index exists:

PUT /_data_stream/.logs-endpoint.actions-default

Ignore any resource_already_exists_exception error that might be returned.

Check to see if the mapping is already present:

GET /.logs-endpoint.actions-default/_mapping/field/agent.policy*

If the response returns an empty mappings, then mappings need to be added

Add mappings to the index:

PUT /.logs-endpoint.actions-default/_mapping
{
  "properties": {
    "agent": {
      "properties": {
        "policy": {
          "properties": {
            "agentId": { "type": "keyword" },
            "elasticAgentId": { "type": "keyword" },
            "integrationPolicyId": { "type": "keyword" },
            "agentPolicyId": { "type": "keyword" }
          }
        }
      }
    }
  }
}

Add data

You should now be all setup to load data for testing. Remember that space data visibility is mostly driven by Fleet and how Policies are setup and shared between spaces - Agent Policies now have a Space ID field to manage this.

Our scripts that run live VMs for each type o9f EDR have been updated to support a --spaceId CLI argument and thus can be used to target specific spaces.

Checklist

@paul-tavares paul-tavares added release_note:skip Skip the PR/issue when compiling release notes backport:skip This PR does not require backporting Team:Defend Workflows “EDR Workflows” sub-team of Security Solution v9.1.0 labels Apr 14, 2025
@paul-tavares paul-tavares self-assigned this Apr 14, 2025
@paul-tavares
Copy link
Contributor Author

/ci

@paul-tavares
Copy link
Contributor Author

/ci

@paul-tavares paul-tavares requested review from ashokaditya and pzl April 17, 2025 14:33
@elasticmachine
Copy link
Contributor

Pinging @elastic/security-defend-workflows (Team:Defend Workflows)

@paul-tavares paul-tavares requested review from szwarckonrad and removed request for pzl April 17, 2025 20:05
paul-tavares added a commit to paul-tavares/kibana that referenced this pull request Apr 17, 2025
Copy link
Contributor

@szwarckonrad szwarckonrad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code and logic behind it LGTM!

};
microsoft: {
// eslint-disable-next-line @typescript-eslint/no-explicit-any
defender_endpoint: Record<string, any>;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we can go with an unknown?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll check if unknown will work as well.

connectorActions.setup(SENTINELONE_CONNECTOR_ID);
}

private async fetchSentinelOneAgentIndexNames(): Promise<string[]> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Feels like this could be abstracted in the base class — just caching and retrieving, right? I think you're already doing something similar for other connectors. Ignore this if that’s not the case.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I usually push methods/logic to the base class only if its something that applies to all EDR types (generic). In this case, the index names will be different depending on the EDR type, so I felt like it was most appropriate for it to live in each respective sub-class.


// Kibana CORE will take care of `500` errors when the handler `throw`'s, including logging the error
throw error;
// Kibana core server handling of `500` errors does not actually return the `error.message` encountered,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔥

const doc: LogsEndpointAction<TParameters, TOutputContent, TMeta> = {
'@timestamp': new Date().toISOString(),
// Need to suppress this TS error around `agent.policy` not supporting `undefined`.
// It will be removed once we enable the feature and delete the feature flag checks.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe add a // TODO here for visibility

],
crowdstrike: ['device.id'],
microsoft_defender_endpoint: [
'cloud.instance.id',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🙇🏼 Thanks for sorting!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😄

FYI:
I actually did not sort it on purpose. I only moved cloud.instance.id up so that it is the first one we try to find in MS documents. thats because I'm still not 100% sure of the other fields defined below because we never really set up the M365 integration. I got these values from an Env. that Raquel has where she did setup M365.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah I see. Well, sorted values are always nice to maintain. 🌞

@paul-tavares paul-tavares enabled auto-merge (squash) April 23, 2025 12:44
@elasticmachine
Copy link
Contributor

elasticmachine commented Apr 23, 2025

💔 Build Failed

Failed CI Steps

Test Failures

  • [job] [logs] Jest Tests #4 / Update Insights Route Handler standard operations and authz should throw if retrieved insight is missing
  • [job] [logs] Jest Tests #4 / Update Insights Route Handler standard operations and authz should throw if retrieved insight is missing

Metrics [docs]

Unknown metric groups

ESLint disabled in files

id before after diff
securitySolution 85 86 +1

Total ESLint disabled count

id before after diff
securitySolution 670 671 +1

History

cc @paul-tavares

@paul-tavares paul-tavares merged commit 70d6f40 into elastic:main Apr 23, 2025
9 checks passed
@paul-tavares paul-tavares deleted the task/olm-11225-store-policy-id-in-action-request-for-spaces branch April 23, 2025 21:09
akowalska622 pushed a commit to akowalska622/kibana that referenced this pull request May 29, 2025
… it store policy information when action is created (elastic#218175)

## Summary

The following changes are in support of space awareness for response
actions (currently behind feature flag:
`endpointManagementSpaceAwarenessEnabled`). All response actions will
now start to store agent policy information.

- A new property will be stored in the Action Request document that
captures policy information about each agent the action was sent to
(`agent.policy: []`).
- All response action client instances must now be initiated with a
`spaceId`
- A new method was added to the internal Fleet Services to retrieve all
`namespace`'s in use by a given integration type in the active space
- The SentinelOne and Microsoft run host scripts were enhaced so that
the host VM name includes the space id
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

backport:skip This PR does not require backporting release_note:skip Skip the PR/issue when compiling release notes Team:Defend Workflows “EDR Workflows” sub-team of Security Solution v9.1.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants