[Security Solution] [Attack discovery] Includes the user.target.name field in the default Anonymization allow list to improve Attack discoveries
#193496
+2
−0
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ame` field in the default Anonymization allow list to improve Attack discoveries ### Summary This PR implements <elastic#193350> by adding the `user.target.name` field to the default Anonymization allow list. The `user.target.name` field will be allowed and anonymized by default. The _Background_ section below describes the purpose of this field, and how it improves Attack discoveries. ### Background In the Elastic Common Schema (ECS), the `user.target.name` field represents the targeted user of an action taken. It is a member of the [Field sets that can be nested under User](https://www.elastic.co/guide/en/ecs/current/ecs-user.html#ecs-user-nestings). Some detection rules make a distinction between the user taking action, and another account that's the _target_ of that action. For example, in the [User Added to Privileged Group](https://www.elastic.co/guide/en/security/current/user-added-to-privileged-group.html) detection rule: - The `user.name` field in the alert identifies the account taking action; in this example the user _adding_ a member to the `Administrators` group - The `user.target.name` field in the alert specifies the account that's the _target_ of the action; in this example it's the account _being added to_ the `Administrators` group Including the `user.target.name` field in the default Anonymization settings improves Attack discoveries, because it enables the model to distinguish between the user taking action and the target of that action when the `user.target.name` field is available, as illustrated by the _Before_ and _After_ images below: **Before**  **After**  ### Desk testing 1) Start a new (development) instance of Elasticsearch: ```sh yarn es snapshot -E path.data=/Users/$USERNAME/data-2024-09-19a ``` 2) Start a local (development) instance of Kibana: ``` yarn start --no-base-path ```` 3) Login to Kibana as the `elastic` user 4) Navigate to Stack Management > License management 5) Click Start trial 6) Navigate to Stack Management > AI Assistants 7) Click `Manage Settings` for the security assistant 8) Click Anonymization 9) Enter `user.target.name` in the search field **Expected results** - The `user.target.name` field is `Allowed` - The `user.target.name` field is `Anonymized` as illustrated by the screenshot below: 
andrew-goldstein
added
release_note:fix
v9.0.0
Team: SecuritySolution
|
Pinging @elastic/security-solution (Team: SecuritySolution) |
💛 Build succeeded, but was flaky
Failed CI StepsMetrics [docs]
To update your PR or re-run it, just comment with: |
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this pull request
Sep 20, 2024
…` field in the default Anonymization allow list to improve Attack discoveries (elastic#193496) ## [Security Solution] [Attack discovery] Includes the `user.target.name` field in the default Anonymization allow list to improve Attack discoveries ### Summary This PR implements <elastic#193350> by adding the `user.target.name` field to the default Anonymization allow list. The `user.target.name` field will be allowed and anonymized by default. The _Background_ section below describes the purpose of this field, and how it improves Attack discoveries. ### Background In the Elastic Common Schema (ECS), the `user.target.name` field represents the targeted user of an action taken. It is a member of the [Field sets that can be nested under User](https://www.elastic.co/guide/en/ecs/current/ecs-user.html#ecs-user-nestings). Some detection rules make a distinction between the user taking action, and another account that's the _target_ of that action. For example, in the [User Added to Privileged Group](https://www.elastic.co/guide/en/security/current/user-added-to-privileged-group.html) detection rule: - The `user.name` field in the alert identifies the account taking action; in this example the user _adding_ a member to the `Administrators` group - The `user.target.name` field in the alert specifies the account that's the _target_ of the action; in this example it's the account _being added to_ the `Administrators` group Including the `user.target.name` field in the default Anonymization settings improves Attack discoveries, because it enables the model to distinguish between the user taking action and the target of that action when the `user.target.name` field is available, as illustrated by the _Before_ and _After_ images below: **Before**  **After**  ### Desk testing 1) Start a new (development) instance of Elasticsearch: ```sh yarn es snapshot -E path.data=/Users/$USERNAME/data-2024-09-19a ``` 2) Start a local (development) instance of Kibana: ``` yarn start --no-base-path ```` 3) Login to Kibana as the `elastic` user 4) Navigate to Stack Management > License management 5) Click Start trial 6) Navigate to Stack Management > AI Assistants 7) Click `Manage Settings` for the security assistant 8) Click Anonymization 9) Enter `user.target.name` in the search field **Expected results** - The `user.target.name` field is `Allowed` - The `user.target.name` field is `Anonymized` as illustrated by the screenshot below:  (cherry picked from commit 349a307)
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this pull request
Sep 20, 2024
…` field in the default Anonymization allow list to improve Attack discoveries (elastic#193496) ## [Security Solution] [Attack discovery] Includes the `user.target.name` field in the default Anonymization allow list to improve Attack discoveries ### Summary This PR implements <elastic#193350> by adding the `user.target.name` field to the default Anonymization allow list. The `user.target.name` field will be allowed and anonymized by default. The _Background_ section below describes the purpose of this field, and how it improves Attack discoveries. ### Background In the Elastic Common Schema (ECS), the `user.target.name` field represents the targeted user of an action taken. It is a member of the [Field sets that can be nested under User](https://www.elastic.co/guide/en/ecs/current/ecs-user.html#ecs-user-nestings). Some detection rules make a distinction between the user taking action, and another account that's the _target_ of that action. For example, in the [User Added to Privileged Group](https://www.elastic.co/guide/en/security/current/user-added-to-privileged-group.html) detection rule: - The `user.name` field in the alert identifies the account taking action; in this example the user _adding_ a member to the `Administrators` group - The `user.target.name` field in the alert specifies the account that's the _target_ of the action; in this example it's the account _being added to_ the `Administrators` group Including the `user.target.name` field in the default Anonymization settings improves Attack discoveries, because it enables the model to distinguish between the user taking action and the target of that action when the `user.target.name` field is available, as illustrated by the _Before_ and _After_ images below: **Before**  **After**  ### Desk testing 1) Start a new (development) instance of Elasticsearch: ```sh yarn es snapshot -E path.data=/Users/$USERNAME/data-2024-09-19a ``` 2) Start a local (development) instance of Kibana: ``` yarn start --no-base-path ```` 3) Login to Kibana as the `elastic` user 4) Navigate to Stack Management > License management 5) Click Start trial 6) Navigate to Stack Management > AI Assistants 7) Click `Manage Settings` for the security assistant 8) Click Anonymization 9) Enter `user.target.name` in the search field **Expected results** - The `user.target.name` field is `Allowed` - The `user.target.name` field is `Anonymized` as illustrated by the screenshot below:  (cherry picked from commit 349a307)
💚 All backports created successfully
Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
kibanamachine
added a commit
that referenced
this pull request
Sep 20, 2024
…target.name` field in the default Anonymization allow list to improve Attack discoveries (#193496) (#193564) # Backport This will backport the following commits from `main` to `8.x`: - [[Security Solution] [Attack discovery] Includes the `user.target.name` field in the default Anonymization allow list to improve Attack discoveries (#193496)](#193496) <!--- Backport version: 9.4.3 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT [{"author":{"name":"Andrew Macri","email":"[email protected]"},"sourceCommit":{"committedDate":"2024-09-20T12:45:41Z","message":"[Security Solution] [Attack discovery] Includes the `user.target.name` field in the default Anonymization allow list to improve Attack discoveries (#193496)\n\n## [Security Solution] [Attack discovery] Includes the `user.target.name` field in the default Anonymization allow list to improve Attack discoveries\r\n\r\n### Summary\r\n\r\nThis PR implements <#193350> by adding the `user.target.name` field to the default Anonymization allow list.\r\n\r\nThe `user.target.name` field will be allowed and anonymized by default.\r\n\r\nThe _Background_ section below describes the purpose of this field, and how it improves Attack discoveries.\r\n\r\n### Background\r\n\r\nIn the Elastic Common Schema (ECS), the `user.target.name` field represents the targeted user of an action taken. It is a member of the [Field sets that can be nested under User](https://www.elastic.co/guide/en/ecs/current/ecs-user.html#ecs-user-nestings).\r\n\r\nSome detection rules make a distinction between the user taking action, and another account that's the _target_ of that action.\r\n\r\nFor example, in the [User Added to Privileged Group](https://www.elastic.co/guide/en/security/current/user-added-to-privileged-group.html) detection rule:\r\n\r\n- The `user.name` field in the alert identifies the account taking action; in this example the user _adding_ a member to the `Administrators` group\r\n- The `user.target.name` field in the alert specifies the account that's the _target_ of the action; in this example it's the account _being added to_ the `Administrators` group\r\n\r\nIncluding the `user.target.name` field in the default Anonymization settings improves Attack discoveries, because it enables the model to distinguish between the user taking action and the target of that action when the `user.target.name` field is available, as illustrated by the _Before_ and _After_ images below:\r\n\r\n**Before**\r\n\r\n\r\n\r\n**After**\r\n\r\n\r\n\r\n### Desk testing\r\n\r\n1) Start a new (development) instance of Elasticsearch:\r\n\r\n```sh\r\nyarn es snapshot -E path.data=/Users/$USERNAME/data-2024-09-19a\r\n```\r\n\r\n2) Start a local (development) instance of Kibana:\r\n\r\n```\r\nyarn start --no-base-path\r\n````\r\n\r\n3) Login to Kibana as the `elastic` user\r\n\r\n4) Navigate to Stack Management > License management\r\n\r\n5) Click Start trial\r\n\r\n6) Navigate to Stack Management > AI Assistants\r\n\r\n7) Click `Manage Settings` for the security assistant\r\n\r\n8) Click Anonymization\r\n\r\n9) Enter `user.target.name` in the search field\r\n\r\n**Expected results**\r\n\r\n- The `user.target.name` field is `Allowed`\r\n- The `user.target.name` field is `Anonymized`\r\n\r\nas illustrated by the screenshot below:\r\n\r\n","sha":"349a30789075f0ef907608987f8cb77247c5e8e3","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:fix","v9.0.0","Team: SecuritySolution","backport:prev-minor","Team:Security Generative AI","v8.16.0","v8.15.2"],"title":"[Security Solution] [Attack discovery] Includes the `user.target.name` field in the default Anonymization allow list to improve Attack discoveries","number":193496,"url":"https://github.com/elastic/kibana/pull/193496","mergeCommit":{"message":"[Security Solution] [Attack discovery] Includes the `user.target.name` field in the default Anonymization allow list to improve Attack discoveries (#193496)\n\n## [Security Solution] [Attack discovery] Includes the `user.target.name` field in the default Anonymization allow list to improve Attack discoveries\r\n\r\n### Summary\r\n\r\nThis PR implements <#193350> by adding the `user.target.name` field to the default Anonymization allow list.\r\n\r\nThe `user.target.name` field will be allowed and anonymized by default.\r\n\r\nThe _Background_ section below describes the purpose of this field, and how it improves Attack discoveries.\r\n\r\n### Background\r\n\r\nIn the Elastic Common Schema (ECS), the `user.target.name` field represents the targeted user of an action taken. It is a member of the [Field sets that can be nested under User](https://www.elastic.co/guide/en/ecs/current/ecs-user.html#ecs-user-nestings).\r\n\r\nSome detection rules make a distinction between the user taking action, and another account that's the _target_ of that action.\r\n\r\nFor example, in the [User Added to Privileged Group](https://www.elastic.co/guide/en/security/current/user-added-to-privileged-group.html) detection rule:\r\n\r\n- The `user.name` field in the alert identifies the account taking action; in this example the user _adding_ a member to the `Administrators` group\r\n- The `user.target.name` field in the alert specifies the account that's the _target_ of the action; in this example it's the account _being added to_ the `Administrators` group\r\n\r\nIncluding the `user.target.name` field in the default Anonymization settings improves Attack discoveries, because it enables the model to distinguish between the user taking action and the target of that action when the `user.target.name` field is available, as illustrated by the _Before_ and _After_ images below:\r\n\r\n**Before**\r\n\r\n\r\n\r\n**After**\r\n\r\n\r\n\r\n### Desk testing\r\n\r\n1) Start a new (development) instance of Elasticsearch:\r\n\r\n```sh\r\nyarn es snapshot -E path.data=/Users/$USERNAME/data-2024-09-19a\r\n```\r\n\r\n2) Start a local (development) instance of Kibana:\r\n\r\n```\r\nyarn start --no-base-path\r\n````\r\n\r\n3) Login to Kibana as the `elastic` user\r\n\r\n4) Navigate to Stack Management > License management\r\n\r\n5) Click Start trial\r\n\r\n6) Navigate to Stack Management > AI Assistants\r\n\r\n7) Click `Manage Settings` for the security assistant\r\n\r\n8) Click Anonymization\r\n\r\n9) Enter `user.target.name` in the search field\r\n\r\n**Expected results**\r\n\r\n- The `user.target.name` field is `Allowed`\r\n- The `user.target.name` field is `Anonymized`\r\n\r\nas illustrated by the screenshot below:\r\n\r\n","sha":"349a30789075f0ef907608987f8cb77247c5e8e3"}},"sourceBranch":"main","suggestedTargetBranches":["8.x","8.15"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/193496","number":193496,"mergeCommit":{"message":"[Security Solution] [Attack discovery] Includes the `user.target.name` field in the default Anonymization allow list to improve Attack discoveries (#193496)\n\n## [Security Solution] [Attack discovery] Includes the `user.target.name` field in the default Anonymization allow list to improve Attack discoveries\r\n\r\n### Summary\r\n\r\nThis PR implements <#193350> by adding the `user.target.name` field to the default Anonymization allow list.\r\n\r\nThe `user.target.name` field will be allowed and anonymized by default.\r\n\r\nThe _Background_ section below describes the purpose of this field, and how it improves Attack discoveries.\r\n\r\n### Background\r\n\r\nIn the Elastic Common Schema (ECS), the `user.target.name` field represents the targeted user of an action taken. It is a member of the [Field sets that can be nested under User](https://www.elastic.co/guide/en/ecs/current/ecs-user.html#ecs-user-nestings).\r\n\r\nSome detection rules make a distinction between the user taking action, and another account that's the _target_ of that action.\r\n\r\nFor example, in the [User Added to Privileged Group](https://www.elastic.co/guide/en/security/current/user-added-to-privileged-group.html) detection rule:\r\n\r\n- The `user.name` field in the alert identifies the account taking action; in this example the user _adding_ a member to the `Administrators` group\r\n- The `user.target.name` field in the alert specifies the account that's the _target_ of the action; in this example it's the account _being added to_ the `Administrators` group\r\n\r\nIncluding the `user.target.name` field in the default Anonymization settings improves Attack discoveries, because it enables the model to distinguish between the user taking action and the target of that action when the `user.target.name` field is available, as illustrated by the _Before_ and _After_ images below:\r\n\r\n**Before**\r\n\r\n\r\n\r\n**After**\r\n\r\n\r\n\r\n### Desk testing\r\n\r\n1) Start a new (development) instance of Elasticsearch:\r\n\r\n```sh\r\nyarn es snapshot -E path.data=/Users/$USERNAME/data-2024-09-19a\r\n```\r\n\r\n2) Start a local (development) instance of Kibana:\r\n\r\n```\r\nyarn start --no-base-path\r\n````\r\n\r\n3) Login to Kibana as the `elastic` user\r\n\r\n4) Navigate to Stack Management > License management\r\n\r\n5) Click Start trial\r\n\r\n6) Navigate to Stack Management > AI Assistants\r\n\r\n7) Click `Manage Settings` for the security assistant\r\n\r\n8) Click Anonymization\r\n\r\n9) Enter `user.target.name` in the search field\r\n\r\n**Expected results**\r\n\r\n- The `user.target.name` field is `Allowed`\r\n- The `user.target.name` field is `Anonymized`\r\n\r\nas illustrated by the screenshot below:\r\n\r\n","sha":"349a30789075f0ef907608987f8cb77247c5e8e3"}},{"branch":"8.x","label":"v8.16.0","branchLabelMappingKey":"^v8.16.0$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.15","label":"v8.15.2","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT--> Co-authored-by: Andrew Macri <[email protected]>
kibanamachine
added a commit
that referenced
this pull request
Sep 23, 2024
….target.name` field in the default Anonymization allow list to improve Attack discoveries (#193496) (#193563) # Backport This will backport the following commits from `main` to `8.15`: - [[Security Solution] [Attack discovery] Includes the `user.target.name` field in the default Anonymization allow list to improve Attack discoveries (#193496)](#193496) <!--- Backport version: 9.4.3 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT [{"author":{"name":"Andrew Macri","email":"[email protected]"},"sourceCommit":{"committedDate":"2024-09-20T12:45:41Z","message":"[Security Solution] [Attack discovery] Includes the `user.target.name` field in the default Anonymization allow list to improve Attack discoveries (#193496)\n\n## [Security Solution] [Attack discovery] Includes the `user.target.name` field in the default Anonymization allow list to improve Attack discoveries\r\n\r\n### Summary\r\n\r\nThis PR implements <#193350> by adding the `user.target.name` field to the default Anonymization allow list.\r\n\r\nThe `user.target.name` field will be allowed and anonymized by default.\r\n\r\nThe _Background_ section below describes the purpose of this field, and how it improves Attack discoveries.\r\n\r\n### Background\r\n\r\nIn the Elastic Common Schema (ECS), the `user.target.name` field represents the targeted user of an action taken. It is a member of the [Field sets that can be nested under User](https://www.elastic.co/guide/en/ecs/current/ecs-user.html#ecs-user-nestings).\r\n\r\nSome detection rules make a distinction between the user taking action, and another account that's the _target_ of that action.\r\n\r\nFor example, in the [User Added to Privileged Group](https://www.elastic.co/guide/en/security/current/user-added-to-privileged-group.html) detection rule:\r\n\r\n- The `user.name` field in the alert identifies the account taking action; in this example the user _adding_ a member to the `Administrators` group\r\n- The `user.target.name` field in the alert specifies the account that's the _target_ of the action; in this example it's the account _being added to_ the `Administrators` group\r\n\r\nIncluding the `user.target.name` field in the default Anonymization settings improves Attack discoveries, because it enables the model to distinguish between the user taking action and the target of that action when the `user.target.name` field is available, as illustrated by the _Before_ and _After_ images below:\r\n\r\n**Before**\r\n\r\n\r\n\r\n**After**\r\n\r\n\r\n\r\n### Desk testing\r\n\r\n1) Start a new (development) instance of Elasticsearch:\r\n\r\n```sh\r\nyarn es snapshot -E path.data=/Users/$USERNAME/data-2024-09-19a\r\n```\r\n\r\n2) Start a local (development) instance of Kibana:\r\n\r\n```\r\nyarn start --no-base-path\r\n````\r\n\r\n3) Login to Kibana as the `elastic` user\r\n\r\n4) Navigate to Stack Management > License management\r\n\r\n5) Click Start trial\r\n\r\n6) Navigate to Stack Management > AI Assistants\r\n\r\n7) Click `Manage Settings` for the security assistant\r\n\r\n8) Click Anonymization\r\n\r\n9) Enter `user.target.name` in the search field\r\n\r\n**Expected results**\r\n\r\n- The `user.target.name` field is `Allowed`\r\n- The `user.target.name` field is `Anonymized`\r\n\r\nas illustrated by the screenshot below:\r\n\r\n","sha":"349a30789075f0ef907608987f8cb77247c5e8e3","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:fix","v9.0.0","Team: SecuritySolution","backport:prev-minor","Team:Security Generative AI","v8.16.0","v8.15.2"],"title":"[Security Solution] [Attack discovery] Includes the `user.target.name` field in the default Anonymization allow list to improve Attack discoveries","number":193496,"url":"https://github.com/elastic/kibana/pull/193496","mergeCommit":{"message":"[Security Solution] [Attack discovery] Includes the `user.target.name` field in the default Anonymization allow list to improve Attack discoveries (#193496)\n\n## [Security Solution] [Attack discovery] Includes the `user.target.name` field in the default Anonymization allow list to improve Attack discoveries\r\n\r\n### Summary\r\n\r\nThis PR implements <#193350> by adding the `user.target.name` field to the default Anonymization allow list.\r\n\r\nThe `user.target.name` field will be allowed and anonymized by default.\r\n\r\nThe _Background_ section below describes the purpose of this field, and how it improves Attack discoveries.\r\n\r\n### Background\r\n\r\nIn the Elastic Common Schema (ECS), the `user.target.name` field represents the targeted user of an action taken. It is a member of the [Field sets that can be nested under User](https://www.elastic.co/guide/en/ecs/current/ecs-user.html#ecs-user-nestings).\r\n\r\nSome detection rules make a distinction between the user taking action, and another account that's the _target_ of that action.\r\n\r\nFor example, in the [User Added to Privileged Group](https://www.elastic.co/guide/en/security/current/user-added-to-privileged-group.html) detection rule:\r\n\r\n- The `user.name` field in the alert identifies the account taking action; in this example the user _adding_ a member to the `Administrators` group\r\n- The `user.target.name` field in the alert specifies the account that's the _target_ of the action; in this example it's the account _being added to_ the `Administrators` group\r\n\r\nIncluding the `user.target.name` field in the default Anonymization settings improves Attack discoveries, because it enables the model to distinguish between the user taking action and the target of that action when the `user.target.name` field is available, as illustrated by the _Before_ and _After_ images below:\r\n\r\n**Before**\r\n\r\n\r\n\r\n**After**\r\n\r\n\r\n\r\n### Desk testing\r\n\r\n1) Start a new (development) instance of Elasticsearch:\r\n\r\n```sh\r\nyarn es snapshot -E path.data=/Users/$USERNAME/data-2024-09-19a\r\n```\r\n\r\n2) Start a local (development) instance of Kibana:\r\n\r\n```\r\nyarn start --no-base-path\r\n````\r\n\r\n3) Login to Kibana as the `elastic` user\r\n\r\n4) Navigate to Stack Management > License management\r\n\r\n5) Click Start trial\r\n\r\n6) Navigate to Stack Management > AI Assistants\r\n\r\n7) Click `Manage Settings` for the security assistant\r\n\r\n8) Click Anonymization\r\n\r\n9) Enter `user.target.name` in the search field\r\n\r\n**Expected results**\r\n\r\n- The `user.target.name` field is `Allowed`\r\n- The `user.target.name` field is `Anonymized`\r\n\r\nas illustrated by the screenshot below:\r\n\r\n","sha":"349a30789075f0ef907608987f8cb77247c5e8e3"}},"sourceBranch":"main","suggestedTargetBranches":["8.x","8.15"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/193496","number":193496,"mergeCommit":{"message":"[Security Solution] [Attack discovery] Includes the `user.target.name` field in the default Anonymization allow list to improve Attack discoveries (#193496)\n\n## [Security Solution] [Attack discovery] Includes the `user.target.name` field in the default Anonymization allow list to improve Attack discoveries\r\n\r\n### Summary\r\n\r\nThis PR implements <#193350> by adding the `user.target.name` field to the default Anonymization allow list.\r\n\r\nThe `user.target.name` field will be allowed and anonymized by default.\r\n\r\nThe _Background_ section below describes the purpose of this field, and how it improves Attack discoveries.\r\n\r\n### Background\r\n\r\nIn the Elastic Common Schema (ECS), the `user.target.name` field represents the targeted user of an action taken. It is a member of the [Field sets that can be nested under User](https://www.elastic.co/guide/en/ecs/current/ecs-user.html#ecs-user-nestings).\r\n\r\nSome detection rules make a distinction between the user taking action, and another account that's the _target_ of that action.\r\n\r\nFor example, in the [User Added to Privileged Group](https://www.elastic.co/guide/en/security/current/user-added-to-privileged-group.html) detection rule:\r\n\r\n- The `user.name` field in the alert identifies the account taking action; in this example the user _adding_ a member to the `Administrators` group\r\n- The `user.target.name` field in the alert specifies the account that's the _target_ of the action; in this example it's the account _being added to_ the `Administrators` group\r\n\r\nIncluding the `user.target.name` field in the default Anonymization settings improves Attack discoveries, because it enables the model to distinguish between the user taking action and the target of that action when the `user.target.name` field is available, as illustrated by the _Before_ and _After_ images below:\r\n\r\n**Before**\r\n\r\n\r\n\r\n**After**\r\n\r\n\r\n\r\n### Desk testing\r\n\r\n1) Start a new (development) instance of Elasticsearch:\r\n\r\n```sh\r\nyarn es snapshot -E path.data=/Users/$USERNAME/data-2024-09-19a\r\n```\r\n\r\n2) Start a local (development) instance of Kibana:\r\n\r\n```\r\nyarn start --no-base-path\r\n````\r\n\r\n3) Login to Kibana as the `elastic` user\r\n\r\n4) Navigate to Stack Management > License management\r\n\r\n5) Click Start trial\r\n\r\n6) Navigate to Stack Management > AI Assistants\r\n\r\n7) Click `Manage Settings` for the security assistant\r\n\r\n8) Click Anonymization\r\n\r\n9) Enter `user.target.name` in the search field\r\n\r\n**Expected results**\r\n\r\n- The `user.target.name` field is `Allowed`\r\n- The `user.target.name` field is `Anonymized`\r\n\r\nas illustrated by the screenshot below:\r\n\r\n","sha":"349a30789075f0ef907608987f8cb77247c5e8e3"}},{"branch":"8.x","label":"v8.16.0","branchLabelMappingKey":"^v8.16.0$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.15","label":"v8.15.2","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT--> Co-authored-by: Andrew Macri <[email protected]> Co-authored-by: Elastic Machine <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
[Security Solution] [Attack discovery] Includes the
user.target.namefield in the default Anonymization allow list to improve Attack discoveriesSummary
This PR implements #193350 by adding the
user.target.namefield to the default Anonymization allow list.The
user.target.namefield will be allowed and anonymized by default.The Background section below describes the purpose of this field, and how it improves Attack discoveries.
Background
In the Elastic Common Schema (ECS), the
user.target.namefield represents the targeted user of an action taken. It is a member of the Field sets that can be nested under User.Some detection rules make a distinction between the user taking action, and another account that's the target of that action.
For example, in the User Added to Privileged Group detection rule:
user.namefield in the alert identifies the account taking action; in this example the user adding a member to theAdministratorsgroupuser.target.namefield in the alert specifies the account that's the target of the action; in this example it's the account being added to theAdministratorsgroupIncluding the
user.target.namefield in the default Anonymization settings improves Attack discoveries, because it enables the model to distinguish between the user taking action and the target of that action when theuser.target.namefield is available, as illustrated by the Before and After images below:Before
After
Desk testing
yarn es snapshot -E path.data=/Users/$USERNAME/data-2024-09-19aLogin to Kibana as the
elasticuserNavigate to Stack Management > License management
Click Start trial
Navigate to Stack Management > AI Assistants
Click
Manage Settingsfor the security assistantClick Anonymization
Enter
user.target.namein the search fieldExpected results
user.target.namefield isAlloweduser.target.namefield isAnonymizedas illustrated by the screenshot below: