Privileged Access Detection

The Privileged Access Detection package contains assets to detect anomalous privilege access activity in the Windows, Linux and Okta system logs. This package requires a Platinum subscription. Please ensure that you have a Trial, Platinum, or Enterprise subscription before proceeding. This package is licensed under Elastic License 2.0.

1. Add the Integration Package: Install the package via Management > Integrations > Add Privileged Access Detection. Configure the integration name and agent policy. Click Save and Continue.
2. Configure the pipeline: To configure the pipeline you can use one of the following steps:
   • If using Elastic Defend, add a custom pipeline to the data stream. Go to Stack Management > Ingest Pipelines, and check if the pipeline logs-endpoint.events.process@custom exists. If it does not exist, you can create it by running the following command in the Dev Console. Be sure to replace <VERSION> with the current package version.

     PUT _ingest/pipeline/logs-endpoint.events.process@custom
     {
       "processors": [
         {
           "pipeline": {
             "name": "<VERSION>-ml_pad_ingest_pipeline",
             "ignore_missing_pipeline": true,
             "ignore_failure": true
           }
         }
       ]
     }
     

   • If logs-endpoint.events.process@custom already exists, select the three dots next to it and choose Edit. Click Add a processor. Select Pipeline for Processor, enter <VERSION>-ml_pad_ingest_pipeline for name (replacing <VERSION> with the current package version), and check Ignore missing pipeline and Ignore failures for this processor. Select Add Processor.
3. Add the required mappings to the component template: Go to Stack Management > Index Management > Component Templates. Templates that can be edited to add custom components will be marked with a @custom suffix. For instance, the custom component template for Elastic Defend process events is logs-endpoint.events.process@custom. Note: Do not attempt to edit the @package template.
   • If the @custom component template does not exist, you can execute the following command in the Dev Console to create it and then continue to the Rollover section in these instructions. Be sure to change <VERSION> to the current package version.

     PUT _component_template/{COMPONENT_TEMPLATE_NAME}@custom
     {
       "template": {
         "settings": {
           "index": {
             "default_pipeline": "<VERSION>-ml_pad_ingest_pipeline"
           }
         },
         "mappings": {
           "properties": {
             "process": {
               "type": "object",
               "properties": {
                 "command_line_entropy": {
                   "type": "double"
                 }
               }
             }
           }
         }
       }
     }
     

   • If the @custom component template already exists, you will need to edit it to add mappings for data to be properly enriched. Click the three dots next to it and select Edit.
   • On the index settings step, add the following. Be sure to change <VERSION> to the current package version.

     {
       "index": {
         "default_pipeline": "<VERSION>-ml_pad_ingest_pipeline"
       }
     }
     

   • Proceed to the mappings step in the UI. Click Add Field at the bottom of the page and create an Object field for process:
   • Create a property under Process for command_line_entropy of type Double.
   • Your component mappings should look like the following:
   • Click Review then Save Component Template.
4. Rollover Depending on your environment, you may need to rollover in order for these mappings to get picked up. The default index pattern for Elastic Defend is logs-endpoint.events.process-default.

   POST INDEX_NAME/_rollover
   

5. Check the health of the transforms: The transforms are scheduled to run every hour. These transforms create two indices: ml_windows_privilege_type_pad.all and ml_okta_multiple_user_sessions_pad.all. To check the health of the transforms go to Management > Stack Management > Data > Transforms under logs-pad.pivot_transform_okta_multiple_sessions-default-<FLEET-TRANSFORM-VERSION> and logs-pad.pivot_transform_windows_privilege_list-default-<FLEET-TRANSFORM-VERSION>.
6. Create data views for anomaly detection jobs: The anomaly detection jobs under this package rely on three indices. One index contains logs for Windows, Linux, and Okta (logs-*), while the second and third indices store Okta user session information and details about special Windows privileges assigned to a user, respectively, collected through two transforms (ml_okta_multiple_user_sessions_pad.all and ml_windows_privilege_type_pad.all). Before enabling the anomaly detection jobs, create a data view with both index patterns.
   1. Go to Stack Management > Kibana > Data Views and click Create data view.
   2. Enter the name of your respective index patterns in the Index pattern box, i.e., logs-*, ml_okta_multiple_user_sessions_pad.all, ml_windows_privilege_type_pad.all, and copy the same in the Name field.
   3. Select @timestamp under the Timestamp field and click on Save data view to Kibana.
   4. Use the new data view (logs-*, ml_okta_multiple_user_sessions_pad.all, ml_windows_privilege_type_pad.all) to create anomaly detection jobs for this package.
7. Add preconfigured anomaly detection jobs: In Machine Learning > Anomaly Detection, when you create a job, you should see an option to Use preconfigured jobs with a card for Privileged Access Detection. When you select the card, you will see pre-configured anomaly detection jobs that you can enable depending on what makes the most sense for your environment. Note: In the Machine Learning app, these configurations are available only when data exists that matches the query specified in the pad-ml file. Additionally, we recommend backdating the datafeed for these anomaly detection jobs to a specific timeframe, as some datafeed queries are resource-intensive and may lead to query delays. We advise you to start the datafeed with 2-3 months' worth of data.
8. Data view configuration for Dashboards: For the dashboard to work as expected, the following settings need to be configured in Kibana.
   1. You have started the above anomaly detection jobs.
   2. You have read access to .ml-anomalies-shared index or are assigned the machine_learning_user role. For more information on roles, please refer to Built-in roles in Elastic. Please be aware that a user who has access to the underlying machine learning results indices can see the results of all jobs in all spaces. Be mindful of granting permissions if you use Kibana spaces to control which users can see which machine learning results. For more information on machine learning privileges, refer to setup-privileges.
   3. After enabling the jobs, go to Management > Stack Management > Kibana > Data Views. Click on Create data view with the following settings:
      • Name: .ml-anomalies-shared
      • Index pattern : .ml-anomalies-shared
      • Select Show Advanced settings enable Allow hidden and system indices
      • Custom data view ID: .ml-anomalies-shared
9. Enabling detection rules: You can also enable detection rules to alert on Privileged Access activity in your environment, based on anomalies flagged by the above ML jobs. These rules are available as part of the Detection Engine, and can be found using the tag Use Case: Privileged Access Detection. See this documentation for more information on importing and enabling the rules.

To inspect the installed assets, you can navigate to Stack Management > Data > Transforms.

When querying the destination indices for Okta and Windows logs, we advise using the alias for the destination index (ml_okta_multiple_user_sessions_pad.all and ml_windows_privilege_type_pad.all). In the event that the underlying package is upgraded, the alias will aid in maintaining the previous findings.

Usage in production requires that you have a license key that permits use of machine learning features.