mirror of
https://github.com/elastic/kibana.git
synced 2025-06-27 10:40:07 -04:00
1b7cb0f29b
# Overview This pull request adds capabilities associated with the [Privileged Access Detection (PAD) anomaly integration package](https://www.elastic.co/docs/reference/integrations/pad) as a first-class-citizen into the Entity Analytics Privileged User Monitoring feature. # How to test - Pull this branch into your local machine - Ensure that the security experimental flag `privilegeMonitoringEnabled` has been enabled, for example by setting `xpack.securitySolution.enableExperimental: [privilegeMonitoringEnabled]` in your `config/kibana.dev.yml` file - Start Elasticsearch and Kibana - From the [security-documents-generator](https://github.com/elastic/security-documents-generator) repository, run the following command: `yarn start privileged-user-monitoring` (ensuring your config is pointing to your locally running Elastic cluster). This will load "source" events that are anomalous in nature. You can run this command more than once if desired to upload more than 10 users. - Grab the CSV file that the generator created in its console output. - Open the Entity analytics page and navigate to dashboards (by clicking "Go to dashboards") - Add the privileged users from the previous step to the privileged users index using the CSV File Upload option. > [!NOTE] > Any errors regarding risk scoring are unrelated to this PR, and are being resolved separately - You should see a panel that says "Enable Privileged access detection". Click "Install", and you'll meet a loading state. - Once complete, you shouldn't see any results. That's because, even though we **install** the ML jobs by default, we don't **run** them by default. - Click "ML Job Settings", and note that only `pad` jobs should be displaying in this callout. Feel free to test this callout's links and filtering options. - Click "Run job" next to the job called `pad_linux_high_count_privileged_process_events_by_user`. This is the job for which we have anomaly data. - Click away from the callout. **You still shouldn't see data.** That's because there just aren't any anomalies "today". - Change the global date filter at the top of the screen to "Last 30 days". - You should see something similar to this: <img width="1441" alt="Screenshot 2025-06-16 at 12 50 25 AM" src="https://github.com/user-attachments/assets/2b3f11f2-f45d-4716-bb8e-79d2b585aa3e" /> - Congrats for making it this far! Some things to play around with: - Click around on the anomaly filters (i.e., click 25-50), and notice that the results will change. - Ensure that the ordering of the users is based on the **highest single anomaly score in any visible bucket**. Meaning, if user `samwise` has only one anomaly, but its score is 99, and user `frodo` has dozens of anomalies, but no higher than, say, 80, `samwise` will be on the top of the list. - Click the user names to open the appropriate user flyout - Change the global time filter to change ranges, and ensure the data shows up appropriately. The buckets will try to roughly show 30 buckets total, but will have a maximum of 3 hours, meaning if your range is too small, it may show fewer than 30 buckets. This is intentional behavior, as the PAD jobs have an anomaly job window of 3 hours. - Click the button that says "View all in Anomaly Explorer", which uses the currently selected global time range, and compare results > [!WARNING] > Remember that the users in the privileged user monitoring table are only those that you designated as privileged users in a previous step. In contrast, the Anomaly Explorer page shows **all** users. Additionally, note that there may be very slight differences between the swimlanes, because ES|QL calculates the bucket dates slightly differently than the Anomaly Explorer. **This should not affect the results themselves, only the buckets that an individual anomaly score might fall in.** You might see a single anomaly fall into one visual bucket instead of another, but the date should be correct. # Helpful hints If you'd like an easy way to "reset" the Privileged Access Detection package and delete its associated jobs (and anomaly data), so that you can redo the onboarding flow, you can run the below commands (changing any credentials as necessary): ```shell curl "http://localhost:5601/api/fleet/epm/packages/pad/0.5.0" \ -X 'DELETE' \ -H 'elastic-api-version: 2023-10-31' \ -H 'kbn-xsrf:true' \ --user elastic:changeme curl "http://localhost:5601/internal/ml/jobs/delete_jobs" \ -H 'kbn-xsrf:true' \ --user elastic:changeme \ -X 'POST' \ -H 'elastic-api-version: 1' \ -H 'x-elastic-internal-origin:kibana' \ -H 'Content-Type: application/json' \ --data-raw '{ "jobIds": [ "pad_linux_high_count_privileged_process_events_by_user", "pad_linux_high_median_process_command_line_entropy_by_user", "pad_linux_rare_process_executed_by_user", "pad_okta_high_sum_concurrent_sessions_by_user", "pad_okta_rare_host_name_by_user", "pad_okta_rare_region_name_by_user", "pad_okta_rare_source_ip_by_user", "pad_okta_spike_in_group_application_assignment_changes", "pad_okta_spike_in_group_lifecycle_changes", "pad_okta_spike_in_group_membership_changes", "pad_okta_spike_in_group_privilege_changes", "pad_okta_spike_in_user_lifecycle_management_changes", "pad_windows_high_count_group_management_events", "pad_windows_high_count_special_logon_events", "pad_windows_high_count_special_privilege_use_events", "pad_windows_high_count_user_account_management_events", "pad_windows_rare_device_by_user", "pad_windows_rare_group_name_by_user", "pad_windows_rare_privilege_assigned_to_user", "pad_windows_rare_region_name_by_user", "pad_windows_rare_source_ip_by_user" ], "deleteUserAnnotations": true, "deleteAlertingRules": false } ' ``` # What's left? - This PR does not implement "proactive" permissions checks. Instead, relevant permission issues will cause requests/queries to fail, which are appropriately shown in the UI for troubleshooting. This proactive check will be tackled in [this (private) followup issue](https://github.com/elastic/security-team/issues/12822). - There is not yet a way to "upgrade" the package directly from the Privileged User Monitoring screen. This would be a nice addition later on, instead of requiring users to navigate to the integration page. This behavior will be tackled in [this (private) followup issue](https://github.com/elastic/security-team/issues/12823). --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> |
||
|---|---|---|
| .. | ||
| examples | ||
| linters | ||
| output | ||
| overlays | ||
| scripts | ||
| bundle.json | ||
| bundle.serverless.json | ||
| kibana.info.serverless.yaml | ||
| kibana.info.yaml | ||
| makefile | ||
| package-lock.json | ||
| package.json | ||
| README.md | ||
Kibana API reference documentation
Documentation about our OpenAPI bundling workflow and configuration. See Kibana's hosted stateful and serverless docs.
Workflow
The final goal of this workflow is to produce an OpenAPI bundle containing all Kibana's public APIs.
Step 0
OAS from Kibana's APIs are continuously extracted and captured in bundle.json and bundle.serverless.json as fully formed OAS documentation. See node scripts/capture_oas_snapshot --help for more info.
These bundles form the basis of our OpenAPI bundles to which we append and layer extra information before publishing.
Step 1
Append pre-existing bundles not extracted from code using kbn-openapi-bundler to produce the final resulting bundles.
To add more files into the final bundle, edit the appropriate oas_docs/scripts/merge*.js files.
Step 2
Apply any final overalys to the document that might include examples or final tweaks (see the "Scripts" section for more details).
Scripts
The oas_docs/scripts folder contains scripts that point to the source domain-specific OpenAPI bundles and specify additional parameters for producing the final output bundle. Currently, there are the following scripts:
-
merge_ess_oas.jsscript produces production an output bundle for ESS -
merge_serverless_oas.jsscript produces production an output bundle for Serverless
Output Kibana OpenAPI bundles
The oas_docs/output folder contains the final resulting Kibana OpenAPI bundles
kibana.yamlproduction ready ESS OpenAPI bundlekibana.serverless.yamlproduction ready Serverless OpenAPI bundle
Bundling commands
Besides the scripts in the oas_docs/scripts folder, there is an oas_docs/makefile to simplify the workflow. Use make help to see available commands.