From 88822a7f47a01e02b87d7fe84626c8d43401f2c2 Mon Sep 17 00:00:00 2001 From: Colleen McGinnis Date: Sat, 26 Oct 2024 14:08:59 -0500 Subject: [PATCH 01/14] migrate mdx to asciidoc --- .../behavioral-detection-use-cases.asciidoc | 4 +- .../machine-learning.asciidoc | 8 +- .../tune-anomaly-results.asciidoc | 22 +- docs/cases/cases-manage-settings.asciidoc | 14 +- docs/cases/cases-manage.asciidoc | 28 +- .../session-view.asciidoc | 4 +- docs/dashboards/entity-dashboard.asciidoc | 44 +- docs/detections/about-rules.asciidoc | 10 +- docs/detections/add-exceptions.asciidoc | 56 +- docs/detections/alerts-add-to-cases.asciidoc | 8 +- docs/detections/alerts-ui-manage.asciidoc | 62 +- .../exceptions-api-overview.asciidoc | 8 +- .../api/lists/lists-api-overview.asciidoc | 8 +- .../api/rules/rules-api-overview.asciidoc | 4 +- .../api/signals-migration-api.asciidoc | 32 +- docs/detections/building-block-rule.asciidoc | 4 +- .../detection-engine-intro.asciidoc | 16 +- docs/detections/detections-req.asciidoc | 6 +- .../detections-ui-exceptions.asciidoc | 10 +- .../prebuilt-rules-management.asciidoc | 12 +- .../prebuilt-rules/tune-rule-signals.asciidoc | 12 +- docs/detections/rules-ui-create.asciidoc | 140 +-- docs/detections/rules-ui-manage.asciidoc | 40 +- docs/detections/rules-ui-monitor.asciidoc | 34 +- .../shared-exception-lists.asciidoc | 44 +- .../detections/value-list-exceptions.asciidoc | 20 +- .../detections/visual-event-analyzer.asciidoc | 4 +- docs/getting-started/ingest-data.asciidoc | 2 +- docs/getting-started/net-map-req.asciidoc | 8 +- docs/getting-started/security-ui.asciidoc | 28 +- docs/getting-started/siem-ui.asciidoc | 18 +- .../threat-intel-integrations.asciidoc | 6 +- .../osquery/invest-guide-run-osquery.asciidoc | 6 +- .../osquery-placeholder-fields.asciidoc | 18 +- docs/osquery/osquery-response-action.asciidoc | 16 +- docs/osquery/view-osquery-results.asciidoc | 10 +- ...t-upgrade-deprecated-sn-connector.asciidoc | 4 +- .../post-upgrade-req-cti-alerts.asciidoc | 4 +- docs/reference/field-ref.asciidoc | 10 +- .../ai-assistant-alert-triage.asciidoc | 37 + .../ai-assistant-esql-queries.asciidoc | 19 + .../AI-for-security/ai-assistant.asciidoc | 198 ++++ .../ai-for-security-landing-pg.asciidoc | 7 + .../AI-for-security/ai-use-cases.asciidoc | 11 + .../AI-for-security/attack-discovery.asciidoc | 100 ++ .../connect-to-azure-openai.asciidoc | 121 +++ .../connect-to-bedrock.asciidoc | 171 ++++ .../connect-to-byo-llm.asciidoc | 223 +++++ .../connect-to-openai.asciidoc | 74 ++ .../connect-to-vertex.asciidoc | 115 +++ .../llm-connector-guides.asciidoc | 15 + .../llm-performance-matrix.asciidoc | 56 ++ ...c-ai-assistant-incident-reporting.asciidoc | 69 ++ .../advanced-behavioral-detections.asciidoc | 14 + ...dvanced-entity-analytics-overview.asciidoc | 14 + .../analyze-risk-score-data.asciidoc | 153 +++ .../asset-criticality.asciidoc | 132 +++ .../behavioral-detection-use-cases.asciidoc | 34 + .../entity-risk-scoring.asciidoc | 120 +++ .../ers-req.asciidoc | 94 ++ .../machine-learning.asciidoc | 89 ++ .../machine-learning.mdx | 2 +- .../ml-requirements.asciidoc | 27 + .../prebuilt-ml-jobs.asciidoc | 8 + .../tuning-anomaly-results.asciidoc | 170 ++++ .../turn-on-risk-engine.asciidoc | 50 + docs/serverless/alerts/alert-schema.asciidoc | 445 +++++++++ .../alerts/alert-suppression.asciidoc | 134 +++ .../alerts/alerts-ui-manage.asciidoc | 306 ++++++ .../alerts/query-alert-indices.asciidoc | 21 + .../reduce-notifications-alerts.asciidoc | 33 + .../alerts/signals-to-cases.asciidoc | 70 ++ .../alerts/view-alert-details.asciidoc | 292 ++++++ .../alerts/visual-event-analyzer.asciidoc | 151 +++ .../alerts/visualize-alerts.asciidoc | 106 +++ .../assets/asset-management.asciidoc | 13 + docs/serverless/billing.asciidoc | 69 ++ .../benchmark-rules.asciidoc | 53 ++ .../cloud-native-security-overview.asciidoc | 52 + .../cloud-workload-protection.asciidoc | 26 + .../cspm-findings-page.asciidoc | 87 ++ .../cspm-get-started-azure.asciidoc | 179 ++++ .../cspm-get-started-gcp.asciidoc | 186 ++++ .../cspm-get-started.asciidoc | 328 +++++++ .../cspm-security-posture-faq.asciidoc | 90 ++ .../cloud-native-security/cspm.asciidoc | 25 + .../d4c-get-started.asciidoc | 93 ++ .../d4c-overview.asciidoc | 88 ++ .../d4c-policy-guide.asciidoc | 163 ++++ .../enable-cloudsec.asciidoc | 23 + .../environment-variable-capture.asciidoc | 42 + .../get-started-with-kspm.asciidoc | 446 +++++++++ .../cloud-native-security/kspm.asciidoc | 86 ++ .../security-posture-faq.asciidoc | 89 ++ .../security-posture-management.asciidoc | 50 + .../session-view.asciidoc | 166 ++++ .../vuln-management-faq.asciidoc | 65 ++ .../vuln-management-findings.asciidoc | 91 ++ .../vuln-management-get-started.asciidoc | 77 ++ .../vuln-management-overview.asciidoc | 41 + .../cloud-posture-dashboard-dash.asciidoc | 53 ++ .../dashboards/dashboards-overview.asciidoc | 22 + .../dashboards/data-quality-dash.asciidoc | 112 +++ .../detection-entity-dashboard.asciidoc | 99 ++ .../detection-response-dashboard.asciidoc | 48 + .../kubernetes-dashboard-dash.asciidoc | 103 ++ .../dashboards/overview-dashboard.asciidoc | 63 ++ .../rule-monitoring-dashboard.asciidoc | 65 ++ .../vuln-management-dashboard-dash.asciidoc | 45 + .../agent-tamper-protection.asciidoc | 53 ++ .../artifact-control.asciidoc | 30 + ...igure-endpoint-integration-policy.asciidoc | 286 ++++++ .../defend-feature-privs.asciidoc | 67 ++ .../deploy-endpoint-macos-cat-mont.asciidoc | 92 ++ .../deploy-endpoint-macos-ven.asciidoc | 100 ++ .../deploy-endpoint-reqs.asciidoc | 29 + .../deploy-with-mdm.asciidoc | 142 +++ .../endpoint-data-volume.asciidoc | 20 + .../endpoint-diagnostic-data.asciidoc | 24 + .../endpoint-protection-intro.asciidoc | 9 + .../install-elastic-defend.asciidoc | 118 +++ .../linux-file-monitoring.asciidoc | 97 ++ .../self-healing-rollback.asciidoc | 29 + .../uninstall-agent.asciidoc | 102 ++ .../allowlist-endpoint-3rd-party-av.asciidoc | 78 ++ docs/serverless/edr-manage/blocklist.asciidoc | 96 ++ .../edr-manage/endpoint-command-ref.asciidoc | 378 ++++++++ .../endpoint-event-capture.asciidoc | 59 ++ .../endpoint-self-protection.asciidoc | 37 + .../edr-manage/endpoints-page.asciidoc | 140 +++ .../edr-manage/event-filters.asciidoc | 121 +++ .../host-isolation-exceptions.asciidoc | 78 ++ .../manage-endpoint-protection.asciidoc | 9 + .../edr-manage/optimize-edr.asciidoc | 40 + .../edr-manage/policies-page-ov.asciidoc | 23 + .../edr-manage/trusted-apps-ov.asciidoc | 103 ++ .../automated-response-actions.asciidoc | 41 + .../host-isolation-ov.asciidoc | 166 ++++ .../response-actions-config.asciidoc | 159 ++++ .../response-actions-history.asciidoc | 41 + .../response-actions.asciidoc | 308 ++++++ .../response-actions.mdx | 37 +- .../third-party-actions.asciidoc | 79 ++ docs/serverless/explore/conf-map-ui.asciidoc | 157 +++ docs/serverless/explore/conf-map-ui.mdx | 10 +- .../explore/data-views-in-sec.asciidoc | 63 ++ .../explore/explore-your-data.asciidoc | 15 + .../explore/hosts-overview.asciidoc | 133 +++ .../explore/network-page-overview.asciidoc | 85 ++ .../explore/runtime-fields.asciidoc | 60 ++ .../explore/siem-field-reference.asciidoc | 267 ++++++ docs/serverless/explore/users-page.asciidoc | 128 +++ docs/serverless/images/icons/addDataApp.svg | 1 + docs/serverless/images/icons/addFilter.svg | 1 + .../images/icons/ai-assistant-bw.svg | 1 + docs/serverless/images/icons/ai-assistant.svg | 1 + docs/serverless/images/icons/apmTrace.svg | 1 + docs/serverless/images/icons/apps.svg | 1 + docs/serverless/images/icons/arrowDown.svg | 1 + docs/serverless/images/icons/arrowLeft.svg | 1 + docs/serverless/images/icons/arrowRight.svg | 1 + docs/serverless/images/icons/beaker.svg | 1 + docs/serverless/images/icons/bell.svg | 1 + .../images/icons/boxesHorizontal.svg | 1 + .../serverless/images/icons/boxesVertical.svg | 1 + docs/serverless/images/icons/calendar.svg | 1 + docs/serverless/images/icons/casesApp.svg | 1 + docs/serverless/images/icons/check.svg | 1 + .../images/icons/controlsVertical.svg | 1 + .../serverless/images/icons/copyClipboard.svg | 1 + docs/serverless/images/icons/cross.svg | 1 + docs/serverless/images/icons/discoverApp.svg | 1 + docs/serverless/images/icons/discuss.svg | 1 + docs/serverless/images/icons/document.svg | 1 + .../serverless/images/icons/documentation.svg | 1 + .../serverless/images/icons/editorComment.svg | 1 + docs/serverless/images/icons/error.svg | 1 + docs/serverless/images/icons/expand.svg | 1 + docs/serverless/images/icons/exportAction.svg | 1 + docs/serverless/images/icons/eye.svg | 1 + docs/serverless/images/icons/filter.svg | 1 + .../images/icons/filterInCircle.svg | 1 + docs/serverless/images/icons/gear.svg | 1 + docs/serverless/images/icons/globe.svg | 1 + .../images/icons/grabHorizontal.svg | 1 + docs/serverless/images/icons/help.svg | 1 + docs/serverless/images/icons/iInCircle.svg | 1 + docs/serverless/images/icons/importAction.svg | 1 + docs/serverless/images/icons/indexClose.svg | 1 + docs/serverless/images/icons/indexOpen.svg | 1 + docs/serverless/images/icons/inspect.svg | 1 + docs/serverless/images/icons/lensApp.svg | 1 + docs/serverless/images/icons/list.svg | 1 + docs/serverless/images/icons/listAdd.svg | 1 + docs/serverless/images/icons/menuLeft.svg | 1 + docs/serverless/images/icons/menuRight.svg | 1 + docs/serverless/images/icons/merge.svg | 1 + docs/serverless/images/icons/minus.svg | 1 + .../serverless/images/icons/minusInCircle.svg | 1 + docs/serverless/images/icons/pagesSelect.svg | 1 + docs/serverless/images/icons/pencil.svg | 1 + docs/serverless/images/icons/plusInCircle.svg | 1 + .../images/icons/plusInCircleFilled.svg | 1 + docs/serverless/images/icons/popout.svg | 1 + .../images/icons/questionInCircle.svg | 1 + docs/serverless/images/icons/refresh.svg | 1 + docs/serverless/images/icons/save.svg | 1 + docs/serverless/images/icons/share.svg | 1 + docs/serverless/images/icons/sortDown.svg | 1 + docs/serverless/images/icons/sortUp.svg | 1 + docs/serverless/images/icons/spaces.svg | 6 + docs/serverless/images/icons/starEmpty.svg | 1 + .../images/icons/tableDensityCompact.svg | 1 + docs/serverless/images/icons/timeline.svg | 1 + docs/serverless/images/icons/trash.svg | 1 + docs/serverless/images/icons/warning.svg | 1 + docs/serverless/index.asciidoc | 189 ++++ docs/serverless/ingest/auto-import.asciidoc | 89 ++ docs/serverless/ingest/ingest-data.asciidoc | 134 +++ .../ingest/threat-intelligence.asciidoc | 74 ++ .../serverless/ingest/threat-intelligence.mdx | 2 +- .../investigate/case-permissions.asciidoc | 58 ++ .../investigate/cases-open-manage.asciidoc | 290 ++++++ .../investigate/cases-overview.asciidoc | 25 + .../investigate/cases-settings.asciidoc | 126 +++ .../indicators-of-compromise.asciidoc | 181 ++++ .../investigate/investigate-events.asciidoc | 16 + .../timeline-object-schema.asciidoc | 441 +++++++++ .../timeline-templates-ui.asciidoc | 160 ++++ .../investigate/timelines-ui.asciidoc | 270 ++++++ .../osquery/alerts-run-osquery.asciidoc | 60 ++ .../osquery/invest-guide-run-osquery.asciidoc | 78 ++ .../osquery-placeholder-fields.asciidoc | 36 + .../osquery/osquery-response-action.asciidoc | 93 ++ docs/serverless/osquery/use-osquery.asciidoc | 16 + .../osquery/view-osquery-results.asciidoc | 48 + .../partials/in-review-notice.asciidoc | 15 + .../partials/in-testing-notice.asciidoc | 15 + .../partials/publish-ready-notice.asciidoc | 15 + .../partials/rough-content-notice.asciidoc | 16 + .../partials/rough-content-notice.mdx | 2 +- .../projects-create/create-project.asciidoc | 30 + docs/serverless/rules/about-rules.asciidoc | 94 ++ docs/serverless/rules/add-exceptions.asciidoc | 292 ++++++ .../rules/alerts-ui-monitor.asciidoc | 235 +++++ .../rules/building-block-rule.asciidoc | 41 + .../rules/detection-engine-overview.asciidoc | 144 +++ .../detections-permissions-section.asciidoc | 110 +++ .../rules/detections-ui-exceptions.asciidoc | 36 + .../interactive-investigation-guides.asciidoc | 138 +++ .../prebuilt-rules-management.asciidoc | 129 +++ .../prebuilt-rules/prebuilt-rules.asciidoc | 18 + docs/serverless/rules/rules-coverage.asciidoc | 60 ++ .../serverless/rules/rules-ui-create.asciidoc | 898 ++++++++++++++++++ .../rules/rules-ui-management.asciidoc | 239 +++++ docs/serverless/rules/rules-ui-management.mdx | 20 +- .../rules/shared-exception-lists.asciidoc | 143 +++ .../rules/tuning-detection-signals.asciidoc | 203 ++++ .../rules/value-lists-exceptions.asciidoc | 105 ++ docs/serverless/sec-requirements.asciidoc | 63 ++ docs/serverless/security-overview.asciidoc | 45 + docs/serverless/security-ui.asciidoc | 290 ++++++ .../settings/advanced-settings.asciidoc | 214 +++++ .../settings/manage-settings.asciidoc | 12 + .../settings/project-settings.asciidoc | 9 + .../technical-preview-limitations.asciidoc | 14 + .../troubleshoot-endpoints.asciidoc | 225 +++++ .../troubleshooting-intro.asciidoc | 10 + .../ts-detection-rules.asciidoc | 113 +++ .../what-is-security-serverless.asciidoc | 77 ++ docs/siem-apis.asciidoc | 10 +- docs/siem/installation.asciidoc | 24 +- docs/siem/overview.asciidoc | 4 +- .../ts-detection-rules.asciidoc | 26 +- docs/troubleshooting/ts-management.asciidoc | 18 +- docs/upgrade/upgrade-7.17-8.x.asciidoc | 60 +- docs/upgrade/upgrade-security.asciidoc | 54 +- docs/whats-new.asciidoc | 50 +- 278 files changed, 18036 insertions(+), 547 deletions(-) create mode 100644 docs/serverless/AI-for-security/ai-assistant-alert-triage.asciidoc create mode 100644 docs/serverless/AI-for-security/ai-assistant-esql-queries.asciidoc create mode 100644 docs/serverless/AI-for-security/ai-assistant.asciidoc create mode 100644 docs/serverless/AI-for-security/ai-for-security-landing-pg.asciidoc create mode 100644 docs/serverless/AI-for-security/ai-use-cases.asciidoc create mode 100644 docs/serverless/AI-for-security/attack-discovery.asciidoc create mode 100644 docs/serverless/AI-for-security/connect-to-azure-openai.asciidoc create mode 100644 docs/serverless/AI-for-security/connect-to-bedrock.asciidoc create mode 100644 docs/serverless/AI-for-security/connect-to-byo-llm.asciidoc create mode 100644 docs/serverless/AI-for-security/connect-to-openai.asciidoc create mode 100644 docs/serverless/AI-for-security/connect-to-vertex.asciidoc create mode 100644 docs/serverless/AI-for-security/llm-connector-guides.asciidoc create mode 100644 docs/serverless/AI-for-security/llm-performance-matrix.asciidoc create mode 100644 docs/serverless/AI-for-security/usecase-attack-disc-ai-assistant-incident-reporting.asciidoc create mode 100644 docs/serverless/advanced-entity-analytics/advanced-behavioral-detections.asciidoc create mode 100644 docs/serverless/advanced-entity-analytics/advanced-entity-analytics-overview.asciidoc create mode 100644 docs/serverless/advanced-entity-analytics/analyze-risk-score-data.asciidoc create mode 100644 docs/serverless/advanced-entity-analytics/asset-criticality.asciidoc create mode 100644 docs/serverless/advanced-entity-analytics/behavioral-detection-use-cases.asciidoc create mode 100644 docs/serverless/advanced-entity-analytics/entity-risk-scoring.asciidoc create mode 100644 docs/serverless/advanced-entity-analytics/ers-req.asciidoc create mode 100644 docs/serverless/advanced-entity-analytics/machine-learning.asciidoc create mode 100644 docs/serverless/advanced-entity-analytics/ml-requirements.asciidoc create mode 100644 docs/serverless/advanced-entity-analytics/prebuilt-ml-jobs.asciidoc create mode 100644 docs/serverless/advanced-entity-analytics/tuning-anomaly-results.asciidoc create mode 100644 docs/serverless/advanced-entity-analytics/turn-on-risk-engine.asciidoc create mode 100644 docs/serverless/alerts/alert-schema.asciidoc create mode 100644 docs/serverless/alerts/alert-suppression.asciidoc create mode 100644 docs/serverless/alerts/alerts-ui-manage.asciidoc create mode 100644 docs/serverless/alerts/query-alert-indices.asciidoc create mode 100644 docs/serverless/alerts/reduce-notifications-alerts.asciidoc create mode 100644 docs/serverless/alerts/signals-to-cases.asciidoc create mode 100644 docs/serverless/alerts/view-alert-details.asciidoc create mode 100644 docs/serverless/alerts/visual-event-analyzer.asciidoc create mode 100644 docs/serverless/alerts/visualize-alerts.asciidoc create mode 100644 docs/serverless/assets/asset-management.asciidoc create mode 100644 docs/serverless/billing.asciidoc create mode 100644 docs/serverless/cloud-native-security/benchmark-rules.asciidoc create mode 100644 docs/serverless/cloud-native-security/cloud-native-security-overview.asciidoc create mode 100644 docs/serverless/cloud-native-security/cloud-workload-protection.asciidoc create mode 100644 docs/serverless/cloud-native-security/cspm-findings-page.asciidoc create mode 100644 docs/serverless/cloud-native-security/cspm-get-started-azure.asciidoc create mode 100644 docs/serverless/cloud-native-security/cspm-get-started-gcp.asciidoc create mode 100644 docs/serverless/cloud-native-security/cspm-get-started.asciidoc create mode 100644 docs/serverless/cloud-native-security/cspm-security-posture-faq.asciidoc create mode 100644 docs/serverless/cloud-native-security/cspm.asciidoc create mode 100644 docs/serverless/cloud-native-security/d4c-get-started.asciidoc create mode 100644 docs/serverless/cloud-native-security/d4c-overview.asciidoc create mode 100644 docs/serverless/cloud-native-security/d4c-policy-guide.asciidoc create mode 100644 docs/serverless/cloud-native-security/enable-cloudsec.asciidoc create mode 100644 docs/serverless/cloud-native-security/environment-variable-capture.asciidoc create mode 100644 docs/serverless/cloud-native-security/get-started-with-kspm.asciidoc create mode 100644 docs/serverless/cloud-native-security/kspm.asciidoc create mode 100644 docs/serverless/cloud-native-security/security-posture-faq.asciidoc create mode 100644 docs/serverless/cloud-native-security/security-posture-management.asciidoc create mode 100644 docs/serverless/cloud-native-security/session-view.asciidoc create mode 100644 docs/serverless/cloud-native-security/vuln-management-faq.asciidoc create mode 100644 docs/serverless/cloud-native-security/vuln-management-findings.asciidoc create mode 100644 docs/serverless/cloud-native-security/vuln-management-get-started.asciidoc create mode 100644 docs/serverless/cloud-native-security/vuln-management-overview.asciidoc create mode 100644 docs/serverless/dashboards/cloud-posture-dashboard-dash.asciidoc create mode 100644 docs/serverless/dashboards/dashboards-overview.asciidoc create mode 100644 docs/serverless/dashboards/data-quality-dash.asciidoc create mode 100644 docs/serverless/dashboards/detection-entity-dashboard.asciidoc create mode 100644 docs/serverless/dashboards/detection-response-dashboard.asciidoc create mode 100644 docs/serverless/dashboards/kubernetes-dashboard-dash.asciidoc create mode 100644 docs/serverless/dashboards/overview-dashboard.asciidoc create mode 100644 docs/serverless/dashboards/rule-monitoring-dashboard.asciidoc create mode 100644 docs/serverless/dashboards/vuln-management-dashboard-dash.asciidoc create mode 100644 docs/serverless/edr-install-config/agent-tamper-protection.asciidoc create mode 100644 docs/serverless/edr-install-config/artifact-control.asciidoc create mode 100644 docs/serverless/edr-install-config/configure-endpoint-integration-policy.asciidoc create mode 100644 docs/serverless/edr-install-config/defend-feature-privs.asciidoc create mode 100644 docs/serverless/edr-install-config/deploy-endpoint-macos-cat-mont.asciidoc create mode 100644 docs/serverless/edr-install-config/deploy-endpoint-macos-ven.asciidoc create mode 100644 docs/serverless/edr-install-config/deploy-endpoint-reqs.asciidoc create mode 100644 docs/serverless/edr-install-config/deploy-with-mdm.asciidoc create mode 100644 docs/serverless/edr-install-config/endpoint-data-volume.asciidoc create mode 100644 docs/serverless/edr-install-config/endpoint-diagnostic-data.asciidoc create mode 100644 docs/serverless/edr-install-config/endpoint-protection-intro.asciidoc create mode 100644 docs/serverless/edr-install-config/install-elastic-defend.asciidoc create mode 100644 docs/serverless/edr-install-config/linux-file-monitoring.asciidoc create mode 100644 docs/serverless/edr-install-config/self-healing-rollback.asciidoc create mode 100644 docs/serverless/edr-install-config/uninstall-agent.asciidoc create mode 100644 docs/serverless/edr-manage/allowlist-endpoint-3rd-party-av.asciidoc create mode 100644 docs/serverless/edr-manage/blocklist.asciidoc create mode 100644 docs/serverless/edr-manage/endpoint-command-ref.asciidoc create mode 100644 docs/serverless/edr-manage/endpoint-event-capture.asciidoc create mode 100644 docs/serverless/edr-manage/endpoint-self-protection.asciidoc create mode 100644 docs/serverless/edr-manage/endpoints-page.asciidoc create mode 100644 docs/serverless/edr-manage/event-filters.asciidoc create mode 100644 docs/serverless/edr-manage/host-isolation-exceptions.asciidoc create mode 100644 docs/serverless/edr-manage/manage-endpoint-protection.asciidoc create mode 100644 docs/serverless/edr-manage/optimize-edr.asciidoc create mode 100644 docs/serverless/edr-manage/policies-page-ov.asciidoc create mode 100644 docs/serverless/edr-manage/trusted-apps-ov.asciidoc create mode 100644 docs/serverless/endpoint-response-actions/automated-response-actions.asciidoc create mode 100644 docs/serverless/endpoint-response-actions/host-isolation-ov.asciidoc create mode 100644 docs/serverless/endpoint-response-actions/response-actions-config.asciidoc create mode 100644 docs/serverless/endpoint-response-actions/response-actions-history.asciidoc create mode 100644 docs/serverless/endpoint-response-actions/response-actions.asciidoc create mode 100644 docs/serverless/endpoint-response-actions/third-party-actions.asciidoc create mode 100644 docs/serverless/explore/conf-map-ui.asciidoc create mode 100644 docs/serverless/explore/data-views-in-sec.asciidoc create mode 100644 docs/serverless/explore/explore-your-data.asciidoc create mode 100644 docs/serverless/explore/hosts-overview.asciidoc create mode 100644 docs/serverless/explore/network-page-overview.asciidoc create mode 100644 docs/serverless/explore/runtime-fields.asciidoc create mode 100644 docs/serverless/explore/siem-field-reference.asciidoc create mode 100644 docs/serverless/explore/users-page.asciidoc create mode 100644 docs/serverless/images/icons/addDataApp.svg create mode 100644 docs/serverless/images/icons/addFilter.svg create mode 100644 docs/serverless/images/icons/ai-assistant-bw.svg create mode 100644 docs/serverless/images/icons/ai-assistant.svg create mode 100644 docs/serverless/images/icons/apmTrace.svg create mode 100644 docs/serverless/images/icons/apps.svg create mode 100644 docs/serverless/images/icons/arrowDown.svg create mode 100644 docs/serverless/images/icons/arrowLeft.svg create mode 100644 docs/serverless/images/icons/arrowRight.svg create mode 100644 docs/serverless/images/icons/beaker.svg create mode 100644 docs/serverless/images/icons/bell.svg create mode 100644 docs/serverless/images/icons/boxesHorizontal.svg create mode 100644 docs/serverless/images/icons/boxesVertical.svg create mode 100644 docs/serverless/images/icons/calendar.svg create mode 100644 docs/serverless/images/icons/casesApp.svg create mode 100644 docs/serverless/images/icons/check.svg create mode 100644 docs/serverless/images/icons/controlsVertical.svg create mode 100644 docs/serverless/images/icons/copyClipboard.svg create mode 100644 docs/serverless/images/icons/cross.svg create mode 100644 docs/serverless/images/icons/discoverApp.svg create mode 100644 docs/serverless/images/icons/discuss.svg create mode 100644 docs/serverless/images/icons/document.svg create mode 100644 docs/serverless/images/icons/documentation.svg create mode 100644 docs/serverless/images/icons/editorComment.svg create mode 100644 docs/serverless/images/icons/error.svg create mode 100644 docs/serverless/images/icons/expand.svg create mode 100644 docs/serverless/images/icons/exportAction.svg create mode 100644 docs/serverless/images/icons/eye.svg create mode 100644 docs/serverless/images/icons/filter.svg create mode 100644 docs/serverless/images/icons/filterInCircle.svg create mode 100644 docs/serverless/images/icons/gear.svg create mode 100644 docs/serverless/images/icons/globe.svg create mode 100644 docs/serverless/images/icons/grabHorizontal.svg create mode 100644 docs/serverless/images/icons/help.svg create mode 100644 docs/serverless/images/icons/iInCircle.svg create mode 100644 docs/serverless/images/icons/importAction.svg create mode 100644 docs/serverless/images/icons/indexClose.svg create mode 100644 docs/serverless/images/icons/indexOpen.svg create mode 100644 docs/serverless/images/icons/inspect.svg create mode 100644 docs/serverless/images/icons/lensApp.svg create mode 100644 docs/serverless/images/icons/list.svg create mode 100644 docs/serverless/images/icons/listAdd.svg create mode 100644 docs/serverless/images/icons/menuLeft.svg create mode 100644 docs/serverless/images/icons/menuRight.svg create mode 100644 docs/serverless/images/icons/merge.svg create mode 100644 docs/serverless/images/icons/minus.svg create mode 100644 docs/serverless/images/icons/minusInCircle.svg create mode 100644 docs/serverless/images/icons/pagesSelect.svg create mode 100644 docs/serverless/images/icons/pencil.svg create mode 100644 docs/serverless/images/icons/plusInCircle.svg create mode 100644 docs/serverless/images/icons/plusInCircleFilled.svg create mode 100644 docs/serverless/images/icons/popout.svg create mode 100644 docs/serverless/images/icons/questionInCircle.svg create mode 100644 docs/serverless/images/icons/refresh.svg create mode 100644 docs/serverless/images/icons/save.svg create mode 100644 docs/serverless/images/icons/share.svg create mode 100644 docs/serverless/images/icons/sortDown.svg create mode 100644 docs/serverless/images/icons/sortUp.svg create mode 100644 docs/serverless/images/icons/spaces.svg create mode 100644 docs/serverless/images/icons/starEmpty.svg create mode 100644 docs/serverless/images/icons/tableDensityCompact.svg create mode 100644 docs/serverless/images/icons/timeline.svg create mode 100644 docs/serverless/images/icons/trash.svg create mode 100644 docs/serverless/images/icons/warning.svg create mode 100644 docs/serverless/index.asciidoc create mode 100644 docs/serverless/ingest/auto-import.asciidoc create mode 100644 docs/serverless/ingest/ingest-data.asciidoc create mode 100644 docs/serverless/ingest/threat-intelligence.asciidoc create mode 100644 docs/serverless/investigate/case-permissions.asciidoc create mode 100644 docs/serverless/investigate/cases-open-manage.asciidoc create mode 100644 docs/serverless/investigate/cases-overview.asciidoc create mode 100644 docs/serverless/investigate/cases-settings.asciidoc create mode 100644 docs/serverless/investigate/indicators-of-compromise.asciidoc create mode 100644 docs/serverless/investigate/investigate-events.asciidoc create mode 100644 docs/serverless/investigate/timeline-object-schema.asciidoc create mode 100644 docs/serverless/investigate/timeline-templates-ui.asciidoc create mode 100644 docs/serverless/investigate/timelines-ui.asciidoc create mode 100644 docs/serverless/osquery/alerts-run-osquery.asciidoc create mode 100644 docs/serverless/osquery/invest-guide-run-osquery.asciidoc create mode 100644 docs/serverless/osquery/osquery-placeholder-fields.asciidoc create mode 100644 docs/serverless/osquery/osquery-response-action.asciidoc create mode 100644 docs/serverless/osquery/use-osquery.asciidoc create mode 100644 docs/serverless/osquery/view-osquery-results.asciidoc create mode 100644 docs/serverless/partials/in-review-notice.asciidoc create mode 100644 docs/serverless/partials/in-testing-notice.asciidoc create mode 100644 docs/serverless/partials/publish-ready-notice.asciidoc create mode 100644 docs/serverless/partials/rough-content-notice.asciidoc create mode 100644 docs/serverless/projects-create/create-project.asciidoc create mode 100644 docs/serverless/rules/about-rules.asciidoc create mode 100644 docs/serverless/rules/add-exceptions.asciidoc create mode 100644 docs/serverless/rules/alerts-ui-monitor.asciidoc create mode 100644 docs/serverless/rules/building-block-rule.asciidoc create mode 100644 docs/serverless/rules/detection-engine-overview.asciidoc create mode 100644 docs/serverless/rules/detections-permissions-section.asciidoc create mode 100644 docs/serverless/rules/detections-ui-exceptions.asciidoc create mode 100644 docs/serverless/rules/interactive-investigation-guides.asciidoc create mode 100644 docs/serverless/rules/prebuilt-rules/prebuilt-rules-management.asciidoc create mode 100644 docs/serverless/rules/prebuilt-rules/prebuilt-rules.asciidoc create mode 100644 docs/serverless/rules/rules-coverage.asciidoc create mode 100644 docs/serverless/rules/rules-ui-create.asciidoc create mode 100644 docs/serverless/rules/rules-ui-management.asciidoc create mode 100644 docs/serverless/rules/shared-exception-lists.asciidoc create mode 100644 docs/serverless/rules/tuning-detection-signals.asciidoc create mode 100644 docs/serverless/rules/value-lists-exceptions.asciidoc create mode 100644 docs/serverless/sec-requirements.asciidoc create mode 100644 docs/serverless/security-overview.asciidoc create mode 100644 docs/serverless/security-ui.asciidoc create mode 100644 docs/serverless/settings/advanced-settings.asciidoc create mode 100644 docs/serverless/settings/manage-settings.asciidoc create mode 100644 docs/serverless/settings/project-settings.asciidoc create mode 100644 docs/serverless/technical-preview-limitations.asciidoc create mode 100644 docs/serverless/troubleshooting/troubleshoot-endpoints.asciidoc create mode 100644 docs/serverless/troubleshooting/troubleshooting-intro.asciidoc create mode 100644 docs/serverless/troubleshooting/ts-detection-rules.asciidoc create mode 100644 docs/serverless/what-is-security-serverless.asciidoc diff --git a/docs/advanced-entity-analytics/behavioral-detection-use-cases.asciidoc b/docs/advanced-entity-analytics/behavioral-detection-use-cases.asciidoc index f76f7134a7..47a84ca9c6 100644 --- a/docs/advanced-entity-analytics/behavioral-detection-use-cases.asciidoc +++ b/docs/advanced-entity-analytics/behavioral-detection-use-cases.asciidoc @@ -1,11 +1,11 @@ [[behavioral-detection-use-cases]] = Behavioral detection use cases -Behavioral detection identifies potential internal and external threats based on user and host activity. It uses a threat-centric approach to flag suspicious activity by analyzing patterns, anomalies, and context enrichment. +Behavioral detection identifies potential internal and external threats based on user and host activity. It uses a threat-centric approach to flag suspicious activity by analyzing patterns, anomalies, and context enrichment. The behavioral detection feature is built on {elastic-sec}'s foundational SIEM detection capabilities, leveraging {ml} algorithms to enable proactive threat detection and hunting. -[float] +[discrete] [[ml-integrations]] === Elastic {integrations} for behavioral detection use cases diff --git a/docs/advanced-entity-analytics/machine-learning.asciidoc b/docs/advanced-entity-analytics/machine-learning.asciidoc index 673997ef3b..5c0cfe0c4d 100644 --- a/docs/advanced-entity-analytics/machine-learning.asciidoc +++ b/docs/advanced-entity-analytics/machine-learning.asciidoc @@ -14,7 +14,7 @@ offer the ability to drag and drop details of the anomaly to Timeline, such as the `Entity` itself, or any of the associated `Influencers`. -[float] +[discrete] [[manage-jobs]] == Manage {ml} jobs If you have the `machine_learning_admin` role, you can use the *ML job settings* interface on the *Alerts*, *Rules*, and *Rule Exceptions* pages to view, start, and stop {elastic-sec} {ml} jobs. @@ -22,7 +22,7 @@ If you have the `machine_learning_admin` role, you can use the *ML job settings* [role="screenshot"] image::images/ml-ui.png[ML job settings UI on the Alerts page] -[float] +[discrete] [[manage-ml-rules]] === Manage {ml} detection rules @@ -39,7 +39,7 @@ image::images/rules-table-ml-job-error.png[Rules table {ml} job error] image::images/rules-ts-ml-job-stopped.png[Rule details page with ML job stopped] -[float] +[discrete] [[included-jobs]] === Prebuilt jobs @@ -71,7 +71,7 @@ prior to the time they are enabled. After jobs are enabled, they continuously analyze incoming data. When jobs are stopped and restarted within the two-week time frame, previously analyzed data is not processed again. -[float] +[discrete] [[view-anomalies]] == View detected anomalies To view the `Anomalies` table widget and `Max Anomaly Score By Job` details, diff --git a/docs/advanced-entity-analytics/tune-anomaly-results.asciidoc b/docs/advanced-entity-analytics/tune-anomaly-results.asciidoc index 1c0d64a399..fcd8db2d3a 100644 --- a/docs/advanced-entity-analytics/tune-anomaly-results.asciidoc +++ b/docs/advanced-entity-analytics/tune-anomaly-results.asciidoc @@ -1,12 +1,12 @@ [[tuning-anomaly-results]] = Optimizing anomaly results -To gain clearer insights into real threats, you can tune the anomaly results. The following procedures help to reduce the number of false positives: +To gain clearer insights into real threats, you can tune the anomaly results. The following procedures help to reduce the number of false positives: * <> * <> -[float] +[discrete] [[rarely-used-processes]] == Filter out anomalies from rarely used applications and processes @@ -20,7 +20,7 @@ For example, to filter out results from a housekeeping process, named . <> . <> (optional) -[float] +[discrete] [[create-fiter-list]] === Create a filter list @@ -40,7 +40,7 @@ image::filter-add-item.png[] + The new filter appears in the Filter List and can be added to relevant jobs. -[float] +[discrete] [[add-job-filter]] === Add the filter to the relevant job @@ -68,7 +68,7 @@ TIP: For more information, see NOTE: Changes to rules only affect new results. All anomalies found by the job before the filter was added are still displayed. -[float] +[discrete] [[clone-job]] === Clone and rerun the job @@ -106,24 +106,24 @@ image::start-job-window.png[] + After a while, results will start to appear on the *Anomaly Explorer* page. -[float] +[discrete] [[define-rule-threshold]] == Define an anomaly threshold for a job -Certain jobs use a high-count function to look for unusual spikes in +Certain jobs use a high-count function to look for unusual spikes in process events. For some processes, a burst of activity is a normal, such as automation and housekeeping jobs running on server fleets. However, sometimes a high-delta event count is unlikely to be the result of routine behavior. In these cases, you can define a minimum threshold for when a high-event count is considered an anomaly. -Depending on your anomaly detection results, you may want to set a +Depending on your anomaly detection results, you may want to set a minimum event count threshold for the `packetbeat_dns_tunneling` job: . Go to *Machine Learning* -> *Anomaly Detection* -> *Anomaly Explorer*. -. Navigate to the job results for the `packetbeat_dns_tunneling` job. If the -job results are not listed, click *Edit job selection* and select +. Navigate to the job results for the `packetbeat_dns_tunneling` job. If the +job results are not listed, click *Edit job selection* and select `packetbeat_dns_tunneling`. . In the *actions* column, click the gear icon and then select _Configure rules_. @@ -132,7 +132,7 @@ The *Create Rule* window is displayed. + [role="screenshot"] image::ml-rule-threshold.png[] -. Select _Add numeric conditions for when the rule applies_ and the following +. Select _Add numeric conditions for when the rule applies_ and the following `when` statement: + _WHEN actual IS GREATER THAN _ diff --git a/docs/cases/cases-manage-settings.asciidoc b/docs/cases/cases-manage-settings.asciidoc index f1ed423dba..bbef74246f 100644 --- a/docs/cases/cases-manage-settings.asciidoc +++ b/docs/cases/cases-manage-settings.asciidoc @@ -1,8 +1,8 @@ [[cases-manage-settings]] == Configure case settings :frontmatter-description: Change the default behavior of cases by adding connectors, custom fields, templates, and closure options. -:frontmatter-tags-products: [security] -:frontmatter-tags-content-type: [how-to] +:frontmatter-tags-products: [security] +:frontmatter-tags-content-type: [how-to] :frontmatter-tags-user-goals: [analyze] To change case closure options and add custom fields, templates, and connectors for external incident management systems, go to *Cases* -> *Settings*. @@ -13,7 +13,7 @@ image::images/cases-settings.png[Shows the case settings page] NOTE: To view and change case settings, you must have the appropriate {kib} feature privileges. Refer to <>. -[float] +[discrete] [[close-sent-cases]] === Case closures @@ -21,7 +21,7 @@ If you close cases in your external incident management system, the cases will r To close cases when they are sent to an external system, select *Automatically close cases when pushing new incident to external system*. -[float] +[discrete] [[cases-ui-integrations]] === External incident management systems @@ -61,7 +61,7 @@ To change the settings of an existing connector: To change the default connector used to send cases to external systems, select the required connector from the incident management system list. -[float] +[discrete] [[mapped-case-fields]] ==== Mapped case fields @@ -76,7 +76,7 @@ When you push updates to external systems, mapped fields are either overwritten Retrieving data from external systems is not supported. -[float] +[discrete] [[cases-ui-custom-fields]] === Custom fields @@ -98,7 +98,7 @@ In existing cases, new custom text fields initially have null values. You can subsequently remove or edit custom fields on the **Settings** page. -[float] +[discrete] [[cases-templates]] === Templates diff --git a/docs/cases/cases-manage.asciidoc b/docs/cases/cases-manage.asciidoc index 4436afeb22..eae4adc79c 100644 --- a/docs/cases/cases-manage.asciidoc +++ b/docs/cases/cases-manage.asciidoc @@ -2,12 +2,12 @@ = Open and manage cases :frontmatter-description: Create a case in {elastic-sec}, configure email notifications, and add files and visualizations. :frontmatter-tags-products: [security] -:frontmatter-tags-content-type: [how-to] +:frontmatter-tags-content-type: [how-to] :frontmatter-tags-user-goals: [analyze] You can create and manage cases using the UI or the <>. -[float] +[discrete] [[cases-ui-open]] == Open a new case @@ -43,7 +43,7 @@ NOTE: If you've selected a connector for the case, the case is automatically pus image::images/cases-ui-open.png[Shows an open case] // NOTE: This is an autogenerated screenshot. Do not edit it directly. -[float] +[discrete] [[cases-ui-notifications]] == Add email notifications @@ -75,7 +75,7 @@ must configure the {kibana-ref}/settings.html#server-publicBaseUrl[server.public When you subsequently add assignees to cases, they receive an email. -[float] +[discrete] [[cases-ui-manage]] == Manage existing cases @@ -99,12 +99,12 @@ TIP: Comments can contain Markdown. For syntax help, click the Markdown icon (im * Examine <> and <> attached to the case * <> * <> -* Modify the case's description, assignees, category, severity, status, and tags. +* Modify the case's description, assignees, category, severity, status, and tags. * <> and send updates to external systems (if you've added a connector to the case) * <> * Refresh the case to retrieve the latest updates -[float] +[discrete] [[cases-summary]] === Review the case summary @@ -122,7 +122,7 @@ Click on an existing case to access its summary. The case summary, located under [role="screenshot"] image::images/cases-summary.png[Shows you a summary of the case] -[float] +[discrete] [[cases-manage-comments]] === Manage case comments To edit, delete, or quote a comment, select the appropriate option from the *More actions* menu (*…​*). @@ -130,7 +130,7 @@ To edit, delete, or quote a comment, select the appropriate option from the *Mor [role="screenshot"] image::images/cases-manage-comments.png[Shows you a summary of the case] -[float] +[discrete] [[cases-examine-alerts]] === Examine alerts attached to a case @@ -141,7 +141,7 @@ image::images/cases-alert-tab.png[Shows you the Alerts tab] NOTE: Each case can have a maximum of 1,000 alerts. -[float] +[discrete] [[cases-add-files]] === Add files @@ -159,7 +159,7 @@ The available hash functions are MD5, SHA-1, and SHA-256. When you add a file, a comment is added to the case activity log. To view an image, click its name in the activity or file list. -[float] +[discrete] [[cases-lens-visualization]] === Add a Lens visualization @@ -194,7 +194,7 @@ After a visualization has been added to a case, you can modify or interact with [role="screenshot"] image::images/cases-open-vis.png[Shows where the Open Visualization option is] -[float] +[discrete] [[cases-copy-case-uuid]] === Copy the case UUID @@ -203,7 +203,7 @@ Each case has a universally unique identifier (UUID) that you can copy and share [role="screenshot"] image::images/cases-copy-case-id.png[Copy Case ID option in More actions menu 40%,40%] -[float] +[discrete] [[cases-export-import]] == Export and import cases @@ -211,7 +211,7 @@ Cases can be <> and <> as saved IMPORTANT: Before importing Lens visualizations, Timelines, or alerts into a space, ensure their data is present. Without it, they won't work after being imported. -[float] +[discrete] [[cases-export]] === Export a case Use the *Export* option to move cases between different Kibana instances. When you export a case, the following data is exported to a newline-delimited JSON (`.ndjson`) file: @@ -243,7 +243,7 @@ TIP: Keep the *Include related objects* option enabled to ensure connectors are [role="screenshot"] image::images/cases-export-button.png[Shows the export saved objects workflow] -[float] +[discrete] [[cases-import]] === Import a case diff --git a/docs/cloud-native-security/session-view.asciidoc b/docs/cloud-native-security/session-view.asciidoc index 9423e8be17..4e1eb412fd 100644 --- a/docs/cloud-native-security/session-view.asciidoc +++ b/docs/cloud-native-security/session-view.asciidoc @@ -24,7 +24,7 @@ Session View has the following features: NOTE: To view Linux session data from your Kubernetes infrastructure, you'll need to set up the <>. -[float] +[discrete] [[enable-session-view]] == Enable Session View data Session View uses process data collected by the {elastic-defend} integration, @@ -42,7 +42,7 @@ fields collected when this setting is enabled, refer to the https://github.com/e -[float] +[discrete] [[open-session-view]] == Open Session View Session View is accessible from the **Hosts**, **Alerts**, and **Timelines** pages, as well as the alert details flyout and the **Kubernetes** dashboard. diff --git a/docs/dashboards/entity-dashboard.asciidoc b/docs/dashboards/entity-dashboard.asciidoc index 7e32a3365e..41b94ea3c5 100644 --- a/docs/dashboards/entity-dashboard.asciidoc +++ b/docs/dashboards/entity-dashboard.asciidoc @@ -18,70 +18,70 @@ The dashboard includes the following sections: * <> * <> * <> -* <> +* <> [role="screenshot"] image::images/entity-dashboard.png[Entity dashboard] [[entity-kpis]] -[float] +[discrete] == Entity KPIs (key performance indicators) -Displays the total number of critical hosts, critical users, and anomalies. Select a link to jump to the Host risk table, User risk table, or Anomalies table. +Displays the total number of critical hosts, critical users, and anomalies. Select a link to jump to the Host risk table, User risk table, or Anomalies table. [[entity-host-risk-scores]] -[float] +[discrete] == Host Risk Scores -Displays host risk score data for your environment, including the total number of hosts, and the five most recently recorded host risk scores, with their associated host names, risk data, and number of detection alerts. Host risk scores are calculated using a weighted sum on a scale of 0 (lowest) to 100 (highest). +Displays host risk score data for your environment, including the total number of hosts, and the five most recently recorded host risk scores, with their associated host names, risk data, and number of detection alerts. Host risk scores are calculated using a weighted sum on a scale of 0 (lowest) to 100 (highest). [role="screenshot"] image::images/host-score-data.png[Host risk scores table] -Interact with the table to filter data, view more details, and take action: +Interact with the table to filter data, view more details, and take action: -* Select the *Host risk level* menu to filter the chart by the selected level. +* Select the *Host risk level* menu to filter the chart by the selected level. * Click a host name link to open the host details flyout. -* Hover over a host name link to display inline actions: *Add to timeline*, which adds the selected value to Timeline, and *Copy to Clipboard*, which copies the host name value for you to paste later. -* Click *View all* in the upper-right to display all host risk information on the Hosts page. +* Hover over a host name link to display inline actions: *Add to timeline*, which adds the selected value to Timeline, and *Copy to Clipboard*, which copies the host name value for you to paste later. +* Click *View all* in the upper-right to display all host risk information on the Hosts page. * Click the number link in the *Alerts* column to view the alerts on the Alerts page. Hover over the number and select *Investigate in timeline* (image:images/timeline-button-osquery.png[Investigate in timeline icon,20,20]) to launch Timeline with a query that includes the associated host name value. -For more information about host risk scores, refer to <>. +For more information about host risk scores, refer to <>. [[entity-user-risk-scores]] -[float] +[discrete] == User Risk Scores -Displays user risk score data for your environment, including the total number of users, and the five most recently recorded user risk scores, with their associated user names, risk data, and number of detection alerts. Like host risk scores, user risk scores are calculated using a weighted sum on a scale of 0 (lowest) to 100 (highest). +Displays user risk score data for your environment, including the total number of users, and the five most recently recorded user risk scores, with their associated user names, risk data, and number of detection alerts. Like host risk scores, user risk scores are calculated using a weighted sum on a scale of 0 (lowest) to 100 (highest). [role="screenshot"] image::images/user-score-data.png[User risk table] Interact with the table to filter data, view more details, and take action: -* Select the *User risk level* menu to filter the chart by the selected level. -* Click a user name link to open the user details flyout. -* Hover over a user name link to display inline actions: *Add to timeline*, which adds the selected value to Timeline, and *Copy to Clipboard*, which copies the user name value for you to paste later. -* Click *View all* in the upper-right to display all user risk information on the Users page. +* Select the *User risk level* menu to filter the chart by the selected level. +* Click a user name link to open the user details flyout. +* Hover over a user name link to display inline actions: *Add to timeline*, which adds the selected value to Timeline, and *Copy to Clipboard*, which copies the user name value for you to paste later. +* Click *View all* in the upper-right to display all user risk information on the Users page. * Click the number link in the *Alerts* column to view the alerts on the Alerts page. Hover over the number and select *Investigate in timeline* (image:images/timeline-button-osquery.png[Investigate in timeline icon,20,20]) to launch Timeline with a query that includes the associated user name value. -For more information about user risk scores, refer to <>. +For more information about user risk scores, refer to <>. [[entity-anomalies]] -[float] +[discrete] == Anomalies Anomaly detection jobs identify suspicious or irregular behavior patterns. The Anomalies table displays the total number of anomalies identified by these prebuilt {ml} jobs (named in the **Anomaly name** column). .Requirements [sidebar] --- +-- To display anomaly results, you must {ml-docs}/ml-ad-run-jobs.html[install and run] one or more <>. You cannot add custom anomaly detection jobs to the Entity Analytics dashboard. --- +-- [role="screenshot"] image::images/anomalies-table.png[Anomalies table] @@ -90,7 +90,7 @@ Interact with the table to view more details: * Click *View all host anomalies* to go to the Anomalies table on the Hosts page. * Click *View all user anomalies* to go to the Anomalies table on the Users page. -* Click *View all* to display and manage all machine learning jobs on the Anomaly Detection Jobs page. +* Click *View all* to display and manage all machine learning jobs on the Anomaly Detection Jobs page. -TIP: To learn more about {ml}, refer to {ml-docs}/machine-learning-intro.html[What is Elastic machine learning?] +TIP: To learn more about {ml}, refer to {ml-docs}/machine-learning-intro.html[What is Elastic machine learning?] diff --git a/docs/detections/about-rules.asciidoc b/docs/detections/about-rules.asciidoc index b241b82013..668f821461 100644 --- a/docs/detections/about-rules.asciidoc +++ b/docs/detections/about-rules.asciidoc @@ -6,7 +6,7 @@ Rules run periodically and search for source events, matches, sequences, or {ml} that meet their criteria. When a rule's criteria are met, a detection alert is created. -[float] +[discrete] [[rule-types]] === Rule types @@ -51,7 +51,7 @@ disabled using the `enableESQL` setting from the [role="screenshot"] image::images/all-rules.png[Shows the Rules page] -[float] +[discrete] [[views-index-patterns]] === Data views and index patterns @@ -59,13 +59,13 @@ When you create a rule, you must either specify the {es} index pattens for which NOTE: To access data views, ensure you have the {kibana-ref}/data-views.html#data-views-read-only-access[required permissions]. -[float] +[discrete] [[about-notifications]] === Notifications For both prebuilt and custom rules, you can send notifications when alerts are created. Notifications can be sent via {jira}, Microsoft Teams, PagerDuty, Slack, and others, and can be configured when you create or edit a rule. -[float] +[discrete] [[alerting-authorization-model]] === Authorization @@ -76,7 +76,7 @@ Rules, including all background detection and the actions they generate, are aut If a rule requires certain privileges to run, such as index privileges, keep in mind that if a user without those privileges updates the rule, the rule will no longer function. ============================================== -[float] +[discrete] [[about-exceptions]] === Exceptions diff --git a/docs/detections/add-exceptions.asciidoc b/docs/detections/add-exceptions.asciidoc index dea8dc0331..28408c9dd0 100644 --- a/docs/detections/add-exceptions.asciidoc +++ b/docs/detections/add-exceptions.asciidoc @@ -1,10 +1,10 @@ [[add-exceptions]] == Add and manage exceptions -:frontmatter-description: Explains how to add and manage rule exceptions from a rule's details page, alerts, or the Exception Lists page. +:frontmatter-description: Explains how to add and manage rule exceptions from a rule's details page, alerts, or the Exception Lists page. :frontmatter-tags-products: [security] :frontmatter-tags-content-type: [how-to] -:frontmatter-tags-user-goals: [configure] +:frontmatter-tags-user-goals: [configure] You can add exceptions to a rule from the rule details page, the Alerts table, the alert details flyout, or the Shared Exception Lists page. When you add an exception, you can also close all alerts that meet the exception’s criteria. @@ -26,11 +26,11 @@ specific event in the sequence, update the rule's EQL statement. For example: and process.name != "process-name.exe"]` ---- -* Be careful when adding exceptions to <> rules. Exceptions are evaluated against source and indicator indices, so if the exception matches events in _either_ index, alerts are not generated. +* Be careful when adding exceptions to <> rules. Exceptions are evaluated against source and indicator indices, so if the exception matches events in _either_ index, alerts are not generated. ============== -[float] +[discrete] [[detection-rule-exceptions]] === Add exceptions to a rule @@ -51,15 +51,15 @@ image::images/rule-exception-tab.png[Detail of rule exceptions tab] * To add an exception from the alert details flyout: .. Go to *Alerts*. -.. Click the *View details* button from the Alerts table. -.. In the alert details flyout, click *Take action -> Add rule exception*. +.. Click the *View details* button from the Alerts table. +.. In the alert details flyout, click *Take action -> Add rule exception*. * To add an exception from the Shared Exception Lists page: .. Go to *Rules* -> *Shared exception lists*. -.. Click *Create shared exception list* -> *Create exception item*. +.. Click *Create shared exception list* -> *Create exception item*. -- -. In the *Add rule exception* flyout, name the exception. +. In the *Add rule exception* flyout, name the exception. . Add conditions that define the exception. When the exception's query evaluates to `true`, rules don't generate alerts even when their criteria are met. + IMPORTANT: Rule exceptions are case-sensitive, which means that any character that's entered as an uppercase or lowercase letter will be treated as such. In the event you _don't_ want a field evaluated as case-sensitive, some ECS fields have a `.caseless` version that you can use. @@ -68,7 +68,7 @@ NOTE: When you create a new exception from an alert, exception conditions are au .. *Field*: Select a field to identify the event being filtered. + -[NOTE] +[NOTE] ======= A warning displays for fields with conflicts. Using these fields might cause unexpected exceptions behavior. Refer to <> for more information. ======= @@ -91,9 +91,9 @@ NOTE: Some characters must be escaped with a backslash, such as `\\` for a liter + IMPORTANT: Using wildcards can impact performance. To create a more efficient exception using wildcards, use multiple conditions and make them as specific as possible. For example, adding conditions using `process.name` or `file.name` can help limit the scope of wildcard matching. -.. *Value*: Enter the value associated with the *Field*. To enter multiple values (when using `is one of` or `is not one of`), enter each value, then press **Return**. +.. *Value*: Enter the value associated with the *Field*. To enter multiple values (when using `is one of` or `is not one of`), enter each value, then press **Return**. + -NOTE: The `is one of` and `is not one of` operators support identical, case-sensitive values. For example, if you want to match the values `Windows` and `windows`, add both values to the **Value** field. +NOTE: The `is one of` and `is not one of` operators support identical, case-sensitive values. For example, if you want to match the values `Windows` and `windows`, add both values to the **Value** field. + In the following example, the exception was created from the Rules page and prevents the rule from generating alerts when the `svchost.exe` process runs on hostname `siem-kibana`. + @@ -106,15 +106,15 @@ image::images/add-exception-ui.png[] . Click *Add nested condition* to create conditions using nested fields. This is only required for <>. For all other fields, nested conditions should not be used. -. Choose to add the exception to a rule or a shared exception list. +. Choose to add the exception to a rule or a shared exception list. ++ +NOTE: If you are creating an exception from the Shared Exception Lists page, you can add the exception to multiple rules. + -NOTE: If you are creating an exception from the Shared Exception Lists page, you can add the exception to multiple rules. -+ TIP: If a shared exception list doesn't exist, you can <> from the Shared Exception Lists page. . (Optional) Enter a comment describing the exception. -. (Optional) Enter a future expiration date and time for the exception. +. (Optional) Enter a future expiration date and time for the exception. . Select one of the following alert actions: @@ -123,9 +123,9 @@ is only available when adding exceptions from the Alerts table. * *Close all alerts that match this exception and were generated by this rule*: Closes all alerts that match the exception's conditions and were generated only by the current rule. + -. Click *Add rule exception*. +. Click *Add rule exception*. -[float] +[discrete] [[endpoint-rule-exceptions]] === Add {elastic-endpoint} exceptions @@ -167,7 +167,7 @@ alert, click the *More actions* menu (*...*), then select *Add Endpoint exceptio * To add an Endpoint exception from Shared Exception Lists page: .. Go to *Rules* -> *Shared exception lists*. -.. Expand the Endpoint Security Exception List or click the list name to open the list's details page. Next, click *Add endpoint exception*. +.. Expand the Endpoint Security Exception List or click the list name to open the list's details page. Next, click *Add endpoint exception*. + NOTE: The Endpoint Security Exception List is automatically created. By default, it's associated with the Endpoint Security rule and any rules with the <> option selected. @@ -179,13 +179,13 @@ The *Add Endpoint Exception* flyout opens. image::images/endpoint-add-exp.png[] . If required, modify the conditions. -+ ++ IMPORTANT: Rule exceptions are case-sensitive, which means that any character that's entered as an uppercase or lowercase letter will be treated as such. In the event you _don't_ want a field evaluated as case-sensitive, some ECS fields have a `.caseless` version that you can use. + -[NOTE] +[NOTE] ====== * Fields with conflicts are marked with a warning icon (image:images/field-warning-icon.png[Field conflict warning icon,13,13]). Using these fields might cause unexpected exceptions behavior. For more information, refer to <>. -* The `is one of` and `is not one of` operators support identical, case-sensitive values. For example, if you want to match the values `Windows` and `windows`, add both values to the **Value** field. +* The `is one of` and `is not one of` operators support identical, case-sensitive values. For example, if you want to match the values `Windows` and `windows`, add both values to the **Value** field. ====== . (Optional) Add a comment to the exception. @@ -196,11 +196,11 @@ is only available when adding exceptions from the Alerts table. * *Close all alerts that match this exception and were generated by this rule*: Closes all alerts that match the exception's conditions. -. Click *Add Endpoint Exception*. An exception is created for both the detection rule and the {elastic-endpoint}. -+ +. Click *Add Endpoint Exception*. An exception is created for both the detection rule and the {elastic-endpoint}. ++ NOTE: It might take longer for exceptions to be applied to hosts within larger deployments. -[float] +[discrete] [[ex-nested-conditions]] === Exceptions with nested conditions @@ -260,19 +260,19 @@ Creates an exception that excludes all LFC-signed trusted processes: [role="screenshot"] image::images/nested-exp.png[] -[float] +[discrete] [[manage-exception]] -=== View and manage exceptions +=== View and manage exceptions To view a rule's exceptions, open the rule's details page (*Rules* -> *Detection rules (SIEM)* -> *_Rule name_*), then scroll down and select the *Rule exceptions* or *Endpoint exceptions* tab. All exceptions that belong to the rule will display in a list. From the list, you can filter, edit, and delete exceptions. You can also toggle between *Active exceptions* and *Expired exceptions*. [role="screenshot"] image::images/manage-default-rule-list.png[A default rule list] -[float] +[discrete] [[rules-using-same-exception]] === Find rules using the same exceptions -To find out if an exception is used by other rules, select the *Rule exceptions* or *Endpoint exceptions* tab, navigate to an exception list item, then click *Affects _X_ rules*. +To find out if an exception is used by other rules, select the *Rule exceptions* or *Endpoint exceptions* tab, navigate to an exception list item, then click *Affects _X_ rules*. NOTE: Changes that you make to the exception also apply to other rules that use the exception. diff --git a/docs/detections/alerts-add-to-cases.asciidoc b/docs/detections/alerts-add-to-cases.asciidoc index 75fcb9932e..f44f54aa98 100644 --- a/docs/detections/alerts-add-to-cases.asciidoc +++ b/docs/detections/alerts-add-to-cases.asciidoc @@ -1,8 +1,8 @@ [[signals-to-cases]] == Add detection alerts to cases :frontmatter-description: Add alerts to new or existing cases in {elastic-sec}. -:frontmatter-tags-products: [security] -:frontmatter-tags-content-type: [how-to] +:frontmatter-tags-products: [security] +:frontmatter-tags-content-type: [how-to] :frontmatter-tags-user-goals: [analyze] From the Alerts table, you can attach one or more alerts to a <> or <>. Alerts from any rule type can be added to a case. @@ -16,7 +16,7 @@ From the Alerts table, you can attach one or more alerts to a <>. [role="screenshot"] image::images/add-alert-to-new-case.png[width=60%][height=60%][Create case flyout with sample data filled in] -[float] +[discrete] [[signals-to-existing-cases]] === Add alerts to an existing case To add alerts to an existing case: diff --git a/docs/detections/alerts-ui-manage.asciidoc b/docs/detections/alerts-ui-manage.asciidoc index fa605a065f..40b664e730 100644 --- a/docs/detections/alerts-ui-manage.asciidoc +++ b/docs/detections/alerts-ui-manage.asciidoc @@ -12,7 +12,7 @@ The Alerts page displays all detection alerts. From the Alerts page, you can fil [role="screenshot"] image::detections/images/alert-page.png[Alerts page overview] -[float] +[discrete] [[detection-view-and-filter-alerts]] === View and filter detection alerts The Alerts page offers various ways for you to organize and triage detection alerts as you investigate suspicious events. You can: @@ -48,7 +48,7 @@ image::images/additional-filters.png[Alerts table with Additional filters menu h * View detection alerts generated by a specific rule. Go to *Rules* -> *Detection rules (SIEM)*, then select a rule name in the table. The rule details page displays a comprehensive view of the rule's settings, and the Alerts table under the Trend histogram displays the alerts associated with the rule, including alerts from any previous or deleted revision of that rule. -[float] +[discrete] [[drop-down-filter-controls]] === Edit drop-down filter controls @@ -61,7 +61,7 @@ image::images/alert-page-dropdown-controls.png[Alerts page with drop-down contro ==== * You can have a maximum of four controls on the Alerts page. * You can't remove the *Status* control. -* If you make any changes to the controls, you _must_ save the pending changes for them to persist. +* If you make any changes to the controls, you _must_ save the pending changes for them to persist. * Saved changes are stored in your browser's local storage, not your {ref}/user-profile.html[user profile]. If you clear your browser's storage or log into your user profile from a different browser, you will lose your customizations. ==== @@ -87,7 +87,7 @@ image::images/alert-page-dropdown-controls.png[Alerts page with drop-down contro . Click *Save pending changes* (image:images/save-icon-blue.png[Save icon,18,18]). -[float] +[discrete] [[group-alerts]] === Group alerts @@ -109,7 +109,7 @@ To interact with grouped alerts: [role="screenshot"] image::images/group-alerts-expand.png[Expanded alert group with alerts table] -[float] +[discrete] [[customize-the-alerts-table]] === Customize the Alerts table Use the toolbar buttons in the upper-left of the Alerts table to customize the columns you want displayed: @@ -133,7 +133,7 @@ image::images/event-rendered-view.png[Alerts table with the Event rendered view TIP: When using grid view, you can view alert-rendered reason statements and event renderings for specific alerts by clicking the expand icon in the *Reason* column. Some events do not have event renderings. -[float] +[discrete] [[alert-actions]] === Take actions on an alert From the Alerts table or the alert details flyout, you can: @@ -151,13 +151,13 @@ From the Alerts table or the alert details flyout, you can: * <> * <> -[float] +[discrete] [[detection-alert-status]] ==== Change an alert's status You can set an alert's status to indicate whether it needs to be investigated (*Open*), is under active investigation (*Acknowledged*), or has been resolved -(*Closed*). By default, the Alerts page displays open alerts. To filter alerts that are *Acknowledged* or *Closed*, use the *Status* drop-down filter at the top of the Alerts page. +(*Closed*). By default, the Alerts page displays open alerts. To filter alerts that are *Acknowledged* or *Closed*, use the *Status* drop-down filter at the top of the Alerts page. To change an alert's status, do one of the following: @@ -172,64 +172,64 @@ image::images/alert-change-status.png[Bulk action menu with multiple alerts sele * In an alert's details flyout, click *Take action* and select a status. -[float] +[discrete] [[apply-alert-tags]] ==== Apply and filter alert tags -Use alert tags to organize related alerts into categories that you can filter and group. For example, use the `False Positive` alert tag to label a group of alerts as false positives. Then, search for them by entering the `kibana.alert.workflow_tags : "False Positive"` query into the KQL bar. Alternatively, use the Alert table's <> to filter for tagged alerts. +Use alert tags to organize related alerts into categories that you can filter and group. For example, use the `False Positive` alert tag to label a group of alerts as false positives. Then, search for them by entering the `kibana.alert.workflow_tags : "False Positive"` query into the KQL bar. Alternatively, use the Alert table's <> to filter for tagged alerts. -NOTE: You can manage alert tag options by updating the `securitySolution:alertTags` advanced setting. Refer to <> for more information. +NOTE: You can manage alert tag options by updating the `securitySolution:alertTags` advanced setting. Refer to <> for more information. -TIP: To display alert tags in the Alerts table, click **Fields** and add the `kibana.alert.workflow_tags` field. +TIP: To display alert tags in the Alerts table, click **Fields** and add the `kibana.alert.workflow_tags` field. To apply or remove alert tags on individual alerts, do one of the following: -** In the Alerts table, click *More actions* (*...*) in an alert's row, then click *Apply alert tags*. Select or unselect tags, then click *Apply tags*. -** In an alert’s details flyout, click *Take action -> Apply alert tags*. Select or unselect tags, then click *Apply tags*. +** In the Alerts table, click *More actions* (*...*) in an alert's row, then click *Apply alert tags*. Select or unselect tags, then click *Apply tags*. +** In an alert’s details flyout, click *Take action -> Apply alert tags*. Select or unselect tags, then click *Apply tags*. -To apply or remove alert tags on multiple alerts, select the alerts you want to change, then click *Selected _x_ alerts* at the upper-left above the table. Click *Apply alert tags*, select or unselect tags, then click *Apply tags*. +To apply or remove alert tags on multiple alerts, select the alerts you want to change, then click *Selected _x_ alerts* at the upper-left above the table. Click *Apply alert tags*, select or unselect tags, then click *Apply tags*. [role="screenshot"] image::images/bulk-apply-alert-tag.png[Bulk action menu with multiple alerts selected, 450] -[float] +[discrete] [[assign-users-to-alerts]] ==== Assign users to alerts -Assign users to alerts that you want them to investigate, and manage alert assignees throughout an alert's lifecycle. +Assign users to alerts that you want them to investigate, and manage alert assignees throughout an alert's lifecycle. -IMPORTANT: Users are not notified when they've been assigned to, or unassigned from, alerts. +IMPORTANT: Users are not notified when they've been assigned to, or unassigned from, alerts. |============================================== -| Action | Instructions +| Action | Instructions -| Assign users to an alert +| Assign users to an alert a| Choose one of the following: -* **Alerts table** - Click **More actions** (**...**) in an alert's row, then click **Assign alert**. Select users, then click **Apply**. -* **Alert details flyout** - Click **Take action -> Assign alert**. Alternatively, click the **Assign alert** icon at the top of the alert details flyout, select users, then click **Apply**. +* **Alerts table** - Click **More actions** (**...**) in an alert's row, then click **Assign alert**. Select users, then click **Apply**. +* **Alert details flyout** - Click **Take action -> Assign alert**. Alternatively, click the **Assign alert** icon at the top of the alert details flyout, select users, then click **Apply**. |Unassign all users from an alert a| Choose one of the following: -* **Alerts table** - Click **More actions** (**...**) in an alert's row, then click **Unassign alert**. -* **Alert details flyout** - Click **Take action -> Unassign alert**. +* **Alerts table** - Click **More actions** (**...**) in an alert's row, then click **Unassign alert**. +* **Alert details flyout** - Click **Take action -> Unassign alert**. | Assign users to multiple alerts -a| From the Alerts table, select the alerts you want to change. Click **Selected _x_ alerts** at the upper-left above the table, then click **Assign alert**. Select users, then click **Apply**. +a| From the Alerts table, select the alerts you want to change. Click **Selected _x_ alerts** at the upper-left above the table, then click **Assign alert**. Select users, then click **Apply**. NOTE: Users assigned to some of the selected alerts will be displayed as unassigned in the selection list. Selecting said users will assign them to all alerts they haven't been assigned to yet. | Unassign users from multiple alerts -| From the Alerts table, select the alerts you want to change and click **Selected _x_ alerts** at the upper-left above the table. Click **Unassign alert** to remove users from the alert. +| From the Alerts table, select the alerts you want to change and click **Selected _x_ alerts** at the upper-left above the table. Click **Unassign alert** to remove users from the alert. |============================================== -Show users that have been assigned to alerts by adding the **Assignees** column to the Alerts table (**Fields** → `kibana.alert.workflow_assignee_ids`). Up to four assigned users can appear in the **Assignees** column. If an alert is assigned to five or more users, a number appears instead. +Show users that have been assigned to alerts by adding the **Assignees** column to the Alerts table (**Fields** → `kibana.alert.workflow_assignee_ids`). Up to four assigned users can appear in the **Assignees** column. If an alert is assigned to five or more users, a number appears instead. [role="screenshot"] image::images/alert-assigned-alerts.png[Alert assignees in the Alerts table, 650] @@ -239,16 +239,16 @@ Assigned users are automatically displayed in the alert details flyout. Up to tw [role="screenshot"] image::images/alert-flyout-assignees.png[Alert assignees in the alert details flyout, 450] -[float] +[discrete] [[filter-assigned-alerts]] ==== Filter assigned alerts -Click the **Assignees** filter above the Alerts table, then select the users you want to filter by. +Click the **Assignees** filter above the Alerts table, then select the users you want to filter by. [role="screenshot"] image::images/alert-filter-assigned-alerts.png[Filtering assigned alerts, 650] -[float] +[discrete] [[add-exception-from-alerts]] ==== Add a rule exception from an alert @@ -262,7 +262,7 @@ To add an exception, click the *More actions* menu (*...*) in the Alerts table, For information about exceptions and how to use them, refer to <>. -[float] +[discrete] [[signals-to-timelines]] ==== View alerts in Timeline diff --git a/docs/detections/api/exceptions/exceptions-api-overview.asciidoc b/docs/detections/api/exceptions/exceptions-api-overview.asciidoc index 5b2bd89706..6189f8c943 100644 --- a/docs/detections/api/exceptions/exceptions-api-overview.asciidoc +++ b/docs/detections/api/exceptions/exceptions-api-overview.asciidoc @@ -43,9 +43,9 @@ entities: image::images/exceptions-logic.png[] -[float] -=== Exceptions requirements +[discrete] +=== Exceptions requirements + +Before you start working with exceptions that use value lists, you must create the `.lists` and `.items` data streams for the relevant {kib} space. To learn how to do this, go to <>. -Before you start working with exceptions that use value lists, you must create the `.lists` and `.items` data streams for the relevant {kib} space. To learn how to do this, go to <>. - Once these data streams are created, your role needs privileges to manage rules. Refer to <> for a complete list of requirements. diff --git a/docs/detections/api/lists/lists-api-overview.asciidoc b/docs/detections/api/lists/lists-api-overview.asciidoc index 39a0cbbb55..a6d6f91538 100644 --- a/docs/detections/api/lists/lists-api-overview.asciidoc +++ b/docs/detections/api/lists/lists-api-overview.asciidoc @@ -60,9 +60,9 @@ Use an <> to define the operator and associate it with an <>. You can then add the exception container to a rule's `exceptions_list` object. -[float] -=== Lists requirements +[discrete] +=== Lists requirements + +Before you can start using lists, you must create the `.lists` and `.items` data streams for the relevant {kib} space. To learn how to do this, go to <>. -Before you can start using lists, you must create the `.lists` and `.items` data streams for the relevant {kib} space. To learn how to do this, go to <>. - Once these data streams are created, your role needs privileges to manage rules. Refer to <> for a complete list of requirements. \ No newline at end of file diff --git a/docs/detections/api/rules/rules-api-overview.asciidoc b/docs/detections/api/rules/rules-api-overview.asciidoc index 85be0089f8..1000118cab 100644 --- a/docs/detections/api/rules/rules-api-overview.asciidoc +++ b/docs/detections/api/rules/rules-api-overview.asciidoc @@ -37,7 +37,7 @@ the status of Elastic <> TIP: You can view and download a Detections API Postman collection https://github.com/elastic/examples/tree/master/Security%20Analytics/SIEM-examples/Detections-API[here]. -[float] +[discrete] === Authentication This API supports both key- and token-based authentication. @@ -54,7 +54,7 @@ If the API key has different privileges than the key that created or most recent If the key that created the rule gets deleted, or the user that created the rule becomes inactive, the rule will stop running. ==== -[float] +[discrete] === Kibana role requirements To create and run rules, the user role for the {kib} space must have: diff --git a/docs/detections/api/signals-migration-api.asciidoc b/docs/detections/api/signals-migration-api.asciidoc index 52111fa4e1..0e694101e0 100644 --- a/docs/detections/api/signals-migration-api.asciidoc +++ b/docs/detections/api/signals-migration-api.asciidoc @@ -18,16 +18,16 @@ Migrating detection alerts is performed at the index level and requires the foll 4. <> (optional) [[migration-1]] -[float] +[discrete] === Determine which indices to migrate You can use the Migration Status API to determine which indices contain detection alerts of a particular age, along with migration info for each of those indices. -[float] +[discrete] ==== Request `GET :/api/detection_engine/signals/migration_status?from=now-30d` -[float] +[discrete] ==== Request query parameters [width="100%",options="header"] @@ -37,7 +37,7 @@ You can use the Migration Status API to determine which indices contain detectio |`from` |datemath|Maximum age of qualifying detection alerts |============================================== -[float] +[discrete] ==== Response example [source,json] @@ -111,17 +111,17 @@ GET .siem-signals-{KIBANA SPACE ID}/_search [[migration-2]] -[float] +[discrete] === Initiate migrations Migrations are initiated per index. While the process is neither destructive nor interferes with existing data, it may be resource-intensive. As such, it is recommended that you plan your migrations accordingly. -[float] +[discrete] ==== Request `POST :/api/detection_engine/signals/migration` -[float] +[discrete] ==== Request body [width="100%",options="header"] @@ -134,7 +134,7 @@ Migrations are initiated per index. While the process is neither destructive nor |`slices`|Integer|The number of subtasks for the migration task. Corresponds to `slices` on the {ref}/docs-reindex.html[Reindex API]|No |============================================== -[float] +[discrete] ==== Response example [source,json] @@ -152,7 +152,7 @@ Migrations are initiated per index. While the process is neither destructive nor The response will include, for each index specified, an ID and destination index for the migration, and an error if unsuccessful. [[migration-3]] -[float] +[discrete] === Finalize migrations The finalization endpoint replaces the original index's alias with the successfully migrated index's alias. The endpoint is idempotent; therefore, it can safely be used to poll a given migration and, upon completion, finalize it. @@ -161,12 +161,12 @@ NOTE: The original indices are not removed as part of this step. After verifying NOTE: If an unsuccessful migration is finalized, a deletion policy will be applied to its index, causing it to be deleted after 30 days. -[float] +[discrete] ==== Request `POST :/api/detection_engine/signals/finalize_migration` -[float] +[discrete] ==== Request body [width="100%",options="header"] @@ -176,7 +176,7 @@ NOTE: If an unsuccessful migration is finalized, a deletion policy will be appli |`migration_ids` |String[]|Array of `migration_id`s to finalize|Yes |============================================== -[float] +[discrete] ==== Response example [source,json] @@ -197,7 +197,7 @@ NOTE: If an unsuccessful migration is finalized, a deletion policy will be appli -------------------------------------------------- Finalized migrations will show a response of `completed: true`, with a corresponding `status`. If the migration is still running when you attempt to finalize it, its response will show as `completed: false`. -[float] +[discrete] [[migration-4]] === Migration cleanup @@ -205,12 +205,12 @@ Migrations favor data integrity over shard size. Consequently, unused or orphane While you can delete these indices manually, the endpoint accomplishes this task by applying a deletion policy to the relevant index, causing it to be deleted after 30 days. It also deletes other artifacts specific to the migration implementation. -[float] +[discrete] ==== Request `DELETE :/api/detection_engine/signals/migration` -[float] +[discrete] ==== Request body [width="100%",options="header"] @@ -220,7 +220,7 @@ While you can delete these indices manually, the endpoint accomplishes this task |`migration_ids` |String[]|Array of `migration_id`s to finalize|Yes |============================================== -[float] +[discrete] ==== Response example [source,json] diff --git a/docs/detections/building-block-rule.asciidoc b/docs/detections/building-block-rule.asciidoc index 829d09088f..dafa2f0835 100644 --- a/docs/detections/building-block-rule.asciidoc +++ b/docs/detections/building-block-rule.asciidoc @@ -10,7 +10,7 @@ in the UI. This is useful when you want: You can then use building block rules to create hidden alerts that act as a basis for an 'ordinary' rule to generate visible alerts. -[float] +[discrete] === Set up rules that run on alert indices To create a rule that searches alert indices, select *Index Patterns* as the rule's *Source* and enter the index pattern for alert indices (`.alerts-security.alerts-*`): @@ -18,7 +18,7 @@ To create a rule that searches alert indices, select *Index Patterns* as the rul [role="screenshot"] image::images/alert-indices-ui.png[] -[float] +[discrete] === View building block alerts in the UI diff --git a/docs/detections/detection-engine-intro.asciidoc b/docs/detections/detection-engine-intro.asciidoc index fb2cae91a0..05d6e9060a 100644 --- a/docs/detections/detection-engine-intro.asciidoc +++ b/docs/detections/detection-engine-intro.asciidoc @@ -7,7 +7,7 @@ Use the detection engine to create and manage rules and view the alerts these rules create. Rules periodically search indices (such as `logs-*` and `filebeat-*`) for suspicious source events and create alerts when a rule's conditions are met. When an alert is created, its status is `Open`. To help -track investigations, an alert's <> can be set as +track investigations, an alert's <> can be set as `Open`, `Acknowledged`, or `Closed`. [role="screenshot"] @@ -61,24 +61,24 @@ To make sure you can access Detections and manage rules, see <>. ============== -[float] +[discrete] [[cold-tier-detections]] == Compatibility with cold and frozen tier nodes Cold and frozen {ref}/data-tiers.html[data tiers] hold time series data that is only accessed occasionally. In {stack} version >=7.11.0, {elastic-sec} supports cold but not frozen tier data for the following {es} indices: * Index patterns specified in `securitySolution:defaultIndex` -* Index patterns specified in the definitions of detection rules, except for indicator match rules +* Index patterns specified in the definitions of detection rules, except for indicator match rules * Index patterns specified in the data sources selector on various {security-app} pages {elastic-sec} does *NOT* support either cold or frozen tier data for the following {es} indices: * Index patterns controlled by {elastic-sec}, including alerts and list indices -* Index patterns specified in the definition of indicator match rules +* Index patterns specified in the definition of indicator match rules Using either cold or frozen tier data for unsupported indices may result in detection rule timeouts and overall performance degradation. -[float] +[discrete] [[support-indicator-rules]] == Limited support for indicator match rules @@ -89,7 +89,7 @@ In addition, the following support restrictions are in place: * {elastic-sec} does not support the use of either cold or frozen {ref}/data-tiers.html[tier data] with indicator match rules. * Indicator match rules with an additional look-back time value greater than 24 hours are not supported. -[float] +[discrete] [[detections-permissions]] == Detections configuration and index privilege prerequisites @@ -140,11 +140,11 @@ For information on how to enable ransomware protection on your host, see <>. @@ -107,7 +107,7 @@ a|`All` for the `Security` feature * To provide full access to rule actions and connectors, give your role `All` privileges. With `Read` privileges, you can edit rule actions, but will have limited capabilities to manage connectors. For example, `Read` privileges allow you to add or remove an existing connector from a rule, but does not allow you to create a new connector. -* To import rules with actions, you need at least `Read` privileges for the `Action and Connectors` feature. To overwrite or add new connectors, you need `All` privileges for the `Actions and Connectors` feature. To import rules without actions, you don't need `Actions and Connectors` privileges. +* To import rules with actions, you need at least `Read` privileges for the `Action and Connectors` feature. To overwrite or add new connectors, you need `All` privileges for the `Actions and Connectors` feature. To import rules without actions, you don't need `Actions and Connectors` privileges. |Manage alerts @@ -143,7 +143,7 @@ Here is an example of a user who has the Detections feature enabled in all {kib} [role="screenshot"] image::images/sec-admin-user.png[Shows user with the Detections feature enabled in all Kibana spaces] -[float] +[discrete] [[alerting-auth-model]] === Authorization diff --git a/docs/detections/detections-ui-exceptions.asciidoc b/docs/detections/detections-ui-exceptions.asciidoc index c0fafe9edc..44977bf6e1 100644 --- a/docs/detections/detections-ui-exceptions.asciidoc +++ b/docs/detections/detections-ui-exceptions.asciidoc @@ -1,15 +1,15 @@ [[detections-ui-exceptions]] == Rule exceptions -You can associate rule exceptions with detection and endpoint rules to prevent trusted processes and network activity from generating unnecessary alerts, therefore, reducing the number of false positives. +You can associate rule exceptions with detection and endpoint rules to prevent trusted processes and network activity from generating unnecessary alerts, therefore, reducing the number of false positives. When creating exceptions, you can assign them to <> or to <>. -[float] +[discrete] [[rule-exceptions-intro]] === Exceptions for individual rules -Exceptions, also referred to as _exception items_, contain the source event conditions that determine when alerts shouldn't be generated. +Exceptions, also referred to as _exception items_, contain the source event conditions that determine when alerts shouldn't be generated. You can create exceptions that apply exclusively to a single rule. These types of exceptions can't be used by other rules, and you must manage them from the rule’s details page. To learn more about creating and managing single-rule exceptions, refer to <>. @@ -18,9 +18,9 @@ image::images/exception-item-example.png[An exception item,90%] NOTE: You can also use <> to define exceptions for detection rules. Value lists allow you to match an exception against a list of possible values. -[float] +[discrete] [[shared-exception-list-intro]] -=== Exceptions shared among multiple rules +=== Exceptions shared among multiple rules If you want an exception to apply to multiple rules, you can add an exception to a shared exception list. Shared exception lists allow you to group exceptions together and then associate them with multiple rules. Refer to <> to learn more. diff --git a/docs/detections/prebuilt-rules-management.asciidoc b/docs/detections/prebuilt-rules-management.asciidoc index 7adb34db43..f846af18a2 100644 --- a/docs/detections/prebuilt-rules-management.asciidoc +++ b/docs/detections/prebuilt-rules-management.asciidoc @@ -6,7 +6,7 @@ :frontmatter-tags-content-type: [how-to] :frontmatter-tags-user-goals: [manage] -Follow these guidelines to start using the {security-app}'s <>, keep them updated, and make sure they have the data needed to run successfully. +Follow these guidelines to start using the {security-app}'s <>, keep them updated, and make sure they have the data needed to run successfully. * <> * <> @@ -23,11 +23,11 @@ Follow these guidelines to start using the {security-app}'s < *Detection rules (SIEM)*. The badge next to *Add Elastic rules* shows the number of prebuilt rules available for installation. +. Go to *Rules* -> *Detection rules (SIEM)*. The badge next to *Add Elastic rules* shows the number of prebuilt rules available for installation. + [role="screenshot"] image::images/prebuilt-rules-add-badge.png[The Add Elastic Rules page] @@ -53,7 +53,7 @@ image::images/prebuilt-rules-add.png[The Add Elastic Rules page] Once you enable a rule, it starts running on its configured schedule. To confirm that it's running successfully, check its *Last response* status in the rules table, or open the rule's details page and check the <> tab. -[float] +[discrete] [[prebuilt-rule-tags]] === Prebuilt rule tags @@ -77,7 +77,7 @@ Each prebuilt rule includes several tags identifying the rule's purpose, detecti ** `Threat Detection`: Detects threats. ** `Vulnerability`: Detects exploitation of specific vulnerabilities. -[float] +[discrete] [[select-all-prebuilt-rules]] === Select and duplicate all prebuilt rules @@ -88,7 +88,7 @@ Each prebuilt rule includes several tags identifying the rule's purpose, detecti You can then modify the duplicated rules and, if required, delete the prebuilt ones. However, your customized rules are entirely separate from the original prebuilt rules, and will not get updates from Elastic if the prebuilt rules are updated. -[float] +[discrete] [[update-prebuilt-rules]] === Update Elastic prebuilt rules diff --git a/docs/detections/prebuilt-rules/tune-rule-signals.asciidoc b/docs/detections/prebuilt-rules/tune-rule-signals.asciidoc index 2c4bcbe402..c30d2518cd 100644 --- a/docs/detections/prebuilt-rules/tune-rule-signals.asciidoc +++ b/docs/detections/prebuilt-rules/tune-rule-signals.asciidoc @@ -23,7 +23,7 @@ For details about tuning rules for specific categories: * <> * <> -[float] +[discrete] [[filter-rule-process]] === Filter out uncommon application alerts @@ -51,7 +51,7 @@ image::images/rule-details-page.png[Rule details page] image::images/process-exception.png[Add Rule Exception UI] . Click *Add rule exception*. -[float] +[discrete] [[tune-authorized-processes]] === Tune rules detecting authorized processes @@ -96,7 +96,7 @@ in original prebuilt rules. image::images/process-specific-exception.png[Example of `is not` exception in the Add Rule Exception UI] . Click *Add rule exception*. -[float] +[discrete] [[tune-windows-rules]] === Tune Windows child process and PowerShell rules @@ -125,7 +125,7 @@ In these cases, exceptions can be added to the rules using the relevant `process.name`, `user.name`, and `host.name` conditions. Additionally, you can create duplicate rules with lower risk scores. -[float] +[discrete] [[tune-network-rules]] === Tune network rules @@ -148,7 +148,7 @@ exception with the port number exception with the port number (`destination.ip is 172.16.0.0/12` and `destination.port is 445`). -[float] +[discrete] [[tune-indicator-rules]] === Tune indicator match rules @@ -160,7 +160,7 @@ Take the following steps to tune indicator match rules: NOTE: {elastic-sec} provides limited support for indicator match rules. Visit <> for more information. -[float] +[discrete] ==== Noise from common cloud-based network traffic In cloud-based organizations, remote workers sometimes access services over the diff --git a/docs/detections/rules-ui-create.asciidoc b/docs/detections/rules-ui-create.asciidoc index 52542e411d..e4b47f7921 100644 --- a/docs/detections/rules-ui-create.asciidoc +++ b/docs/detections/rules-ui-create.asciidoc @@ -9,7 +9,7 @@ To create a new detection rule, follow these steps: -. Define the <>. The configuration for this step varies depending on the rule type. +. Define the <>. The configuration for this step varies depending on the rule type. . Configure basic rule settings. . Configure advanced rule settings (optional). . Set the rule's schedule. @@ -27,7 +27,7 @@ To create a new detection rule, follow these steps: [TIP] ============== * At any step, you can <> before saving it to see what kind of results you can expect. -* To ensure rules don't search cold and frozen data when executing, either configure the `excludedDataTiersForRuleExecution` <> (which applies to all rules in a space), or add a <> to individual rules. +* To ensure rules don't search cold and frozen data when executing, either configure the `excludedDataTiersForRuleExecution` <> (which applies to all rules in a space), or add a <> to individual rules. ============== NOTE: Additional configuration is required for detection rules using cross-cluster search. Refer to <>. @@ -45,7 +45,7 @@ role, and the selected {ml} job must be running for the rule to function correct . Go to *Rules* -> *Detection rules (SIEM)* -> *Create new rule*. The *Create new rule* page displays. . To create a rule based on a {ml} anomaly threshold, select *Machine Learning*, then select: -.. The required {ml} jobs. +.. The required {ml} jobs. + NOTE: If a required job isn't currently running, it will automatically start when you finish configuring and enable the rule. .. The anomaly score threshold above which alerts are created. @@ -56,10 +56,10 @@ NOTE: Because {ml} rules generate alerts from anomalies, which don't contain sou + //// -The following step is repeated across all rule types. If you change anything +The following step is repeated across all rule types. If you change anything in the step or its sub-steps, apply the change to the other rule types, too. //// -. (Optional) Add *Related integrations* to associate the rule with one or more {integrations-docs}[Elastic integrations]. This indicates the rule's dependency on specific integrations and the data they generate, and allows users to confirm each integration's <> when viewing the rule. +. (Optional) Add *Related integrations* to associate the rule with one or more {integrations-docs}[Elastic integrations]. This indicates the rule's dependency on specific integrations and the data they generate, and allows users to confirm each integration's <> when viewing the rule. .. Click *Add integration*, then select an integration from the list. You can also start typing an integration's name to find it faster. .. Enter the version of the integration you want to associate with the rule, using https://semver.org[semantic versioning]. For version ranges, you must use tilde or caret syntax. For example, `~1.2.3` is from 1.2.3 to any patch version less than 1.3.0, and `^1.2.3` is from 1.2.3 to any minor and patch version less than 2.0.0. @@ -103,14 +103,14 @@ When you use a saved query, the *Load saved query "_query name_" dynamically on + //// -The following steps are repeated across multiple rule types. If you change anything +The following steps are repeated across multiple rule types. If you change anything in these steps or sub-steps, apply the change to the other rule types, too. //// . (Optional) Create a list of **Required fields** that the rule needs to function. This list is informational only, to help users understand the rule; it doesn't affect how the rule actually runs. .. Click **Add required field**, then select a field from the index patterns or data view you specified for the rule. You can also start typing a field's name to find it faster, or type in an entirely new custom field. .. Enter the field's data type. -. (Optional) Add *Related integrations* to associate the rule with one or more {integrations-docs}[Elastic integrations]. This indicates the rule's dependency on specific integrations and the data they generate, and allows users to confirm each integration's <> when viewing the rule. +. (Optional) Add *Related integrations* to associate the rule with one or more {integrations-docs}[Elastic integrations]. This indicates the rule's dependency on specific integrations and the data they generate, and allows users to confirm each integration's <> when viewing the rule. .. Click *Add integration*, then select an integration from the list. You can also start typing an integration's name to find it faster. .. Enter the version of the integration you want to associate with the rule, using https://semver.org[semantic versioning]. For version ranges, you must use tilde or caret syntax. For example, `~1.2.3` is from 1.2.3 to any patch version less than 1.3.0, and `^1.2.3` is from 1.2.3 to any minor and patch version less than 2.0.0. @@ -143,14 +143,14 @@ IMPORTANT: Alerts created by threshold rules are synthetic alerts that do not re + //// -The following steps are repeated across multiple rule types. If you change anything +The following steps are repeated across multiple rule types. If you change anything in these steps or sub-steps, apply the change to the other rule types, too. //// . (Optional) Create a list of **Required fields** that the rule needs to function. This list is informational only, to help users understand the rule; it doesn't affect how the rule actually runs. .. Click **Add required field**, then select a field from the index patterns or data view you specified for the rule. You can also start typing a field's name to find it faster, or type in an entirely new custom field. .. Enter the field's data type. -. (Optional) Add *Related integrations* to associate the rule with one or more {integrations-docs}[Elastic integrations]. This indicates the rule's dependency on specific integrations and the data they generate, and allows users to confirm each integration's <> when viewing the rule. +. (Optional) Add *Related integrations* to associate the rule with one or more {integrations-docs}[Elastic integrations]. This indicates the rule's dependency on specific integrations and the data they generate, and allows users to confirm each integration's <> when viewing the rule. .. Click *Add integration*, then select an integration from the list. You can also start typing an integration's name to find it faster. .. Enter the version of the integration you want to associate with the rule, using https://semver.org[semantic versioning]. For version ranges, you must use tilde or caret syntax. For example, `~1.2.3` is from 1.2.3 to any patch version less than 1.3.0, and `^1.2.3` is from 1.2.3 to any minor and patch version less than 2.0.0. @@ -164,7 +164,7 @@ in these steps or sub-steps, apply the change to the other rule types, too. .. Define which {es} indices or data view the rule searches when querying for events. .. Write an {ref}/eql-syntax.html[EQL query] that searches for matching events or a series of matching events. + -TIP: To find events that are missing in a sequence, use the {ref}/eql-syntax.html#eql-missing-events[missing events] syntax. +TIP: To find events that are missing in a sequence, use the {ref}/eql-syntax.html#eql-missing-events[missing events] syntax. + For example, the following rule detects when `msxsl.exe` makes an outbound network connection: @@ -206,14 +206,14 @@ NOTE: For sequence events, the {security-app} generates a single alert when all + //// -The following steps are repeated across multiple rule types. If you change anything +The following steps are repeated across multiple rule types. If you change anything in these steps or sub-steps, apply the change to the other rule types, too. //// . (Optional) Create a list of **Required fields** that the rule needs to function. This list is informational only, to help users understand the rule; it doesn't affect how the rule actually runs. .. Click **Add required field**, then select a field from the index patterns or data view you specified for the rule. You can also start typing a field's name to find it faster, or type in an entirely new custom field. .. Enter the field's data type. -. (Optional) Add *Related integrations* to associate the rule with one or more {integrations-docs}[Elastic integrations]. This indicates the rule's dependency on specific integrations and the data they generate, and allows users to confirm each integration's <> when viewing the rule. +. (Optional) Add *Related integrations* to associate the rule with one or more {integrations-docs}[Elastic integrations]. This indicates the rule's dependency on specific integrations and the data they generate, and allows users to confirm each integration's <> when viewing the rule. .. Click *Add integration*, then select an integration from the list. You can also start typing an integration's name to find it faster. .. Enter the version of the integration you want to associate with the rule, using https://semver.org[semantic versioning]. For version ranges, you must use tilde or caret syntax. For example, `~1.2.3` is from 1.2.3 to any patch version less than 1.3.0, and `^1.2.3` is from 1.2.3 to any minor and patch version less than 2.0.0. @@ -273,20 +273,20 @@ field values. + //// -The following steps are repeated across multiple rule types. If you change anything +The following steps are repeated across multiple rule types. If you change anything in these steps or sub-steps, apply the change to the other rule types, too. //// . (Optional) Create a list of **Required fields** that the rule needs to function. This list is informational only, to help users understand the rule; it doesn't affect how the rule actually runs. .. Click **Add required field**, then select a field from the index patterns or data view you specified for the rule. You can also start typing a field's name to find it faster, or type in an entirely new custom field. .. Enter the field's data type. -. (Optional) Add *Related integrations* to associate the rule with one or more {integrations-docs}[Elastic integrations]. This indicates the rule's dependency on specific integrations and the data they generate, and allows users to confirm each integration's <> when viewing the rule. +. (Optional) Add *Related integrations* to associate the rule with one or more {integrations-docs}[Elastic integrations]. This indicates the rule's dependency on specific integrations and the data they generate, and allows users to confirm each integration's <> when viewing the rule. .. Click *Add integration*, then select an integration from the list. You can also start typing an integration's name to find it faster. .. Enter the version of the integration you want to associate with the rule, using https://semver.org[semantic versioning]. For version ranges, you must use tilde or caret syntax. For example, `~1.2.3` is from 1.2.3 to any patch version less than 1.3.0, and `^1.2.3` is from 1.2.3 to any minor and patch version less than 2.0.0. . Click *Continue* to <>. -[float] +[discrete] [[indicator-value-lists]] ==== Use value lists with indicator match rules @@ -332,14 +332,14 @@ For example, if a rule has an interval of 5 minutes, no additional look-back tim + //// -The following steps are repeated across multiple rule types. If you change anything +The following steps are repeated across multiple rule types. If you change anything in these steps or sub-steps, apply the change to the other rule types, too. //// . (Optional) Create a list of **Required fields** that the rule needs to function. This list is informational only, to help users understand the rule; it doesn't affect how the rule actually runs. .. Click **Add required field**, then select a field from the index patterns or data view you specified for the rule. You can also start typing a field's name to find it faster, or type in an entirely new custom field. .. Enter the field's data type. -. (Optional) Add *Related integrations* to associate the rule with one or more {integrations-docs}[Elastic integrations]. This indicates the rule's dependency on specific integrations and the data they generate, and allows users to confirm each integration's <> when viewing the rule. +. (Optional) Add *Related integrations* to associate the rule with one or more {integrations-docs}[Elastic integrations]. This indicates the rule's dependency on specific integrations and the data they generate, and allows users to confirm each integration's <> when viewing the rule. .. Click *Add integration*, then select an integration from the list. You can also start typing an integration's name to find it faster. .. Enter the version of the integration you want to associate with the rule, using https://semver.org[semantic versioning]. For version ranges, you must use tilde or caret syntax. For example, `~1.2.3` is from 1.2.3 to any patch version less than 1.3.0, and `^1.2.3` is from 1.2.3 to any minor and patch version less than 2.0.0. @@ -354,7 +354,7 @@ Use {ref}/esql.html[{esql}] to query your source events and aggregate event data To create an {esql} rule: . Go to *Rules* -> *Detection rules (SIEM)* -> *Create new rule*. The *Create new rule* page appears. -. Select **{esql}**, then write a query. +. Select **{esql}**, then write a query. + NOTE: Refer to the sections below to learn more about <>, <>, and <>. + @@ -365,32 +365,32 @@ TIP: Click the help icon (image:images/esql-help-ref-button.png[Click the ES|QL + //// -The following steps are repeated across multiple rule types. If you change anything +The following steps are repeated across multiple rule types. If you change anything in these steps or sub-steps, apply the change to the other rule types, too. //// . (Optional) Create a list of **Required fields** that the rule needs to function. This list is informational only, to help users understand the rule; it doesn't affect how the rule actually runs. .. Click **Add required field**, then select a field from the index patterns or data view you specified for the rule. You can also start typing a field's name to find it faster, or type in an entirely new custom field. .. Enter the field's data type. -. (Optional) Add *Related integrations* to associate the rule with one or more {integrations-docs}[Elastic integrations]. This indicates the rule's dependency on specific integrations and the data they generate, and allows users to confirm each integration's <> when viewing the rule. +. (Optional) Add *Related integrations* to associate the rule with one or more {integrations-docs}[Elastic integrations]. This indicates the rule's dependency on specific integrations and the data they generate, and allows users to confirm each integration's <> when viewing the rule. .. Click *Add integration*, then select an integration from the list. You can also start typing an integration's name to find it faster. .. Enter the version of the integration you want to associate with the rule, using https://semver.org[semantic versioning]. For version ranges, you must use tilde or caret syntax. For example, `~1.2.3` is from 1.2.3 to any patch version less than 1.3.0, and `^1.2.3` is from 1.2.3 to any minor and patch version less than 2.0.0. . Click *Continue* to <>. -[float] +[discrete] [[esql-rule-query-types]] -==== {esql} query types +==== {esql} query types -{esql} rule queries are loosely categorized into two types: aggregating and non-aggregating. +{esql} rule queries are loosely categorized into two types: aggregating and non-aggregating. -[float] +[discrete] [[esql-agg-query]] -===== Aggregating query +===== Aggregating query Aggregating queries use {ref}/esql-functions-operators.html#esql-agg-functions[`STATS...BY`] functions to aggregate source event data. Alerts generated by a rule with an aggregating query only contain the fields that the {esql} query returns and any new fields that the query creates. -NOTE: A _new field_ is a field that doesn't exist in the query's source index and is instead created when the rule runs. You can access new fields in the details of any alerts that are generated by the rule. For example, if you use the `STATS...BY` function to create a column with aggregated values, the column is created when the rule runs and is added as a new field to any alerts that are generated by the rule. +NOTE: A _new field_ is a field that doesn't exist in the query's source index and is instead created when the rule runs. You can access new fields in the details of any alerts that are generated by the rule. For example, if you use the `STATS...BY` function to create a column with aggregated values, the column is created when the rule runs and is added as a new field to any alerts that are generated by the rule. Here is an example aggregating query: @@ -402,17 +402,17 @@ FROM logs-* | WHERE host_count > 20 ---- -- This query starts by searching logs from indices that match the pattern `logs-*`. +- This query starts by searching logs from indices that match the pattern `logs-*`. - The query then aggregates the count of events by `host.name`. - Next, it sorts the result by `host_count` in descending order. - Then, it filters for events where the `host_count` field appears more than 20 times during the specified rule interval. NOTE: Rules that use aggregating queries might create duplicate alerts. This can happen when events that occur in the additional look-back time are aggregated both in the current rule execution and in a previous rule execution. -[float] +[discrete] [[esql-non-agg-query]] -===== Non-aggregating query -Non-aggregating queries don't use `STATS...BY` functions and don't aggregate source event data. Alerts generated by a non-aggregating query contain source event fields that the query returns, new fields the query creates, and all other fields in the source event document. +===== Non-aggregating query +Non-aggregating queries don't use `STATS...BY` functions and don't aggregate source event data. Alerts generated by a non-aggregating query contain source event fields that the query returns, new fields the query creates, and all other fields in the source event document. NOTE: A _new field_ is a field that doesn't exist in the query's source index and is instead created when the rule runs. You can access new fields in the details of any alerts that are generated by the rule. For example, if you use the {ref}/esql-commands.html#esql-eval[`EVAL`] command to append new columns with calculated values, the columns are created when the rule runs, and are added as new fields to any alerts generated by the rule. @@ -423,11 +423,11 @@ FROM logs-* METADATA _id, _index, _version | WHERE event.category == "process" AND event.id == "8a4f500d" | LIMIT 10 ----- -- This query starts by querying logs from indices that match the pattern `logs-*`. The `METADATA _id, _index, _version` operator allows <>. -- Next, the query filters events where the `event.category` is a process and the `event.id` is `8a4f500d`. +- This query starts by querying logs from indices that match the pattern `logs-*`. The `METADATA _id, _index, _version` operator allows <>. +- Next, the query filters events where the `event.category` is a process and the `event.id` is `8a4f500d`. - Then, it limits the output to the top 10 results. -[float] +[discrete] [[esql-non-agg-query-dedupe]] ===== Turn on alert deduplication for rules using non-aggregating queries @@ -442,7 +442,7 @@ FROM logs-* METADATA _id, _index, _version When those metadata fields are provided, unique alert IDs are created for each alert generated by the query. -When developing the query, make sure you don't {ref}/esql-commands.html#esql-drop[`DROP`] or filter out the `_id`, `_index`, or `_version` metadata fields. +When developing the query, make sure you don't {ref}/esql-commands.html#esql-drop[`DROP`] or filter out the `_id`, `_index`, or `_version` metadata fields. Here is an example of a query that fails to deduplicate alerts. It uses the `DROP` command to omit the `_id` property from the results table: @@ -454,7 +454,7 @@ FROM logs-* METADATA _id, _index, _version | LIMIT 10 ----- -Here is another example of an invalid query that uses the `KEEP` command to only return `event.*` fields in the results table: +Here is another example of an invalid query that uses the `KEEP` command to only return `event.*` fields in the results table: [source,esql] ----- @@ -464,34 +464,34 @@ FROM logs-* METADATA _id, _index, _version | LIMIT 10 ----- -[float] +[discrete] [[esql-query-design]] -==== Query design considerations +==== Query design considerations When writing your query, consider the following: - The {ref}/esql-commands.html#esql-limit[`LIMIT`] command specifies the maximum number of rows an {esql} query returns and the maximum number of alerts created per rule execution. Similarly, a detection rule's **Max alerts per run** setting specifies the maximum number of alerts it can create every time it runs. -+ -If the `LIMIT` value and **Max alerts per run** value are different, the rule uses the lower value to determine the maximum number of alerts the rule generates. ++ +If the `LIMIT` value and **Max alerts per run** value are different, the rule uses the lower value to determine the maximum number of alerts the rule generates. + -- When writing an aggregating query, use the {ref}/esql-commands.html#esql-stats-by[`STATS...BY`] command with fields that you want to search and filter for after alerts are created. For example, using the `host.name`, `user.name`, `process.name` fields with the `BY` operator of the `STATS...BY` command returns these fields in alert documents, and allows you to search and filter for them from the Alerts table. +- When writing an aggregating query, use the {ref}/esql-commands.html#esql-stats-by[`STATS...BY`] command with fields that you want to search and filter for after alerts are created. For example, using the `host.name`, `user.name`, `process.name` fields with the `BY` operator of the `STATS...BY` command returns these fields in alert documents, and allows you to search and filter for them from the Alerts table. - When configuring alert suppression on a non-aggregating query, we recommend sorting results by ascending `@timestamp` order. Doing so ensures that alerts are properly suppressed, especially if the number of alerts generated is higher than the **Max alerts per run** value. -[float] +[discrete] [[esql-rule-limitations]] -==== {esql} rule limitations +==== {esql} rule limitations -If your {esql} query creates new fields that aren’t part of the ECS schema, they aren't mapped to the alerts index so you can't search for or filter them in the Alerts table. As a workaround, create <>. +If your {esql} query creates new fields that aren’t part of the ECS schema, they aren't mapped to the alerts index so you can't search for or filter them in the Alerts table. As a workaround, create <>. -[float] +[discrete] [[custom-highlighted-esql-fields]] -==== Highlight fields returned by the {esql} rule query +==== Highlight fields returned by the {esql} rule query -When configuring an {esql} rule's **<>**, you can specify any fields that the rule's aggregating or non-aggregating query return. This can help ensure that returned fields are visible in the alert details flyout while you're investigating alerts. +When configuring an {esql} rule's **<>**, you can specify any fields that the rule's aggregating or non-aggregating query return. This can help ensure that returned fields are visible in the alert details flyout while you're investigating alerts. -[float] +[discrete] [[rule-ui-basic-params]] === Configure basic rule settings @@ -539,7 +539,7 @@ the rule. * <> * <> -[float] +[discrete] [[rule-ui-advanced-params]] === Configure advanced rule settings (optional) @@ -549,10 +549,10 @@ the rule. For example, links to background information. .. *False positive examples* (optional): List of common scenarios that may produce false-positive alerts. .. *MITRE ATT&CK^TM^ threats* (optional): Add relevant https://attack.mitre.org/[MITRE] framework tactics, techniques, and subtechniques. -.. *Custom highlighted fields* (optional): Specify one or more highlighted fields for unique alert investigation flows. You can choose any fields that are available in the indices you selected for the rule's data source. +.. *Custom highlighted fields* (optional): Specify one or more highlighted fields for unique alert investigation flows. You can choose any fields that are available in the indices you selected for the rule's data source. + -After you create the rule, you can find all custom highlighted fields in the About section of the rule details page. If the rule has alerts, you can find custom highlighted fields in the <> section of the alert details flyout. - +After you create the rule, you can find all custom highlighted fields in the About section of the rule details page. If the rule has alerts, you can find custom highlighted fields in the <> section of the alert details flyout. + .. *Setup guide* (optional): Instructions on rule prerequisites such as required integrations, configuration steps, and anything else needed for the rule to work correctly. .. *Investigation guide* (optional): Information for analysts investigating alerts created by the rule. You can also add action buttons to <> or <> using alert data. @@ -598,7 +598,7 @@ image::images/schedule-rule.png[] . Continue with <>. -[float] +[discrete] [[rule-schedule]] === Set the rule's schedule @@ -626,7 +626,7 @@ run exactly at its scheduled time. * Continue onto <> and <> (optional). * Create the rule (with or without activation). -[float] +[discrete] [[rule-notifications]] === Set up rule actions (optional) @@ -638,7 +638,7 @@ https://www.elastic.co/subscriptions[appropriate license] and your role needs *A . Select a connector type to determine how notifications are sent. For example, if you select the {jira} connector, notifications are sent to your {jira} system. + -[NOTE] +[NOTE] ===== Each action type requires a connector. Connectors store the information required to send the notification from the external system. You can @@ -651,11 +651,11 @@ Some connectors that perform actions require less configuration. For example, yo . After you select a connector, set its action frequency to define when notifications are sent: -** *Summary of alerts*: Select this option to get a report that summarizes generated alerts, which you can review at your convenience. Alert summaries will be sent at the specified time intervals. +** *Summary of alerts*: Select this option to get a report that summarizes generated alerts, which you can review at your convenience. Alert summaries will be sent at the specified time intervals. + -NOTE: When setting a custom notification frequency, do not choose a time that is shorter than the rule's execution schedule. +NOTE: When setting a custom notification frequency, do not choose a time that is shorter than the rule's execution schedule. -** *For each alert*: Select this option to ensure notifications are sent every time new alerts are generated. +** *For each alert*: Select this option to ensure notifications are sent every time new alerts are generated. . (Optional) Specify additional conditions that need to be met for notifications to send. Click the toggle to enable a setting, then add the required details: @@ -687,15 +687,15 @@ When a rule fails to run, the {security-app} tries to rerun it at its next scheduled run time. ============== -[float] +[discrete] [[rule-action-variables]] ==== Alert notification placeholders -You can use http://mustache.github.io/[mustache syntax] to add variables to notification messages. The action frequency you choose determines the variables you can select from. +You can use http://mustache.github.io/[mustache syntax] to add variables to notification messages. The action frequency you choose determines the variables you can select from. -The following variables can be passed for all rules: +The following variables can be passed for all rules: -NOTE: Refer to {kibana-ref}/rule-action-variables.html#alert-summary-action-variables[Action frequency: Summary of alerts] to learn about additional variables that can be passed if the rule's action frequency is **Summary of alerts**. +NOTE: Refer to {kibana-ref}/rule-action-variables.html#alert-summary-action-variables[Action frequency: Summary of alerts] to learn about additional variables that can be passed if the rule's action frequency is **Summary of alerts**. * `{{context.alerts}}`: Array of detected alerts * `{{{context.results_link}}}`: URL to the alerts in {kib} @@ -738,7 +738,7 @@ NOTE: This placeholder contains the rule's default values even when the *Severit * `{{rule.type}}`: Type of rule * `{{state.signals_count}}`: Number of alerts detected -The following variables can only be passed if the rule’s action frequency is for each alert: +The following variables can only be passed if the rule’s action frequency is for each alert: * `{{alert.actionGroup}}`: Action group of the alert that scheduled actions for the rule * `{{alert.actionGroupName}}`: Human-readable name of the action group of the alert that scheduled actions for the rule @@ -746,7 +746,7 @@ The following variables can only be passed if the rule’s action frequency is f * `{{alert.id}}`: ID of the alert that scheduled actions for the rule * `{{alert.flapping}}`: A flag on the alert that indicates whether the alert status is changing repeatedly -[float] +[discrete] [[placeholder-examples]] ===== Alert placeholder examples @@ -777,7 +777,7 @@ Example using the mustache "current element" notation `{{.}}` to output all the {{#signal.rule.references}} {{.}} {{/signal.rule.references}} -------------------------------------------------- -[float] +[discrete] [[rule-response-action]] ==== Set up response actions (optional) Use response actions to set up additional functionality that will run whenever a rule executes: @@ -797,7 +797,7 @@ You can preview any custom or prebuilt rule to find out how noisy it will be. Fo NOTE: To preview rules, you need the `read` privilege for the `.preview.alerts-security.alerts-` and `.internal.preview.alerts-security.alerts--*` indices, plus `All` privileges for the Security feature. Refer to <> for more information. -Click the *Rule preview* button while creating or editing a rule. The preview opens in a side panel, showing a histogram and table with the alerts you can expect, based on the defined rule settings and past events in your indices. +Click the *Rule preview* button while creating or editing a rule. The preview opens in a side panel, showing a histogram and table with the alerts you can expect, based on the defined rule settings and past events in your indices. [role="screenshot"] image::images/preview-rule.png[Rule preview] @@ -810,7 +810,7 @@ To interact with the rule preview: + TIP: Avoid setting long time ranges with short rule intervals, or the rule preview might time out. -* Click *Refresh* to update the preview. +* Click *Refresh* to update the preview. ** When you edit the rule's settings or the preview's time range, the button changes from blue (image:images/rule-preview-refresh-circle.png[Blue circular refresh icon,16,17]) to green (image:images/rule-preview-refresh-arrow.png[Green right-pointing arrow refresh icon,17,17]) to indicate that the rule has been edited since the last preview. ** For a relative time range (such as `Last 1 hour`), refresh the preview to check for the latest results. (Previews don't automatically refresh with new incoming data.) @@ -826,15 +826,15 @@ TIP: Avoid setting long time ranges with short rule intervals, or the rule previ NOTE: This option is only offered for {esql} and event correlation rules. -When previewing a rule, you can also learn about its {es} queries, which are submitted when the rule runs. This information can help you identify and troubleshoot potential rule issues. You can also use it to confirm that your rule is retrieving the expected data. +When previewing a rule, you can also learn about its {es} queries, which are submitted when the rule runs. This information can help you identify and troubleshoot potential rule issues. You can also use it to confirm that your rule is retrieving the expected data. To learn more about your rule's {es} queries, preview its results and do the following: -. Select the **Show {es} requests, ran during rule executions** option below the preview's date and time picker. The **Preview logged results** section displays under the histogram and alerts table. -. Click the **Preview logged results** section to expand it. Within the section, each rule execution is shown on an individual row. +. Select the **Show {es} requests, ran during rule executions** option below the preview's date and time picker. The **Preview logged results** section displays under the histogram and alerts table. +. Click the **Preview logged results** section to expand it. Within the section, each rule execution is shown on an individual row. . Expand each row to learn more about the {es} queries that the rule submits each time it executes. The following details are provided: ** When the rule execution started, and how long it took to complete ** A brief explanation of what the {es} queries do -** The actual {es} queries that the rule submits to indices containing events that are used during the rule execution +** The actual {es} queries that the rule submits to indices containing events that are used during the rule execution + TIP: Run the queries in {kibana-ref}/console-kibana.html[Console] to determine if your rule is retrieving the expected data. For example, to test your rule’s exceptions, run the rule’s {es} queries, which will also contain exceptions added to the rule. If your rule’s exceptions are working as intended, the query will not return events that should be ignored. diff --git a/docs/detections/rules-ui-manage.asciidoc b/docs/detections/rules-ui-manage.asciidoc index 2c033b4151..dca76f3806 100644 --- a/docs/detections/rules-ui-manage.asciidoc +++ b/docs/detections/rules-ui-manage.asciidoc @@ -23,7 +23,7 @@ On the Rules page, you can: * <> * <> -[float] +[discrete] [[sort-filter-rules]] === Sort and filter the rules list @@ -32,7 +32,7 @@ To sort the rules list, click any column header. To sort in descending order, cl To filter the rules list, enter a search term in the search bar and press **Return**: * Rule name — Enter a word or phrase from a rule's name. -* Index pattern — Enter an index pattern (such as `filebeat-*`) to display all rules that use it. +* Index pattern — Enter an index pattern (such as `filebeat-*`) to display all rules that use it. * MITRE ATT&CK tactic or technique — Enter a MITRE ATT&CK tactic name (such as `Defense Evasion`) or technique number (such as `TA0005`) to display all associated rules. NOTE: Searches for index patterns and MITRE ATT&CK tactics and techniques must match exactly, are case sensitive, and do _not_ support wildcards. For example, to find rules using the `filebeat-*` index pattern, the search term `filebeat-*` is valid, but `filebeat` and `file*` are not because they don't exactly match the index pattern. Likewise, the MITRE ATT&CK tactic `Defense Evasion` is valid, but `Defense`, `defense evasion`, and `Defense*` are not. @@ -41,7 +41,7 @@ You can also filter the rules list by selecting the *Tags*, *Last response*, *El The rules list retains your sorting and filtering settings when you navigate away and return to the page. These settings are also preserved when you copy the page's URL and paste into another browser. Select *Clear filters* above the table to revert to the default view. -[float] +[discrete] [[rule-status]] === Check the current status of rules @@ -54,7 +54,7 @@ The *Last response* column displays the current status of each rule, based on th For {ml} rules, an indicator icon (image:images/rules-table-error-icon.png[Error icon from rules table,15,15]) also appears in this column if a required {ml} job isn't running. Click the icon to list the affected jobs, then click *Visit rule details page to investigate* to open the rule's details page, where you can start the {ml} job. -[float] +[discrete] [[edit-rules-settings]] === Modify existing rules settings @@ -73,30 +73,30 @@ Similarly, rules will be skipped if they can't be modified by a bulk edit. For e * Bulk edit multiple rules: Select the rules you want to edit, then select an action from the *Bulk actions* menu: ** *Index patterns*: Add or delete the index patterns used by all selected rules. ** *Tags*: Add or delete tags on all selected rules. -** *Custom highlighted fields*: Add custom highlighted fields on all selected rules. You can choose any fields that are available in the <>, or enter field names from other indices. To overwrite a rule's current set of custom highlighted fields, select the **Overwrite all selected rules' custom highlighted fields** option, then click **Save**. +** *Custom highlighted fields*: Add custom highlighted fields on all selected rules. You can choose any fields that are available in the <>, or enter field names from other indices. To overwrite a rule's current set of custom highlighted fields, select the **Overwrite all selected rules' custom highlighted fields** option, then click **Save**. ** *Add rule actions*: Add <> on all selected rules. If you add multiple actions, you can specify an action frequency for each of them. To overwrite the frequency of existing actions select the option to **Overwrite all selected rules actions**. + -IMPORTANT: After upgrading to 8.8 or later, frequency settings for rule actions created in 8.7 or earlier are moved from the rule level to the action level. The action schedules remain the same and will continue to run on their previously specified frequency (`On each rule execution`, `Hourly`, `Daily`, or `Weekly`). +IMPORTANT: After upgrading to 8.8 or later, frequency settings for rule actions created in 8.7 or earlier are moved from the rule level to the action level. The action schedules remain the same and will continue to run on their previously specified frequency (`On each rule execution`, `Hourly`, `Daily`, or `Weekly`). + NOTE: Rule actions won't run during a {kibana-ref}/maintenance-windows.html[maintenance window]. They'll resume running after the maintenance window ends. ** *Update rule schedules*: Update the <> and look-back times on all selected rules. ** *Apply Timeline template*: Apply a specified <> to the selected rules. You can also choose *None* to remove Timeline templates from the selected rules. -. On the flyout that opens, update the rule settings and actions. +. On the flyout that opens, update the rule settings and actions. + TIP: To <> rule actions, go to the *Actions* tab and click the bell icon. . If available, select *Overwrite all selected _x_* to overwrite the settings on the rules. For example, if you're adding tags to multiple rules, selecting *Overwrite all selected rules tags* removes all the rules' original tags and replaces them with the tags you specify. . Click *Save*. -[float] +[discrete] [[manage-rules-ui]] === Manage rules You can duplicate, enable, disable, delete, and snooze actions for rules: -NOTE: When duplicating a rule with exceptions, you can choose to duplicate the rule and its exceptions (active and expired), the rule and active exceptions only, or only the rule. If you duplicate the rule and its exceptions, copies of the exceptions are created and added to the duplicated rule's <>. If the original rule used exceptions from a shared exception list, the duplicated rule will reference the same shared exception list. +NOTE: When duplicating a rule with exceptions, you can choose to duplicate the rule and its exceptions (active and expired), the rule and active exceptions only, or only the rule. If you duplicate the rule and its exceptions, copies of the exceptions are created and added to the duplicated rule's <>. If the original rule used exceptions from a shared exception list, the duplicated rule will reference the same shared exception list. . Go to *Rules* -> *Detection rules (SIEM)*. . Do one of the following: @@ -105,13 +105,13 @@ NOTE: When duplicating a rule with exceptions, you can choose to duplicate the r * To enable or disable a single rule, switch on the rule's *Enabled* toggle. * To <> actions for rules, click the bell icon. -[float] +[discrete] [[manually-run-rules]] === Run rules manually beta::[] -Manually run enabled rules for a specified period of time for testing purposes or additional rule coverage. +Manually run enabled rules for a specified period of time for testing purposes or additional rule coverage. IMPORTANT: Before manually running rules, make sure you properly understand and plan for rule dependencies. Incorrect scheduling can lead to inconsistent rule results. @@ -125,20 +125,20 @@ NOTE: Manual runs can produce multiple rule executions. This is determined by th The manual run's details are shown in the <> table on the *Execution results* tab. Changes you make to the manual run or rule settings will display in the Manual runs table after the current run completes. -[NOTE] +[NOTE] ===== Be mindful of the following: -* Rule actions are not activated during manual runs. +* Rule actions are not activated during manual runs. * Except for threshold rules, duplicate alerts aren't created if you manually run a rule during a time range that was already covered by a scheduled run. * Manual runs are executed with low priority and limited concurrency, meaning they might take longer to complete. This can be especially apparent for rules requiring multiple executions. ===== -[float] +[discrete] [[snooze-rule-actions]] === Snooze rule actions -Instead of turning rules off to stop alert notifications, you can snooze rule actions for a specified time period. When you snooze rule actions, the rule continues to run on its defined schedule, but won't perform any actions or send alert notifications. +Instead of turning rules off to stop alert notifications, you can snooze rule actions for a specified time period. When you snooze rule actions, the rule continues to run on its defined schedule, but won't perform any actions or send alert notifications. You can snooze notifications temporarily or indefinitely. When actions are snoozed, you can cancel or change the duration of the snoozed state. You can also schedule and manage recurring downtime for actions. @@ -147,11 +147,11 @@ You can snooze rule notifications from the *Installed Rules* tab, the rule detai [role="screenshot"] image::images/rule-snoozing.png[Rules snooze options,65%] -[float] +[discrete] [[import-export-rules-ui]] === Export and import rules -You can export custom detection rules to an `.ndjson` file, which you can then import into another {elastic-sec} environment. +You can export custom detection rules to an `.ndjson` file, which you can then import into another {elastic-sec} environment. [NOTE] ==== @@ -190,13 +190,13 @@ NOTE: Imported rules must be in an `.ndjson` file. .. (Optional) Select *Overwrite existing exception lists with conflicting "list_id"* to replace existing exception lists with exception lists from the import file if they have a matching `list_id` value. .. (Optional) Select *Overwrite existing connectors with conflicting action "id"* to update existing connectors if they match the `action id` value of any rule actions in the import file. Configuration data included with the actions is also overwritten. .. Click *Import rule*. -.. (Optional) If a connector is missing sensitive information after the import, a warning displays and you're prompted to fix the connector. In the warning, click *Go to connector*. On the Connectors page, find the connector that needs to be updated, click *Fix*, then add the necessary details. +.. (Optional) If a connector is missing sensitive information after the import, a warning displays and you're prompted to fix the connector. In the warning, click *Go to connector*. On the Connectors page, find the connector that needs to be updated, click *Fix*, then add the necessary details. -[float] +[discrete] [[rule-prerequisites]] === Confirm rule prerequisites -Many detection rules are designed to work with specific {integrations-docs}[Elastic integrations] and data fields. These prerequisites are identified in *Related integrations* and *Required fields* on a rule's details page (*Rules* -> *Detection rules (SIEM)*, then click a rule's name). *Related integrations* also displays each integration's installation status and includes links for installing and configuring the listed integrations. +Many detection rules are designed to work with specific {integrations-docs}[Elastic integrations] and data fields. These prerequisites are identified in *Related integrations* and *Required fields* on a rule's details page (*Rules* -> *Detection rules (SIEM)*, then click a rule's name). *Related integrations* also displays each integration's installation status and includes links for installing and configuring the listed integrations. Additionally, the *Setup guide* section provides guidance on setting up the rule's requirements. diff --git a/docs/detections/rules-ui-monitor.asciidoc b/docs/detections/rules-ui-monitor.asciidoc index 946c98ac54..3c334d4529 100644 --- a/docs/detections/rules-ui-monitor.asciidoc +++ b/docs/detections/rules-ui-monitor.asciidoc @@ -16,7 +16,7 @@ Several tools can help you gain insight into the performance of your detection r Refer to the <> section below for strategies on adjusting rules if they aren't creating the expected alerts. -[float] +[discrete] [[rule-monitoring-tab]] === Rule Monitoring tab @@ -27,13 +27,13 @@ times, select the *Rule Monitoring* tab on the *Rules* page (*Rules* -> [role="screenshot"] image::images/monitor-table.png[] -On the *Rule Monitoring* tab, you can <> just like you can on the *Installed Rules* tab. +On the *Rule Monitoring* tab, you can <> just like you can on the *Installed Rules* tab. TIP: To sort the rules list, click any column header. To sort in descending order, click the column header again. For detailed information on a rule, the alerts it generated, and associated errors, click on its name in the table. This also allows you to perform the same actions that are available on the <>, such as modifying or deleting rules, activating or deactivating rules, exporting or importing rules, and duplicating prebuilt rules. -[float] +[discrete] [[rule-execution-logs]] === Execution results @@ -48,11 +48,11 @@ You can hover over each column heading to display a tooltip about that column's Use these controls to filter what's included in the logs table: -* The **Run type** drop-down filters the table by rule execution type: +* The **Run type** drop-down filters the table by rule execution type: ** **Scheduled**: Automatic, scheduled rule executions. ** **Manual**: Rule executions that were <>. -* The *Status* drop-down filters the table by rule execution status: +* The *Status* drop-down filters the table by rule execution status: ** *Succeeded*: The rule completed its defined search. This doesn't necessarily mean it generated an alert, just that it ran without error. ** *Failed*: The rule encountered an error that prevented it from running. For example, a {ml} rule whose corresponding {ml} job wasn't running. ** *Warning*: Nothing prevented the rule from running, but it might have returned unexpected results. For example, a custom query rule tried to search an index pattern that couldn't be found in {es}. @@ -65,7 +65,7 @@ Use these controls to filter what's included in the logs table: * The *Actions* column allows you to show alerts generated from a given rule execution. Click the filter icon (image:images/filter-icon.png[Filter icon,18,17]) to create a global search filter based on the rule execution's ID value. This replaces any previously applied filters, changes the global date and time range to 24 hours before and after the rule execution, and displays a confirmation notification. You can revert this action by clicking *Restore previous filters* in the notification. -[float] +[discrete] [[manual-runs-table]] ==== Manual runs table @@ -73,7 +73,7 @@ beta::[] Each manual run can produce multiple rule executions, depending on the time range of the run and the rule's execution schedule. These details are shown in the Manual runs table. -To access the table, navigate to the detection rules page, click the rule's name to open its details, then scroll down and select the **Execution results** tab. Scroll down again to find the Manual runs table. +To access the table, navigate to the detection rules page, click the rule's name to open its details, then scroll down and select the **Execution results** tab. Scroll down again to find the Manual runs table. To stop an active run, go to the appropriate row and click **Stop run** in the **Actions** column. Completed rule executions for each manual run are logged in the Execution log table. @@ -83,7 +83,7 @@ image::images/manual-rule-run-table.png[Manual rule runs table on the rule execu The Manual runs table displays important details such as: * The status of each manual run: -** **Pending**: The rule is not yet running. +** **Pending**: The rule is not yet running. ** **Running**: The rule is executing during the time range you specified. Some rules, such as indicator match rules, can take longer to run. ** **Error**: The rule's configuration is preventing it from running correctly. For example, the rule's conditions cannot be validated. @@ -93,7 +93,7 @@ The Manual runs table displays important details such as: * The total number of rule executions that are occurring for a manual run -[float] +[discrete] [[troubleshoot-signals]] === Troubleshoot missing alerts @@ -109,15 +109,15 @@ You can also use Task Manager in {kib} to troubleshoot background tasks and proc * {kibana-ref}/task-manager-health-monitoring.html[Task Manager health monitoring] * {kibana-ref}/task-manager-troubleshooting.html[Task Manager troubleshooting] -[float] +[discrete] [[troubleshoot-max-alerts]] ==== Troubleshoot maximum alerts warning -When a rule reaches the maximum number of alerts it can generate during a single rule execution, the following warning appears on the rule's details page and in the rule execution log: `This rule reached the maximum alert limit for the rule execution. Some alerts were not created.` +When a rule reaches the maximum number of alerts it can generate during a single rule execution, the following warning appears on the rule's details page and in the rule execution log: `This rule reached the maximum alert limit for the rule execution. Some alerts were not created.` -If you receive this warning, go to the rule's **Alerts** tab and check for anything unexpected. Unexpected alerts might be created from data source issues or queries that are too broadly scoped. To further reduce alert volume, you can also add <> or <>. +If you receive this warning, go to the rule's **Alerts** tab and check for anything unexpected. Unexpected alerts might be created from data source issues or queries that are too broadly scoped. To further reduce alert volume, you can also add <> or <>. -[float] +[discrete] [[troubleshoot-gaps]] ==== Troubleshoot gaps @@ -141,7 +141,7 @@ and then reactivating them in small batches at staggered intervals. This ensures {kib} does not attempt to run all the rules at the same time. * Consider adding another {kib} instance to your environment. -[float] +[discrete] [[troubleshoot-ingestion-pipeline-delay]] ==== Troubleshoot ingestion pipeline delay @@ -156,11 +156,11 @@ For example, say an event occurred at 10:00 but wasn't ingested into {es} until [role="screenshot"] image::images/timestamp-override.png[] -[float] +[discrete] [[ml-job-compatibility]] ==== Troubleshoot missing alerts for {ml} jobs -{ml-cap} detection rules use {ml} jobs that have dependencies on data fields populated by the {beats} and {agent} integrations. In {stack} version 8.3, new {ml} jobs (prefixed with `v3`) were released to operate on the ECS fields available at that time. +{ml-cap} detection rules use {ml} jobs that have dependencies on data fields populated by the {beats} and {agent} integrations. In {stack} version 8.3, new {ml} jobs (prefixed with `v3`) were released to operate on the ECS fields available at that time. If you're using 8.2 or earlier versions of {beats} or {agent} with {stack} version 8.3 or later, you may need to duplicate prebuilt rules or create new custom rules _before_ you update the Elastic prebuilt rules. Once you update the prebuilt rules, they will only use `v3` {ml} jobs. Duplicating the relevant prebuilt rules before updating them ensures continued coverage by allowing you to keep using `v1` or `v2` jobs (in the duplicated rules) while also running the new `v3` jobs (in the updated prebuilt rules). @@ -200,7 +200,7 @@ The following Elastic prebuilt rules use the new `v3` {ml} jobs to generate aler * <>: `v3_windows_anomalous_process_creation` -* <>: `v3_windows_anomalous_process_all_hosts` +* <>: `v3_windows_anomalous_process_all_hosts` * <>: `v3_windows_anomalous_user_name` diff --git a/docs/detections/shared-exception-lists.asciidoc b/docs/detections/shared-exception-lists.asciidoc index b7eab6e2e9..16b7b33a5b 100644 --- a/docs/detections/shared-exception-lists.asciidoc +++ b/docs/detections/shared-exception-lists.asciidoc @@ -1,33 +1,33 @@ [[shared-exception-lists]] == Create and manage shared exception lists -Shared exception lists allow you to group exceptions together and then apply them to multiple rules. Use the Shared Exception Lists page to set up shared exception lists. +Shared exception lists allow you to group exceptions together and then apply them to multiple rules. Use the Shared Exception Lists page to set up shared exception lists. NOTE: Exception lists created in 8.5 and earlier become shared exception lists in 8.6 or later. You can access all shared exception lists from the Shared Exception Lists page. [role="screenshot"] image::images/rule-exceptions-page.png[Shared Exception Lists page] -[float] +[discrete] [[create-shared-exception-list]] === Create shared exception lists Set up shared exception lists to contain exception items: . Go to *Rules* -> *Shared exception lists*. -. Click *Create shared exception list* -> *Create shared list*. -. Give the shared exception list a name. -. (Optional) Provide a description. +. Click *Create shared exception list* -> *Create shared list*. +. Give the shared exception list a name. +. (Optional) Provide a description. . Click *Create shared exception list*. -[float] +[discrete] [[add-exception-items]] === Add exception items to shared exception lists Add exception items: . Go to *Rules* -> *Shared exception lists*. -. Click *Create shared exception list* -> *Create exception item*. +. Click *Create shared exception list* -> *Create exception item*. + TIP: You can add exceptions to an empty shared exception list by expanding the list, or viewing its details page and clicking *Create rule exception*. After creating an exception, you can associate the shared exception list with rules. Refer to <> to learn more. @@ -57,17 +57,17 @@ IMPORTANT: Using wildcards can impact performance. To create a more efficient ex . Click *Add nested condition* to create conditions using nested fields. This is only required for <>. For all other fields, nested conditions should not be used. -. Choose to add the exception to shared exception lists. -+ -NOTE: This option will be unavailable if a shared exception list doesn't exist. In addition, you can't add an endpoint exception item to the Endpoint Security Exception List from this UI. Refer to <> for instructions about creating endpoint exceptions. +. Choose to add the exception to shared exception lists. ++ +NOTE: This option will be unavailable if a shared exception list doesn't exist. In addition, you can't add an endpoint exception item to the Endpoint Security Exception List from this UI. Refer to <> for instructions about creating endpoint exceptions. . (Optional) Enter a comment describing the exception. -. (Optional) Enter a future expiration date and time for the exception. +. (Optional) Enter a future expiration date and time for the exception. . (Optional) *Close all alerts that match this exception and were generated by this rule*: Closes all alerts that match the exception's conditions and were generated only by the current rule. . Click *Add rule exception*. -[float] +[discrete] [[link-shared-exception-lists]] === Associate shared exception lists with rules @@ -75,24 +75,24 @@ Apply shared exception lists to rules: . Go to *Rules* -> *Shared exception lists*. . Do one of the following: -** Select a shared exception list's name to open its details page, then click *Link rules*. +** Select a shared exception list's name to open its details page, then click *Link rules*. ** Find the shared exception list you want to assign to rules, then from the *More actions* menu (*...*), select *Link rules*. . Click the toggles in the *Link* column to select the rules you want to link to the exception list. + TIP: If you know a rule's name, you can enter it into the search bar. -. Click *Save*. +. Click *Save*. . (Optional) To verify that the shared exception list was added to the rules you selected: .. Open a rule’s details page (*Rules → Detection rules (SIEM) → _Rule name_*). -.. Scroll down the page, and then select the *Rule exceptions* tab. +.. Scroll down the page, and then select the *Rule exceptions* tab. .. Navigate to the exception items that are included in the shared exception list. Click the *Affects shared list* link to view the associated shared exception lists. + [role="screenshot"] image::images/associated-shared-exception-list.png[Associated shared exceptions] -[float] +[discrete] [[view-shared-exception-lists]] -=== View and filter exception lists +=== View and filter exception lists The Shared Exception Lists page displays each shared exception list on an individual row, with the most recently created list at the top. Each row contains these details about the shared exception list: @@ -115,20 +115,20 @@ To filter exception lists by a specific value, enter a value in the search bar. If no attribute is selected, the app searches the list name by default. -[float] +[discrete] [[manage-exception-lists]] === Manage shared exception lists -You can edit, export, import, duplicate, and delete shared exception lists from the Shared Exception Lists page. +You can edit, export, import, duplicate, and delete shared exception lists from the Shared Exception Lists page. -NOTE: Exception lists created in 8.5 and earlier become shared exception lists in 8.6 or later. You can access all shared exception lists from the Shared Exception Lists page. +NOTE: Exception lists created in 8.5 and earlier become shared exception lists in 8.6 or later. You can access all shared exception lists from the Shared Exception Lists page. To export or delete an exception list, select the required action button on the appropriate list. Note the following: * Exception lists are exported to `.ndjson` files. * Exception lists are also exported as part of any exported detection rules configured with exceptions. Refer to <>. -* If an exception list is linked to any rules, you'll get a warning asking you to confirm the deletion. -* If an exception list contains expired exceptions, you can choose whether to include them in the exported file. +* If an exception list is linked to any rules, you'll get a warning asking you to confirm the deletion. +* If an exception list contains expired exceptions, you can choose whether to include them in the exported file. [role="screenshot"] image::images/actions-exception-list.png[Detail of Exception lists table with export and delete buttons highlighted] \ No newline at end of file diff --git a/docs/detections/value-list-exceptions.asciidoc b/docs/detections/value-list-exceptions.asciidoc index 609c2ef095..5279426f36 100644 --- a/docs/detections/value-list-exceptions.asciidoc +++ b/docs/detections/value-list-exceptions.asciidoc @@ -1,7 +1,7 @@ [[value-lists-exceptions]] == Create and manage value lists -Value lists hold multiple values of the same Elasticsearch data type, such as IP addresses, which are used to determine when an exception prevents an alert from being generated. You can use value lists to define exceptions for detection rules; however, you cannot use value lists to define endpoint rule exceptions. +Value lists hold multiple values of the same Elasticsearch data type, such as IP addresses, which are used to determine when an exception prevents an alert from being generated. You can use value lists to define exceptions for detection rules; however, you cannot use value lists to define endpoint rule exceptions. Value lists are lists of items with the same {es} {ref}/mapping-types.html[data type]. You can create value lists with these types: @@ -14,10 +14,10 @@ After creating value lists, you can use `is in list` and `is not in list` operat TIP: You can also use a value list as the <> when creating an indicator match rule. -[float] +[discrete] [[create-value-lists]] === Create value lists -When you create a value list for a rule exception, be mindful of the list's size and data type. All rule types support value list exceptions, but extremely large lists or certain data types have limitations. +When you create a value list for a rule exception, be mindful of the list's size and data type. All rule types support value list exceptions, but extremely large lists or certain data types have limitations. Custom query, machine learning, and indicator match rules support the following value list types and sizes: @@ -55,29 +55,29 @@ NOTE: If you import a file with a name that already exists, a new list is not cr [discrete] === Manage value lists -You can edit, remove, or export existing value lists. +You can edit, remove, or export existing value lists. [[edit-value-lists]] [discrete] ==== Edit value lists . Go to **Rules** → **Detection rules (SIEM)**. -. Click **Manage value lists**. The **Manage value lists** window opens. +. Click **Manage value lists**. The **Manage value lists** window opens. . In the **Value lists** table, click the value list you want to edit. . Do any of the following: -** **Filter items in the list**: Use the KQL search bar to find values in the list. Depending on your list's type, you can filter by the `keyword`, `ip_range`, `ip`, or `text` fields. For example, to filter by Gmail addresses in a value list of the `keyword` type, enter `keyword:*gmail.com` into the search bar. +** **Filter items in the list**: Use the KQL search bar to find values in the list. Depending on your list's type, you can filter by the `keyword`, `ip_range`, `ip`, or `text` fields. For example, to filter by Gmail addresses in a value list of the `keyword` type, enter `keyword:*gmail.com` into the search bar. + -You can also filter by the `updated_by` field (for example, `updated_by:testuser`), or the `updated at` field (for example, `updated_at < now`). +You can also filter by the `updated_by` field (for example, `updated_by:testuser`), or the `updated at` field (for example, `updated_at < now`). ** **Add individual items to the list**: Click **Create list item**, enter a value, then click **Add list item**. ** **Bulk upload list items**: Drag or select the `csv` or `txt` file that contains the values that you want to add, then click **Upload**. -** **Edit a value**: In the Value column, go to the value you want to edit and click the **Edit** button (image:images/edit-value-list-item.png[Edit button from Manage value lists window,15,15]). When you're done editing, click the **Save** button (image:images/save-value-list-item-changes.png[Save button from Manage value lists window,18,18]) to save your changes. Click the **Cancel** button (image:images/cancel-value-list-item-changes.png[Cancel button from Manage value lists window,18,18]) to revert your changes. +** **Edit a value**: In the Value column, go to the value you want to edit and click the **Edit** button (image:images/edit-value-list-item.png[Edit button from Manage value lists window,15,15]). When you're done editing, click the **Save** button (image:images/save-value-list-item-changes.png[Save button from Manage value lists window,18,18]) to save your changes. Click the **Cancel** button (image:images/cancel-value-list-item-changes.png[Cancel button from Manage value lists window,18,18]) to revert your changes. ** **Remove a value**: Click the **Remove value** button (image:images/remove-value-list-item.png[Remove value list button from Manage value lists window,15,15]) to delete a value from the list. [role="screenshot"] image::images/edit-value-lists.png[Manage items in a value lists,75%] -TIP: You can also edit value lists while creating and managing exceptions that use value lists. +TIP: You can also edit value lists while creating and managing exceptions that use value lists. [[export-remove-value-lists]] [discrete] @@ -86,7 +86,7 @@ TIP: You can also edit value lists while creating and managing exceptions that u . Go to *Rules* -> *Detection rules (SIEM)*. . Click *Manage value lists*. The *Manage value lists* window opens. . From the *Value lists* table, you can: -.. Click the **Export value list** button (image:images/export-value-list.png[Export button from Manage value lists window,15,15]) to export the value list. +.. Click the **Export value list** button (image:images/export-value-list.png[Export button from Manage value lists window,15,15]) to export the value list. .. Click the **Remove value list** button (image:images/remove-value-list.png[Remove button from Manage value lists window,15,15]) to delete the value list. + [role="screenshot"] diff --git a/docs/detections/visual-event-analyzer.asciidoc b/docs/detections/visual-event-analyzer.asciidoc index 4e422292e5..41d9e79b6b 100644 --- a/docs/detections/visual-event-analyzer.asciidoc +++ b/docs/detections/visual-event-analyzer.asciidoc @@ -6,7 +6,7 @@ TIP: If you're experiencing performance degradation, you can <> from analyzer queries. -[float] +[discrete] [[find-events-analyze]] == Find events to analyze @@ -65,7 +65,7 @@ Click the **Legend** to show the state of each process node. [role="screenshot"] image::images/node-legend.png[] -Use the date and time filter to analyze the event within a specific time range. By default, the selected time range matches that of the table from which you opened the alert. +Use the date and time filter to analyze the event within a specific time range. By default, the selected time range matches that of the table from which you opened the alert. [role="screenshot"] image::images/date-range-selection.png[] diff --git a/docs/getting-started/ingest-data.asciidoc b/docs/getting-started/ingest-data.asciidoc index ebbf6aef5d..507436bf10 100644 --- a/docs/getting-started/ingest-data.asciidoc +++ b/docs/getting-started/ingest-data.asciidoc @@ -60,7 +60,7 @@ TIP: On the Integrations page, you can select the *Beats only* filter to only vi [role="screenshot"] image::images/add-integrations.png[Shows button to add integrations] -[float] +[discrete] === Download and install {beats} from the command line To install {beats}, see these installation guides: diff --git a/docs/getting-started/net-map-req.asciidoc b/docs/getting-started/net-map-req.asciidoc index a0a776707c..447b56ac86 100644 --- a/docs/getting-started/net-map-req.asciidoc +++ b/docs/getting-started/net-map-req.asciidoc @@ -11,12 +11,12 @@ Depending on your {kib} setup, to display and interact with data on the NOTE: To see source and destination connections lines on the map, you must configure `source.geo` and `destination.geo` ECS fields for your indices. -[float] +[discrete] [[prereq-perms]] === Permissions required To view the map, you need a role with at least `Read` {kibana-ref}/kibana-role-management.html#adding_kibana_privileges[privileges] for the `Maps` feature. -[float] +[discrete] [[kibana-index-pattern]] === Create {kib} data views @@ -27,7 +27,7 @@ To display map data, you must define a {kib} For example, to display data that is stored in indices matching the index pattern `servers-europe-*` on the map, you must use a {kib} data view whose index pattern matches `servers-europe-*`, such as `servers-*`. -[float] +[discrete] [[geoip-data]] === Add geoIP data @@ -111,7 +111,7 @@ autonomous system number (ASN) fields can be found https://github.com/elastic/ex <1> The value of this field must be the same as the ingest pipeline name in <> (`geoip-info` in this example). -[float] +[discrete] [[private-network]] === Map your internal network diff --git a/docs/getting-started/security-ui.asciidoc b/docs/getting-started/security-ui.asciidoc index 21c63b3cb6..48c5925277 100644 --- a/docs/getting-started/security-ui.asciidoc +++ b/docs/getting-started/security-ui.asciidoc @@ -18,7 +18,7 @@ image::images/search-bar.png[] * To save the current KQL query and any applied filters, select *Saved query menu* (image:images/saved-query-menu-icon.png[Saved query menu icon,18,18]), enter a name for the saved query, and select *Save saved query*. [[navigation-menu-overview]] -[float] +[discrete] == Navigation menu The navigation menu contains direct links and expandable groups, identified by the group icon (image:images/group-icon.png[Group icon,16,16]). @@ -33,7 +33,7 @@ The navigation menu contains direct links and expandable groups, identified by t image::images/nav-overview.gif[Overview of the navigation menu] [[visualization-actions]] -[float] +[discrete] == Visualization actions Many {elastic-sec} histograms, graphs, and tables display an *Inspect* button (image:images/inspect-icon.png[Inspect icon,19,19]) when you hover over them. Click to examine the {es} queries used to retrieve data throughout the app. @@ -46,7 +46,7 @@ Other visualizations display an options menu (image:images/three-dot-icon.png[Th [role="screenshot"] image::images/viz-options-menu-open.png[Options menu opened,85%] -[float] +[discrete] [[inline-actions]] == Inline actions for fields and values @@ -69,12 +69,12 @@ Inline actions include the following (some actions are unavailable in some conte * *Show top _x_*: Display a pop-up window that shows the selected field's top events or detection alerts. * *Copy to Clipboard*: Copy the selected field-value pair to paste elsewhere. -[float] +[discrete] == {security-app} pages The {security-app} contains the following pages that enable analysts to view, analyze, and manage security data. -[float] +[discrete] === Dashboards Expand this section to access the Overview, Detection & Response, Kubernetes, Cloud Security Posture, Cloud Native Vulnerability Management, Entity Analytics, and Data Quality dashboards, which provide interactive visualizations that summarize your data. You can also create and view custom dashboards. Refer to <> for more information. @@ -82,7 +82,7 @@ Expand this section to access the Overview, Detection & Response, Kubernetes, Cl [role="screenshot"] image::images/dashboards-landing-page.png[The dashboards landing page, 75%] -[float] +[discrete] === Rules Expand this section to access the following pages: @@ -107,7 +107,7 @@ image::images/rule-exceptions-page.png[Shared Exception Lists page] [role="screenshot"] image::images/rules-coverage.png[MITRE ATT&CK® coverage page] -[float] +[discrete] === Alerts View and manage alerts to monitor activity within your network. Refer to <> for more information. @@ -115,7 +115,7 @@ View and manage alerts to monitor activity within your network. Refer to <>, <>, or <>. @@ -123,7 +123,7 @@ Identify misconfigurations and vulnerabilities in your cloud infrastructure. For [role="screenshot"] image::cloud-native-security/images/findings-page.png[Findings page] -[float] +[discrete] === Cases Open and track security issues. Refer to <> to learn more. @@ -131,7 +131,7 @@ Open and track security issues. Refer to <> to learn more. [role="screenshot"] image::cases/images/cases-home-page.png[Cases page] -[float] +[discrete] === Timelines Investigate alerts and complex threats -- such as lateral movement -- in your network. Timelines are interactive and allow you to share your findings with other team members. Refer to <> to learn more. @@ -141,7 +141,7 @@ image::images/timeline-ui.png[Timeline page] TIP: Click the *Timeline* button at the bottom of the {security-app} to start an investigation. -[float] +[discrete] === Intelligence The Intelligence section contains the Indicators page, which collects data from enabled threat intelligence feeds and provides a centralized view of indicators of compromise (IoCs). Refer to <> to learn more. @@ -149,7 +149,7 @@ The Intelligence section contains the Indicators page, which collects data from [role="screenshot"] image::images/indicators-table.png[Indicators page] -[float] +[discrete] === Explore Expand this section to access the following pages: @@ -169,12 +169,12 @@ image::images/network-ui.png[Network page] [role="screenshot"] image::images/users/users-page.png[Users page] -[float] +[discrete] === Get started Quickly add security integrations that can ingest data and monitor your hosts. -[float] +[discrete] === Manage Expand this section to access and manage additional security features: diff --git a/docs/getting-started/siem-ui.asciidoc b/docs/getting-started/siem-ui.asciidoc index 6e0657d484..dc88a42cd7 100644 --- a/docs/getting-started/siem-ui.asciidoc +++ b/docs/getting-started/siem-ui.asciidoc @@ -41,7 +41,7 @@ and `apm-*-transaction*`. You can change the default glob patterns in {kib} -> Management -> Advanced Settings -> `siem:defaultIndex`. -[float] +[discrete] [[siem-overview-ui]] == Overview page @@ -99,7 +99,7 @@ View event and host counts specific to Elastic data shippers and apps, such as * image::events-count.png[] -[float] +[discrete] [[hosts-ui]] == Hosts page @@ -133,7 +133,7 @@ Host ID, First Seen timestamp, Last Seen timestamp, IP and MAC addresses, OS, versions, machine type, and so forth. Additionally, it contains all the widgets and tabs relevant for the selected host. -[float] +[discrete] [[network-ui]] == Network page @@ -205,7 +205,7 @@ corner of the map. <> describes how to add map data and set up interactions. -[float] +[discrete] [[detection-engine-ui]] == Detections page @@ -222,7 +222,7 @@ according to various attributes, including `Risk scores`, `Severities`, and `Top event categories`. The `All signals` table helps with investigations, allowing you to search, filter, and aggregate all {elastic-sec} signals. -[float] +[discrete] [[cases-ui]] == Cases page @@ -232,7 +232,7 @@ The Cases page is used to open and track security issues directly in the [role="screenshot"] image::images/cases-ui-home.png[] -[float] +[discrete] == Timelines Use Timeline as your workspace for alert investigations or threat hunting. @@ -341,7 +341,7 @@ might need to: NOTE: To see source and destination connections lines on the map, you must configure `source.geo` and `destination.geo` ECS fields for your indices. -[float] +[discrete] [[kibana-index-pattern]] === Create {kib} data views @@ -352,7 +352,7 @@ To display map data, you must define a {kib} For example, to display data that is stored using the index pattern `servers-europe-*` on the map, you must use a {kib} data view whose index pattern matches `servers-europe-*`, such as `servers-*`. -[float] +[discrete] [[geoip-data]] === Add geoIP data @@ -437,7 +437,7 @@ autonomous system number (ASN) fields can be found https://github.com/elastic/ex <1> The value of this field must be the same as the ingest pipeline name in <> (`geoip-info` in this example). -[float] +[discrete] [[private-network]] === Map your internal network diff --git a/docs/getting-started/threat-intel-integrations.asciidoc b/docs/getting-started/threat-intel-integrations.asciidoc index 308d7034a9..3ca3022a97 100644 --- a/docs/getting-started/threat-intel-integrations.asciidoc +++ b/docs/getting-started/threat-intel-integrations.asciidoc @@ -17,7 +17,7 @@ There are a few scenarios when data won't display in the Threat Intelligence vie - If you've chosen a time range that doesn't contain threat indicator event data, you are prompted to choose a different range. Use the date and time picker in the {security-app} or Kibana to select a new range to analyze. - If the {agent} or {filebeat} agent hasn't ingested Threat Intel module data yet, the threat indicator event counts won't load. You can wait for data to be ingested or reach out to your administrator for help resolving this. -[float] +[discrete] [[agent-ti-integration]] == Add an {agent} integration @@ -31,7 +31,7 @@ If you know the name of {agent} integration you want to install, you can search . Select an {agent} integration, then complete the installation steps. . Return to the Threat Intelligence view on the Overview dashboard. If indicator data isn't displaying, refresh the page or refer to these <>. -[float] +[discrete] [[ti-mod-integration]] == Add a {filebeat} Threat Intel module integration @@ -44,7 +44,7 @@ NOTE: For more information about enabling available threat intelligence filesets .. If you're using a previous version of Filebeat _and_ a current one, differentiate between the threat intelligence indices by using unique index pattern names. For example, if you’re using {filebeat} version 7.0.0 and 8.0.0, update the setting to `logs-ti*`,`filebeat-7*`,`filebeat-8*`. . Return to the Threat Intelligence view on the Overview dashboard. Refresh the page if indicator data isn't displaying. -[float] +[discrete] [[custom-ti-integration]] == Add a custom integration diff --git a/docs/osquery/invest-guide-run-osquery.asciidoc b/docs/osquery/invest-guide-run-osquery.asciidoc index 2419a9e489..713778680a 100644 --- a/docs/osquery/invest-guide-run-osquery.asciidoc +++ b/docs/osquery/invest-guide-run-osquery.asciidoc @@ -13,7 +13,7 @@ Detection rule investigation guides suggest steps for triaging, analyzing, and r [role="screenshot"] image::images/osquery-investigation-guide.png[Shows a live query in an investigation guide] -[float] +[discrete] [[add-live-queries-ig]] === Add live queries to an investigation guide @@ -25,7 +25,7 @@ NOTE: You can only add Osquery to investigation guides for custom rules because .. Add a descriptive label for the query; for example, `Search for executables`. .. Select a saved query or enter a new one. + -TIP: Use <> to dynamically add existing alert data to your query. +TIP: Use <> to dynamically add existing alert data to your query. .. Expand the **Advanced** section to set a timeout period for the query, and view or set {kibana-ref}/osquery.html#osquery-map-fields[mapped ECS fields] included in the results from the live query (optional). + @@ -35,7 +35,7 @@ NOTE: Overwriting the query's default timeout period allows you to support queri image::images/setup-osquery-investigation-guide.png[width=70%][height=70%][Shows results from running a query from an investigation guide] . Click *Save changes* to add the query to the rule's investigation guide. -[float] +[discrete] [[run-live-queries-ig]] === Run live queries from an investigation guide diff --git a/docs/osquery/osquery-placeholder-fields.asciidoc b/docs/osquery/osquery-placeholder-fields.asciidoc index ea1c7ea117..4ea3db9830 100644 --- a/docs/osquery/osquery-placeholder-fields.asciidoc +++ b/docs/osquery/osquery-placeholder-fields.asciidoc @@ -1,29 +1,29 @@ [[osquery-placeholder-fields]] -== Use placeholder fields in Osquery queries +== Use placeholder fields in Osquery queries -Instead of hard-coding alert and event values into Osquery queries, you can use placeholder fields to dynamically pass this data into queries. Placeholder fields function like parameters. You can use placeholder fields to build flexible and reusable queries. +Instead of hard-coding alert and event values into Osquery queries, you can use placeholder fields to dynamically pass this data into queries. Placeholder fields function like parameters. You can use placeholder fields to build flexible and reusable queries. Placeholder fields work in single queries or query packs. They're also supported in the following features: * <> * <> + -* <> +* <> -[float] +[discrete] [[placeholder-field-syntax]] === Placeholder field syntax and requirements -Placeholder fields use http://mustache.github.io/[mustache syntax] and must be wrapped in double curly brackets (`{{example.field}}`). You can use any field within an event or alert document as a placeholder field. +Placeholder fields use http://mustache.github.io/[mustache syntax] and must be wrapped in double curly brackets (`{{example.field}}`). You can use any field within an event or alert document as a placeholder field. -Queries with placeholder fields can only run against alerts or events. Otherwise, they will lack the necessary values and the query status will be `error`. +Queries with placeholder fields can only run against alerts or events. Otherwise, they will lack the necessary values and the query status will be `error`. -[float] +[discrete] [[placeholder-field-example]] ==== Example query with a placeholder field -The following query uses the `{{host.name}}` placeholder field: +The following query uses the `{{host.name}}` placeholder field: `SELECT * FROM os_version WHERE name = `{{host.os.name}}`` -When you run the query, the value that's stored in the alert or event's `host.name` field will be transferred to the `{{host.os.name}}` placeholder field. \ No newline at end of file +When you run the query, the value that's stored in the alert or event's `host.name` field will be transferred to the `{{host.os.name}}` placeholder field. \ No newline at end of file diff --git a/docs/osquery/osquery-response-action.asciidoc b/docs/osquery/osquery-response-action.asciidoc index 4f5fac0bff..830cc2ec94 100644 --- a/docs/osquery/osquery-response-action.asciidoc +++ b/docs/osquery/osquery-response-action.asciidoc @@ -2,7 +2,7 @@ == Add Osquery Response Actions preview::[] -:frontmatter-description: Osquery Response Actions allow you to add live queries to custom query rules so you can automatically collect data on systems the rules are monitoring. +:frontmatter-description: Osquery Response Actions allow you to add live queries to custom query rules so you can automatically collect data on systems the rules are monitoring. :frontmatter-tags-products: [security] :frontmatter-tags-content-type: [how-to] :frontmatter-tags-user-goals: [manage] @@ -22,7 +22,7 @@ Osquery Response Actions allow you to add live queries to custom query rules so [role="screenshot"] image::images/available-response-actions-osquery.png[The Osquery response action] -[float] +[discrete] [[add-osquery-response-action]] === Add Osquery Response Actions to rules @@ -31,14 +31,14 @@ You can add Osquery Response Actions to new or existing custom query rules. Quer . Choose one of the following: ** *New rule*: When you are on the last step of <> creation, go to the Response Actions section and click the *Osquery* icon. ** *Existing rule*: Edit the rule's settings, then go to the *Actions* tab. In the tab, click the *Osquery* icon under the Response Actions section. -+ -NOTE: If the rule's investigation guide is using an Osquery query, you'll be asked if you want to add the query as an Osquery Response Action. Click *Add* to add the investigation guide's query to the rule's Osquery Response Action. ++ +NOTE: If the rule's investigation guide is using an Osquery query, you'll be asked if you want to add the query as an Osquery Response Action. Click *Add* to add the investigation guide's query to the rule's Osquery Response Action. . Specify whether you want to set up a single live query or a pack: -** *Query*: Select a saved query or enter a new one. After you enter the query, you can expand the **Advanced** section to set a timeout period for the query, and view or set {kibana-ref}/osquery.html#osquery-map-fields[mapped ECS fields] included in the results from the live query (optional). +** *Query*: Select a saved query or enter a new one. After you enter the query, you can expand the **Advanced** section to set a timeout period for the query, and view or set {kibana-ref}/osquery.html#osquery-map-fields[mapped ECS fields] included in the results from the live query (optional). + NOTE: Overwriting the query's default timeout period allows you to support queries that take longer to run. The default and minimum supported value for the **Timeout** field is `60`. The maximum supported value is `900`. + -TIP: You can use <> to dynamically add alert data to your query. +TIP: You can use <> to dynamically add alert data to your query. ** *Pack*: Select from available query packs. After you select a pack, all of the queries in the pack are displayed. + @@ -51,7 +51,7 @@ image::images/setup-single-query.png[Shows how to set up a single query] . Click the *Osquery* icon to add more live queries (optional). . Click **Create & enable rule** (for a new rule) or **Save changes** (for existing rules) to finish adding the queries. -[float] +[discrete] [[edit-osquery-response-action]] === Edit Osquery Response Actions @@ -63,7 +63,7 @@ IMPORTANT: If you edited a saved query or query pack that an Osquery Response Ac . Modify the settings for Osquery Response Actions you've added. . Click *Save changes*. -[float] +[discrete] [[find-osquery-response-action-results]] === Find query results diff --git a/docs/osquery/view-osquery-results.asciidoc b/docs/osquery/view-osquery-results.asciidoc index a49ca67906..a38e6f84ac 100644 --- a/docs/osquery/view-osquery-results.asciidoc +++ b/docs/osquery/view-osquery-results.asciidoc @@ -2,12 +2,12 @@ == Examine Osquery results Osquery provides relevant, timely data that you can use to better understand and monitor your environment. When you run queries, results are indexed and displayed the Results table, which you can filter, sort, and interact with. -[float] +[discrete] [[osquery-result-types]] === Results table The Results table displays results from single queries and query packs. -[float] +[discrete] [[review-single-osquery-results]] ==== Single query results @@ -16,7 +16,7 @@ Results for single queries appear on the *Results* tab. When you run a query, th [role="screenshot"] image::images/single-query-results.png[width=80%][height=80%][Shows query results] -[float] +[discrete] [[review-pack-osquery-results]] ==== Query pack results @@ -25,7 +25,7 @@ Results for each query in the pack appear in the *Results* tab. Click the expand [role="screenshot"] image::images/pack-query-results.png[width=80%][height=80%][Shows query results] -[float] +[discrete] [[investigate-osquery-results]] === Investigate query results @@ -49,5 +49,5 @@ If you add the results to a _new_ case, you are prompted to specify the solution If you add the results to an _existing case_, you can select from cases that were created in any solution ({elastic-sec}, {observability}, and {stack}). ===== -* Click the view details icon (image:images/view-osquery-details.png[View details icon,20,20]) to examine the query ID and statement. +* Click the view details icon (image:images/view-osquery-details.png[View details icon,20,20]) to examine the query ID and statement. * View more information about the request, such as failures, by opening the *Status* tab. diff --git a/docs/post-upgrade/post-upgrade-deprecated-sn-connector.asciidoc b/docs/post-upgrade/post-upgrade-deprecated-sn-connector.asciidoc index 812cad91e3..3d25baf37b 100644 --- a/docs/post-upgrade/post-upgrade-deprecated-sn-connector.asciidoc +++ b/docs/post-upgrade/post-upgrade-deprecated-sn-connector.asciidoc @@ -8,7 +8,7 @@ image::images/cases-deprecated-sn-connector.png[Shows deprecated connectors] IMPORTANT: Deprecated connectors will continue to function with the rules they were added to and can be assigned new rules. Deprecated connectors will also continue to function with the cases that they were assigned to, but cannot be assigned to new ones. It is strongly recommended to update deprecated connectors or create new ones to ensure you have access to connector enhancements, such as updating incidents. -[float] +[discrete] [[pre-req-deprecated-sn-connector]] === Prerequisites Before creating a new {sn} ITSM or SecOps connector, you must complete the following within your {sn} instance: @@ -47,7 +47,7 @@ A CORS rule is required for communication between Elastic and {sn}. To create a . Go to the *HTTP methods* tab and select *GET*. . Click *Submit* to create the rule. -[float] +[discrete] [[pre-req-update-deprecated-sn-connector]] === Update a deprecated {sn} connector diff --git a/docs/post-upgrade/post-upgrade-req-cti-alerts.asciidoc b/docs/post-upgrade/post-upgrade-req-cti-alerts.asciidoc index edbd774899..01b7d041a3 100644 --- a/docs/post-upgrade/post-upgrade-req-cti-alerts.asciidoc +++ b/docs/post-upgrade/post-upgrade-req-cti-alerts.asciidoc @@ -12,7 +12,7 @@ To migrate detection alerts: . Migrate old alerts using the <>. . <>. -[float] +[discrete] [[deactivate-detect-rules]] === Deactivate all detection rules @@ -22,7 +22,7 @@ To deactivate all detection rules: . Click the *Select all _x_ rules* option above the rules table. . Click *Bulk actions* -> *Disable*. -[float] +[discrete] [[reactivate-detect-rules]] === Reactivate all detection rules diff --git a/docs/reference/field-ref.asciidoc b/docs/reference/field-ref.asciidoc index eb95040920..41cdc49b07 100644 --- a/docs/reference/field-ref.asciidoc +++ b/docs/reference/field-ref.asciidoc @@ -9,7 +9,7 @@ If you plan to use a custom implementation to map your data to ECS fields (see { For detailed information about which ECS fields can appear in documents generated by {elastic-endpoint}, refer to the https://github.com/elastic/endpoint-package/tree/main/custom_documentation/doc/endpoint[Endpoint event documentation]. -[float] +[discrete] [[siem-always-required-fields]] == Always required fields {elastic-sec} requires all event and threat intelligence data to be normalized to ECS. For proper operation, all data must contain the following ECS fields: @@ -20,7 +20,7 @@ For detailed information about which ECS fields can appear in documents generate * `event.category` * `event.type` -[float] +[discrete] [[siem-required-process-event-fields]] == Fields required for process events {elastic-sec} relies on these fields to analyze and display process data: @@ -28,7 +28,7 @@ For detailed information about which ECS fields can appear in documents generate * `process.name` * `process.pid` -[float] +[discrete] [[siem-host-fields]] == Fields required for host events {elastic-sec} relies on these fields to analyze and display host data: @@ -80,7 +80,7 @@ For detailed information about which ECS fields can appear in documents generate * `user.id` * `user.name` -[float] +[discrete] [[siem-required-network-fields]] == Fields required for network events {elastic-sec} relies on these fields to analyze and display network data: @@ -143,7 +143,7 @@ events have `dns.question.type` fields with values of `PTR`. * `tls.server.not_after` * `tls.server.subject` -[float] +[discrete] == Fields required for events and external alerts {elastic-sec} relies on this field to analyze and display event and external alert data: diff --git a/docs/serverless/AI-for-security/ai-assistant-alert-triage.asciidoc b/docs/serverless/AI-for-security/ai-assistant-alert-triage.asciidoc new file mode 100644 index 0000000000..1b725a6a41 --- /dev/null +++ b/docs/serverless/AI-for-security/ai-assistant-alert-triage.asciidoc @@ -0,0 +1,37 @@ +[[triage-alerts-with-elastic-ai-assistant]] += Triage alerts + +:description: Elastic AI Assistant can help you enhance and streamline your alert triage workflows. +:keywords: security, overview, get-started + +preview:[] + +Elastic AI Assistant can help you enhance and streamline your alert triage workflows. + +AI Assistant can help you interpret an alert and understand its context. When you view an alert in {elastic-sec}, details such as related documents, hosts, and users appear alongside a synopsis of the events that triggered the alert. This data provides a starting point for understanding a potential threat. AI Assistant can answer questions about this data and offer insights and actionable recommendations to remediate the issue. + +[discrete] +[[Use AI Assistant to triage an alert]] +== Use AI Assistant to triage an alert + +. Choose an alert to investigate, then click the **View details** button from the Alerts table. +. On the details flyout, click **Chat** to launch AI Assistant. Data related to the selected alert is automatically added to the prompt. +. Click **Alert (from summary)** to view which alert fields will be shared with AI Assistant. (For more information about selecting which fields to send, and to learn about anonymizing your data, refer to <>.) +. (Optional) Click a quick prompt to use it as a starting point for your query, for example, **Alert summarization**. Customize the prompt and add detail to improve AI Assistant's response. +Once you’ve submitted your query, the AI Assistant will process the information and provide a detailed response. Depending on your prompt and which alert data you included, its response can include a thorough analysis of the alert that highlights key elements such as the nature of the potential threat, potential impact, and suggested response actions. +. (Optional) Ask follow-up questions, provide additional information for further analysis, and request clarification. The response is not a static report. + +[discrete] +[[Generate triage reports]] +== Generate triage reports + +Elastic AI Assistant can streamline the documentation and report generation process by providing clear records of security incidents, their scope and impact, and your remediation efforts. You can use AI Assistant to create summaries or reports for stakeholders that include key event details, findings, and diagrams. Once the AI Assistant has finished analyzing one or more alerts, you can generate reports by using prompts such as: + +* “Generate a detailed report about this incident, including timeline, impact analysis, and response actions. Also, include a diagram of events.” +* “Generate a summary of this incident/alert and include diagrams of events.” +* “Provide more details on the mitigation strategies used.” + +After you review the report, click **Add to existing case** at the top of AI Assistant's response. This allows you to save a record of the report and make it available to your team. + +[role="screenshot"] +image::images/ai-assistant-alert-triage/ai-triage-add-to-case.png[An AI Assistant dialogue with the add to existing case button highlighted] diff --git a/docs/serverless/AI-for-security/ai-assistant-esql-queries.asciidoc b/docs/serverless/AI-for-security/ai-assistant-esql-queries.asciidoc new file mode 100644 index 0000000000..590077db2e --- /dev/null +++ b/docs/serverless/AI-for-security/ai-assistant-esql-queries.asciidoc @@ -0,0 +1,19 @@ +[[ai-assistant-esql-queries]] += Generate, customize, and learn about {esql} queries + +:description: AI Assistant has specialized {esql} capabilities. +:keywords: security, overview, get-started + +Elastic AI Assistant can help you learn about and leverage the Elasticsearch Query Language {(esql}). + +With AI Assistant's <> enabled, AI Assistant benefits from specialized training data that enables it to answer questions related to {esql} at an expert level. + +AI Assistant can help with {esql} in many ways, including: + +* **Education and training**: AI Assistant can serve as a powerful {esql} learning tool. Ask it for examples, explanations of complex queries, and best practices. +* **Writing new queries**: Prompt AI Assistant to provide a query that accomplishes a particular task, and it will generate a query matching your description. For example: "Write a query to identify documents with `curl.exe` usage and calculate the sum of `destination.bytes`" or "What query would return all user logins to [a host] in the last six hours?" +* **Providing feedback to optimize existing queries**: Send AI Assistant a query you want to work on and ask it for improvements, refactoring, a general assessment, or to optimize the query's performance with large data sets. +* **Customizing queries for your environment**: Since each environment is unique, you may need to customize queries that you used in other contexts. AI Assistant can suggest necessary modifications based on contextual information you provide. +* **Troubleshooting**: Having trouble with a query or getting unexpected results? Ask AI Assistant to help you troubleshoot. + +In these ways and others, AI Assistant can enable you to make use of {esql}'s advanced search capabilities to accomplish goals across {elastic-sec}. diff --git a/docs/serverless/AI-for-security/ai-assistant.asciidoc b/docs/serverless/AI-for-security/ai-assistant.asciidoc new file mode 100644 index 0000000000..dc6e46b3a3 --- /dev/null +++ b/docs/serverless/AI-for-security/ai-assistant.asciidoc @@ -0,0 +1,198 @@ +[[security-ai-assistant]] += Elastic AI Assistant + +:description: Elastic AI Assistant is a generative AI open-code chat assistant. +:keywords: security, overview, get-started + +preview:[] + +The Elastic AI Assistant utilizes generative AI to bolster your cybersecurity operations team. It allows users to interact with {elastic-sec} for tasks such as alert investigation, incident response, and query generation or conversion using natural language and much more. + +[role="screenshot"] +image::images/ai-assistant/assistant-basic-view.png[Image of AI Assistant chat window] + +[IMPORTANT] +==== +Elastic AI Assistant is designed to enhance your analysis with smart dialogues. Its capabilities are still developing. Users should exercise caution as the quality of its responses might vary. Your insights and feedback will help us improve this feature. Always cross-verify AI-generated advice for accuracy. +==== + +.Requirements +[NOTE] +==== +* This feature requires the Security Analytics Complete https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature]. +* You need an account with a third-party generative AI provider, which AI Assistant uses to generate responses. Supported providers are OpenAI, Azure OpenAI Service, and Amazon Bedrock. +==== + +[discrete] +[[data-information]] +== Your data and AI Assistant + +Elastic does not store or examine prompts or results used by AI Assistant, or use this data for model training. This includes anything you send the model, such as alert or event data, detection rule configurations, queries, and prompts. However, any data you provide to AI Assistant will be processed by the third-party large language model (LLM) provider you connected as part of AI Assistant setup. + +Elastic does not control third-party tools, and assumes no responsibility or liability for their content, operation, or use, nor for any loss or damage that may arise from your using such tools. Please exercise caution when using AI tools with personal, sensitive, or confidential information. Any data you submit may be used by the provider for AI training or other purposes. There is no guarantee that the provider will keep any information you provide secure or confidential. You should familiarize yourself with the privacy practices and terms of use of any generative AI tools prior to use. + +[NOTE] +==== +Elastic can automatically anonymize event data that you provide to AI Assistant as context. To learn more, refer to <>. +==== + +[discrete] +[[set-up-ai-assistant]] +== Set up AI Assistant + +You must create a generative AI connector before you can use AI Assistant. AI Assistant can connect to multiple large language model (LLM) providers so you can select the best model for your needs. To set up a connector, refer to <>. + +.Recommended models +[NOTE] +==== +While AI Assistant is compatible with many different models, refer to the <> to select models that perform well with your desired use cases. +==== + +[discrete] +[[start-chatting]] +== Start chatting + +To open AI Assistant, select the **AI Assistant** button in the top toolbar from anywhere in the {security-app}. You can also use the keyboard shortcut **Cmd + ;** (or **Ctrl + ;** on Windows). + +[role="screenshot"] +image::images/ai-assistant/-assistant-ai-assistant-button.png[AI Assistant button] + +This opens the **Welcome** chat interface, where you can ask general questions about {elastic-sec}. + +You can also chat with AI Assistant from several particular pages in {elastic-sec} where you can easily send context-specific data and prompts to AI Assistant. + +* <> or Event details flyout: Click **Chat** while viewing the details of an alert or event. +* <>: Use AI Assistant to help create or correct rule queries. +* <>: Select the **Incompatible fields** tab, then click **Chat**. (This is only available for fields marked red, indicating they’re incompatible). +* <>: Select the **Security Assistant** tab. + +[NOTE] +==== +Each user's chat history and custom quick prompts are automatically saved, so you can leave {elastic-sec} and return to pick up a conversation later. Chat history is saved in the `.kibana-elastic-ai-assistant-conversations` data stream. +==== + +[discrete] +[[interact-with-assistant]] +== Interact with AI Assistant + +Use these features to adjust and act on your conversations with AI Assistant: + +* Select a _system prompt_ at the beginning of a conversation to establish how detailed and technical you want AI Assistant's answers to be. ++ +[role="screenshot"] +image:images/ai-assistant/-assistant-system-prompt.gif[The system prompt drop-down menu] ++ +System prompts provide context to the model, informing its response. To create a custom system prompt, open the system prompts dropdown menu and click **+ Add new system prompt...**. +* Select a _quick prompt_ at the bottom of the chat window to get help writing a prompt for a specific purpose, such as summarizing an alert or converting a query from a legacy SIEM to {elastic-sec}. ++ +[role="screenshot"] +image:images/ai-assistant/-assistant-quick-prompts.png[Quick prompts highlighted below a conversation] ++ +Quick prompt availability varies based on context — for example, the **Alert summarization** quick prompt appears when you open AI Assistant while viewing an alert. To customize existing quick prompts and create new ones, click **Add Quick prompt**. +* In an active conversation, you can use the inline actions that appear on messages to incorporate AI Assistant's responses into your workflows: ++ +** **Add note to timeline** (image:images/icons/editorComment.svg[Comment]): Add the selected text to your currently active Timeline as a note. +** **Add to existing case** (image:images/icons/addDataApp.svg[Add data]): Add a comment to an existing case using the selected text. +** **Copy to clipboard** (image:images/icons/copyClipboard.svg[Copy to clipboard]): Copy the text to clipboard to paste elsewhere. Also helpful for resubmitting a previous prompt. +** **Add to timeline** (image:images/icons/timeline.svg[Timeline]): Add a filter or query to Timeline using the text. This button appears for particular queries in AI Assistant's responses. ++ +Be sure to specify which language you'd like AI Assistant to use when writing a query. For example: "Can you generate an Event Query Language query to find four failed logins followed by a successful login?" + +[TIP] +==== +AI Assistant can remember particular information you tell it to remember. For example, you could tell it: "When anwering any question about srv-win-s1-rsa or an alert that references it, mention that this host is in the New York data center". This will cause it to remember the detail you highlighted. +==== + +[discrete] +[[configure-ai-assistant]] +== Configure AI Assistant + +The **Settings** menu (image:images/icons/controlsVertical.svg[EQL settings]) allows you to configure default conversations, quick prompts, system prompts, and data anonymization. + +[role="screenshot"] +image::images/ai-assistant/-assistant-assistant-settings-menu.png[AI Assistant's settings menu, open to the Conversations tab] + +The **Settings** menu has the following tabs: + +* **Conversations:** When you open AI Assistant from certain pages, such as Timeline or Alerts, it defaults to the relevant conversation type. Choose the system prompt for each conversation type, the connector, and model (if applicable). The **Streaming** setting controls whether AI Assistant's responses appear word-by-word (streamed), or as a complete block of text. Streaming is currently only available for OpenAI models. +* **Quick Prompts:** Modify existing quick prompts or create new ones. To create a new quick prompt, type a unique name in the **Name** field, then press **enter**. Under **Prompt**, enter or update the quick prompt's text. Under **Contexts**, select where the quick prompt should appear. +* **System Prompts:** Edit existing system prompts or create new ones. To create a new system prompt, type a unique name in the **Name** field, then press **enter**. Under **Prompt**, enter or update the system prompt's text. ++ +[NOTE] +==== +To delete a custom prompt, open the **Name** drop-down menu, hover over the prompt you want to delete, and click the _X_ that appears. You cannot delete the default prompts. +==== +* **Anonymization:** Select fields to include as plaintext, to obfuscate, and to not send when you provide events to AI Assistant as context. +* **Knowledge base:** Provide additional context to AI Assistant so it can answer questions about {esql} and alerts in your environment. + +[discrete] +[[ai-assistant-anonymization]] +=== Anonymization + +The **Anonymization** tab of the AI Assistant settings menu allows you to define default data anonymization behavior for events you send to AI Assistant. Fields with **Allowed** toggled on are included in events provided to AI Assistant. **Allowed** fields with **Anonymized** set to **Yes** are included, but with their values obfuscated. + +[role="screenshot"] +image::images/ai-assistant/-assistant-assistant-anonymization-menu.png[AI Assistant's settings menu, open to the Anonymization tab] + +The **Show anonymized** toggle controls whether you see the obfuscated or plaintext versions of the fields you sent to AI Assistant. It doesn't control what gets obfuscated — that's determined by the anonymization settings. It also doesn't affect how event fields appear _before_ being sent to AI Assistant. Instead, it controls how fields that were already sent and obfuscated appear to you. + +When you include a particular event as context, such as an alert from the Alerts page, you can adjust anonymization behavior for the specific event. Be sure the anonymization behavior meets your specifications before sending a message with the event attached. + +[discrete] +[[ai-assistant-knowledge-base]] +=== Knowlege base + +beta::[] + +The **Knowledge base** tab of the AI Assistant settings menu allows you to enable AI Assistant to answer questions about the Elastic Search Query Language {(esql}), and about alerts in your environment. To use it, you must <>, + +[discrete] +[[ai-assistant-knowledge-base-for-esql]] +=== Knowledge base for {esql} + +[IMPORTANT] +==== +{esql} queries generated by AI Assistant might require additional validation. To ensure they're correct, refer to the {ref}/esql-language.html[{esql} documentation]. +==== + +When this feature is enabled, AI Assistant can help you write an {esql} query for a particular use case, or answer general questions about {esql} syntax and usage. To enable AI Assistant to answer questions about {esql}: + +* Turn on the knowledge base by clicking **Setup**. If the **Setup** button doesn't appear, knowledge base is already enabled. +* Click **Save**. The knowledge base is now active. A quick prompt for {esql} queries becomes available, which provides a good starting point for your {esql} conversations and questions. + +[NOTE] +==== +AI Assistant's knowledge base gets additional context from {ml-docs}/ml-nlp-elser.html#download-deploy-elser[Elastic Learned Sparse EncodeR (ELSER)]. +==== + +[discrete] +[[ai-assistant-knowledge-base-for-alerts]] +=== Knowledge base for alerts + +When this feature is enabled, AI Assistant will receive multiple alerts as context for each of your prompts. It will receive alerts from the last 24 hours that have a status of `open` or `acknowledged`, ordered first by risk score, then by recency. Building block alerts are excluded. This enables it to answer questions about multiple alerts in your environment, rather than just the individual alerts you choose to include as context. + +To enable RAG for alerts: + +* Turn on the knowledge base by clicking **Setup**. If the **Setup** button doesn't appear, knowledge base is already enabled. +* Use the slider to select the number of alerts to send to AI Assistant. Click **Save**. + +[role="screenshot"] +image::images/ai-assistant/assistant-kb-menu.png[AI Assistant's settings menu, open to the Knowledge base tab] + +[NOTE] +==== +Including a large number of alerts may cause your request to exceed the maximum token length of your third-party generative AI provider. If this happens, try selecting a lower number of alerts to send. +==== + +[discrete] +[[ai-assistant-get-the-most-from-your-queries]] +=== Get the most from your queries + +Elastic AI Assistant helps you take full advantage of the Elastic Security platform to improve your security operations. Its ability to assist you depends on the specificity and detail of your questions. The more context and detail you provide, the more tailored and useful its responses will be. + +To maximize its usefulness, consider using more detailed prompts or asking for additional information. For instance, after asking for an ES|QL query example, you could ask a follow-up question like, “Could you give me some other examples?” You can also ask for clarification or further exposition, for example "Please provide comments explaining the query you just gave." + +In addition to practical advice, AI Assistant can offer conceptual advice, tips, and best practices for enhancing your security measures. You can ask it, for example: + +* “How do I set up a machine learning job in Elastic Security to detect anomalies in network traffic volume over time?” +* “I need to monitor for unusual file creation patterns that could indicate ransomware activity. How would I construct this query using EQL?” diff --git a/docs/serverless/AI-for-security/ai-for-security-landing-pg.asciidoc b/docs/serverless/AI-for-security/ai-for-security-landing-pg.asciidoc new file mode 100644 index 0000000000..7314fa4963 --- /dev/null +++ b/docs/serverless/AI-for-security/ai-for-security-landing-pg.asciidoc @@ -0,0 +1,7 @@ +[[ai-for-security]] += AI for security + +:description: Learn about Elastic's native AI security tools. +:keywords: serverless, security, overview, LLM, artificial intelligence + +You can use {elastic-sec}’s built-in AI tools to speed up your work and augment your team’s capabilities. The pages in this section describe <>, which answers questions and enhances your workflows throughout Elastic Security, and <>, which speeds up the triage process by finding patterns and identifying attacks spanning multiple alerts. diff --git a/docs/serverless/AI-for-security/ai-use-cases.asciidoc b/docs/serverless/AI-for-security/ai-use-cases.asciidoc new file mode 100644 index 0000000000..6fbefc8657 --- /dev/null +++ b/docs/serverless/AI-for-security/ai-use-cases.asciidoc @@ -0,0 +1,11 @@ +[[ai-use-cases]] += Use cases + +:description: Learn about use cases for AI in {elastic-sec}. +:keywords: security, overview, get-started + +The guides in this section describe use cases for AI Assistant and Attack discovery. Refer to them for examples of each tool's individual capabilities, and of what they can do together. + +* <> +* <> +* <> diff --git a/docs/serverless/AI-for-security/attack-discovery.asciidoc b/docs/serverless/AI-for-security/attack-discovery.asciidoc new file mode 100644 index 0000000000..cb79289be1 --- /dev/null +++ b/docs/serverless/AI-for-security/attack-discovery.asciidoc @@ -0,0 +1,100 @@ +[[attack-discovery]] += Attack discovery + +:description: Accelerate threat identification by triaging alerts with a large language model. +:keywords: serverless, security, overview, LLM, artificial intelligence + +preview:[] + +.Technical preview +[IMPORTANT] +==== +This feature is in technical preview. It may change in the future, and you should exercise caution when using it in production environments. Elastic will work to fix any issues, but features in technical preview are not subject to the support SLA of GA features. +==== + +Attack discovery leverages large language models (LLMs) to analyze alerts in your environment and identify threats. Each "discovery" represents a potential attack and describes relationships among multiple alerts to tell you which users and hosts are involved, how alerts correspond to the MITRE ATT&CK matrix, and which threat actor might be responsible. This can help make the most of each security analyst's time, fight alert fatigue, and reduce your mean time to respond. + +For a demo, refer to the following video. + +++++ + + +++++ + +This page describes: + +* <> +* <> +* <> + +[discrete] +[[generate-discoveries]] +== Generate discoveries + +When you access Attack discovery for the first time, you'll need to select an LLM connector before you can analyze alerts. Attack discovery uses the same LLM connectors as <>. To get started: + +. Click the **Attack discovery** page from {elastic-sec}'s navigation menu. +. Select an existing connector from the dropdown menu, or add a new one. + +.Recommended models +[NOTE] +==== +While Attack discovery is compatible with many different models, our testing found increased performance with Claude 3.5 Sonnet. In general, models with larger context windows are more effective for Attack discovery. +==== + +[role="screenshot"] +image::images/attack-discovery/attck-disc-select-model-empty-state.png[Attack discovery empty state] + +. Once you've selected a connector, click **Generate** to start the analysis. + +It may take from a few seconds up to several minutes to generate discoveries, depending on the number of alerts and the model you selected. + +[IMPORTANT] +==== +Attack discovery is in technical preview and will only analyze opened and acknowleged alerts from the past 24 hours. By default it analyzes up to 100 alerts within this timeframe, but you can expand this up to 500 by clicking the settings icon image:images/icons/gear.svg[Settings icon] next to the model selection menu and adjusting the **Alerts** slider. Note that sending more alerts than your chosen LLM can handle may result in an error. +==== + +[role="screenshot"] +image::images/attack-discovery/attck-disc-alerts-number-menu.png[AI Assistant knowledge base menu] + +[IMPORTANT] +==== +Attack discovery uses the same data anonymization settings as <>. To configure which alert fields are sent to the LLM and which of those fields are obfuscated, use the Elastic AI Assistant settings. Consider the privacy policies of third-party LLMs before sending them sensitive data. +==== + +Once the analysis is complete, any threats it identifies appear as discoveries. Click each one's title to expand or collapse it. Click **Generate** at any time to start the Attack discovery process again with the most current alerts. + +[discrete] +[[discovery-info]] +== What information does each discovery include? + +Each discovery includes the following information describing the potential threat, generated by the connected LLM: + +* A descriptive title and a summary of the potential threat. +* The number of associated alerts and which parts of the https://attack.mitre.org/[MITRE ATT&CK matrix] they correspond to. +* The implicated entities (users and hosts), and what suspicious activity was observed for each. + +[role="screenshot"] +image::images/attack-discovery/attack-discovery-full-card.png[Attack discovery detail view] + +[discrete] +[[workflows]] +== Incorporate discoveries with other workflows + +There are several ways you can incorporate discoveries into your {elastic-sec} workflows: + +* Click an entity's name to open the user or host details flyout and view more details that may be relevant to your investigation. +* Hover over an entity's name to either add the entity to Timeline (image:images/icons/timeline.svg[Timeline]) or copy its field name and value to the clipboard (image:images/icons/copyClipboard.svg[Copy to clipboard]). +* Click **Take action**, then select **Add to new case** or **Add to existing case** to add a discovery to a case. This makes it easy to share the information with your team and other stakeholders. +* Click **Investigate in timeline** to explore the discovery in Timeline. +* Click **View in AI Assistant** to attach the discovery to a conversation with AI Assistant. You can then ask follow up questions about the discovery or associated alerts. + +[role="screenshot"] +image::images/attack-discovery/add-discovery-to-conversation.gif[Attack discovery view in AI Assistant] diff --git a/docs/serverless/AI-for-security/connect-to-azure-openai.asciidoc b/docs/serverless/AI-for-security/connect-to-azure-openai.asciidoc new file mode 100644 index 0000000000..45703c60d1 --- /dev/null +++ b/docs/serverless/AI-for-security/connect-to-azure-openai.asciidoc @@ -0,0 +1,121 @@ +[[connect-to-azure-openai]] += Connect to Azure OpenAI + +:description: Set up an Azure OpenAI LLM connector. +:keywords: security, overview, get-started + +[discrete] +[[connect-to-azure-openai-connect-to-azure-openai]] += Connect to Azure OpenAI + +This page provides step-by-step instructions for setting up an Azure OpenAI connector for the first time. This connector type enables you to leverage large language models (LLMs) within {kib}. You'll first need to configure Azure, then configure the connector in {kib}. + +[discrete] +[[connect-to-azure-openai-configure-azure]] +== Configure Azure + +[discrete] +[[connect-to-azure-openai-configure-a-deployment]] +=== Configure a deployment + +First, set up an Azure OpenAI deployment: + +. Log in to the Azure console and search for Azure OpenAI. +. In **Azure AI services**, select **Create**. +. For the **Project Details**, select your subscription and resource group. If you don't have a resource group, select **Create new** to make one. +. For **Instance Details**, select the desired region and specify a name, such as `example-deployment-openai`. +. Select the **Standard** pricing tier, then click **Next**. +. Configure your network settings, click **Next**, optionally add tags, then click **Next**. +. Review your deployment settings, then click **Create**. When complete, select **Go to resource**. + +The following video demonstrates these steps. + +++++ + +++++ + +[discrete] +[[connect-to-azure-openai-configure-keys]] +=== Configure keys + +Next, create access keys for the deployment: + +. From within your Azure OpenAI deployment, select **Click here to manage keys**. +. Store your keys in a secure location. + +The following video demonstrates these steps. + +++++ + +++++ + +[discrete] +[[connect-to-azure-openai-configure-a-model]] +=== Configure a model + +Now, set up the Azure OpenAI model: + +. From within your Azure OpenAI deployment, select **Model deployments**, then click **Manage deployments**. +. On the **Deployments** page, select **Create new deployment**. +. Under **Select a model**, choose `gpt-4o` or `gpt-4 turbo`. +. Set the model version to "Auto-update to default". +. Under **Deployment type**, select **Standard**. +. Name your deployment. +. Slide the **Tokens per Minute Rate Limit** to the maximum. The following example supports 80,000 TPM, but other regions might support higher limits. +. Click **Create**. + +[IMPORTANT] +==== +The models available to you will depend on https://learn.microsoft.com/en-us/azure/ai-services/openai/concepts/models#model-summary-table-and-region-availability[region availability]. For best results, use `GPT-4o 2024-05-13` with the maximum Tokens-Per-Minute (TPM) capacity. For more information on how different models perform for different tasks, refer to the <>. +==== + +The following video demonstrates these steps. + +++++ + +++++ + +[discrete] +[[connect-to-azure-openai-configure-elastic-ai-assistant]] +== Configure Elastic AI Assistant + +Finally, configure the connector in {kib}: + +. Log in to {kib}. +. Go to **Stack Management → Connectors → Create connector → OpenAI**. +. Give your connector a name to help you keep track of different models, such as `Azure OpenAI (GPT-4 Turbo v. 0125)`. +. For **Select an OpenAI provider**, choose **Azure OpenAI**. +. Update the **URL** field. We recommend doing the following: ++ +** Navigate to your deployment in Azure AI Studio and select **Open in Playground**. The **Chat playground** screen displays. +** Select **View code**, then from the drop-down, change the **Sample code** to `Curl`. +** Highlight and copy the URL without the quotes, then paste it into the **URL** field in {kib}. +** (Optional) Alternatively, refer to the https://learn.microsoft.com/en-us/azure/ai-services/openai/reference[API documentation] to learn how to create the URL manually. +. Under **API key**, enter one of your API keys. +. Click **Save & test**, then click **Run**. + +The following video demonstrates these steps. + +++++ + +++++ diff --git a/docs/serverless/AI-for-security/connect-to-bedrock.asciidoc b/docs/serverless/AI-for-security/connect-to-bedrock.asciidoc new file mode 100644 index 0000000000..54cc72207f --- /dev/null +++ b/docs/serverless/AI-for-security/connect-to-bedrock.asciidoc @@ -0,0 +1,171 @@ +[[connect-to-bedrock]] += Connect to Amazon Bedrock + +:description: Set up an Amazon Bedrock LLM connector. +:keywords: security, overview, get-started + +[discrete] +[[connect-to-bedrock-connect-to-amazon-bedrock]] += Connect to Amazon Bedrock + +This page provides step-by-step instructions for setting up an Amazon Bedrock connector for the first time. This connector type enables you to leverage large language models (LLMs) within {kib}. You'll first need to configure AWS, then configure the connector in {kib}. + +[NOTE] +==== +Only Amazon Bedrock's `Anthropic` models are supported: `Claude` and `Claude instant`. +==== + +[discrete] +[[connect-to-bedrock-configure-aws]] +== Configure AWS + +[discrete] +[[connect-to-bedrock-configure-an-iam-policy]] +=== Configure an IAM policy + +First, configure an IAM policy with the necessary permissions: + +. Log into the AWS console and search for Identity and Access Management (IAM). +. From the **IAM** menu, select **Policies** → **Create policy**. +. To provide the necessary permissions, paste the following JSON into the **Specify permissions** menu. + +[source,json] +---- +{ + "Version": "2012-10-17", + "Statement": [ + { + "Sid": "VisualEditor0", + "Effect": "Allow", + "Action": [ + "bedrock:InvokeModel", + "bedrock:InvokeModelWithResponseStream" + ], + "Resource": "*" + } + ] +} +---- + +[NOTE] +==== +These are the minimum required permissions. IAM policies with additional permissions are also supported. +==== + +. Click **Next**. Name your policy. + +The following video demonstrates these steps. + +++++ + +++++ + +[discrete] +[[connect-to-bedrock-configure-an-iam-user]] +=== Configure an IAM User + +Next, assign the policy you just created to a new user: + +. Return to the **IAM** menu. Select **Users** from the navigation menu, then click **Create User**. +. Name the user, then click **Next**. +. Select **Attach policies directly**. +. In the **Permissions policies** field, search for the policy you created earlier, select it, and click **Next**. +. Review the configuration then click **Create user**. + +The following video demonstrates these steps. + +++++ + +++++ + +[discrete] +[[connect-to-bedrock-create-an-access-key]] +=== Create an access key + +Create the access keys that will authenticate your Elastic connector: + +. Return to the **IAM** menu. Select **Users** from the navigation menu. +. Search for the user you just created, and click its name. +. Go to the **Security credentials** tab. +. Under **Access keys**, click **Create access key**. +. Select **Third-party service**, check the box under **Confirmation**, click **Next**, then click **Create access key**. +. Click **Download .csv file** to download the key. Store it securely. + +The following video demonstrates these steps. + +++++ + +++++ + +[discrete] +[[connect-to-bedrock-enable-model-access]] +=== Enable model access + +Make sure the supported Amazon Bedrock LLMs are enabled: + +. Search the AWS console for Amazon Bedrock. +. From the Amazon Bedrock page, click **Get started**. +. Select **Model access** from the left navigation menu, then click **Manage model access**. +. Check the boxes for **Claude** and/or **Claude Instant**, depending which model or models you plan to use. +. Click **Save changes**. + +The following video demonstrates these steps. + +++++ + +++++ + +[discrete] +[[connect-to-bedrock-configure-the-amazon-bedrock-connector]] +== Configure the Amazon Bedrock connector + +Finally, configure the connector in {kib}: + +. Log in to {kib}. +. Go to **Stack Management → Connectors → Create connector → Amazon Bedrock**. +. Name your connector. +. (Optional) Configure the Amazon Bedrock connector to use a different AWS region where Anthropic models are supported by editing the **URL** field, for example by changing `us-east-1` to `eu-central-1`. +. (Optional) Add one of the following strings if you want to use a model other than the default: ++ +** For Haiku: `anthropic.claude-3-haiku-20240307-v1:0` +** For Sonnet: `anthropic.claude-3-sonnet-20240229-v1:0` +** For Opus: `anthropic.claude-3-opus-20240229-v1:0` +. Enter the **Access Key** and **Secret** that you generated earlier, then click **Save**. + +Your LLM connector is now configured. For more information on using Elastic AI Assistant, refer to https://docs.elastic.co/security/ai-assistant[AI Assistant]. + +[IMPORTANT] +==== +If you're using https://docs.aws.amazon.com/bedrock/latest/userguide/prov-throughput.html[provisioned throughput], your ARN becomes the model ID, and the connector settings **URL** value must be https://www.urlencoder.org/[encoded] to work. For example, if the non-encoded ARN is `arn:aws:bedrock:us-east-2:123456789102:provisioned-model/3Ztr7hbzmkrqy1`, the encoded ARN would be `arn%3Aaws%3Abedrock%3Aus-east-2%3A123456789102%3Aprovisioned-model%2F3Ztr7hbzmkrqy1`. +==== + +The following video demonstrates these steps. + +++++ + +++++ diff --git a/docs/serverless/AI-for-security/connect-to-byo-llm.asciidoc b/docs/serverless/AI-for-security/connect-to-byo-llm.asciidoc new file mode 100644 index 0000000000..86faa9c137 --- /dev/null +++ b/docs/serverless/AI-for-security/connect-to-byo-llm.asciidoc @@ -0,0 +1,223 @@ +[[connect-to-byo-llm]] += Connect to your own local LLM + +:description: Set up a connector to LM Studio so you can use a local model with AI Assistant. +:keywords: security, overview, get-started + +This page provides instructions for setting up a connector to a large language model (LLM) of your choice using LM Studio. This allows you to use your chosen model within {elastic-sec}. You'll first need to set up a reverse proxy to communicate with {elastic-sec}, then set up LM Studio on a server, and finally configure the connector in your {elastic-sec} project. https://www.elastic.co/blog/ai-assistant-locally-hosted-models[Learn more about the benefits of using a local LLM]. + +This example uses a single server hosted in GCP to run the following components: + +* LM Studio with the https://mistral.ai/technology/#models[Mixtral-8x7b] model +* A reverse proxy using Nginx to authenticate to Elastic Cloud + +[role="screenshot"] +image::images/lms-studio-arch-diagram.png[Architecture diagram for this guide] + +[NOTE] +==== +For testing, you can use alternatives to Nginx such as https://learn.microsoft.com/en-us/azure/developer/dev-tunnels/overview[Azure Dev Tunnels] or https://ngrok.com/[Ngrok], but using Nginx makes it easy to collect additional telemetry and monitor its status by using Elastic's native Nginx integration. While this example uses cloud infrastructure, it could also be replicated locally without an internet connection. +==== + +[discrete] +[[connect-to-byo-llm-configure-your-reverse-proxy]] +== Configure your reverse proxy + +[NOTE] +==== +If your Elastic instance is on the same host as LM Studio, you can skip this step. +==== + +You need to set up a reverse proxy to enable communication between LM Studio and Elastic. For more complete instructions, refer to a guide such as https://www.digitalocean.com/community/tutorials/how-to-configure-nginx-as-a-reverse-proxy-on-ubuntu-22-04[this one]. + +The following is an example Nginx configuration file: + +[source] +---- +server { + listen 80; + listen [::]:80; + server_name ; + server_tokens off; + add_header x-xss-protection "1; mode=block" always; + add_header x-frame-options "SAMEORIGIN" always; + add_header X-Content-Type-Options "nosniff" always; + return 301 https://$server_name$request_uri; +} + +server { + + listen 443 ssl http2; + listen [::]:443 ssl http2; + server_name ; + server_tokens off; + ssl_certificate /etc/letsencrypt/live//fullchain.pem; + ssl_certificate_key /etc/letsencrypt/live//privkey.pem; + ssl_session_timeout 1d; + ssl_session_cache shared:SSL:50m; + ssl_session_tickets on; + ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256'; + ssl_protocols TLSv1.3 TLSv1.2; + ssl_prefer_server_ciphers on; + add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always; + add_header x-xss-protection "1; mode=block" always; + add_header x-frame-options "SAMEORIGIN" always; + add_header X-Content-Type-Options "nosniff" always; + add_header Referrer-Policy "strict-origin-when-cross-origin" always; + ssl_stapling on; + ssl_stapling_verify on; + ssl_trusted_certificate /etc/letsencrypt/live//fullchain.pem; + resolver 1.1.1.1; + location / { + + if ($http_authorization != "Bearer ") { + return 401; +} + + proxy_pass http://localhost:1234/; + } + +} +---- + +[IMPORTANT] +==== +* Replace `` with your actual token, and keep it safe since you'll need it to set up the {elastic-sec} connector. +* Replace `` with your actual domain name. +* Update the `proxy_pass` value at the bottom of the configuration if you decide to change the port number in LM Studio to something other than 1234. +==== + +[discrete] +[[connect-to-byo-llm-optional-set-up-performance-monitoring-for-your-reverse-proxy]] +=== (Optional) Set up performance monitoring for your reverse proxy + +You can use Elastic's https://www.elastic.co/docs/current/integrations/nginx[Nginx integration] to monitor performance and populate monitoring dashboards in the {security-app}. + +[discrete] +[[connect-to-byo-llm-configure-lm-studio-and-download-a-model]] +== Configure LM Studio and download a model + +First, install https://lmstudio.ai/[LM Studio]. LM Studio supports the OpenAI SDK, which makes it compatible with Elastic's OpenAI connector, allowing you to connect to any model available in the LM Studio marketplace. + +One current limitation of LM Studio is that when it is installed on a server, you must launch the application using its GUI before doing so using the CLI. For example, by using Chrome RDP with an https://cloud.google.com/architecture/chrome-desktop-remote-on-compute-engine[X Window System]. After you've opened the application the first time using the GUI, you can start it by using `sudo lms server start` in the CLI. + +Once you've launched LM Studio: + +. Go to LM Studio's Search window. +. Search for an LLM (for example, `Mixtral-8x7B-instruct`). Your chosen model must include `instruct` in its name in order to work with Elastic. +. Filter your search for "Compatibility Guess" to optimize results for your hardware. Results will be color coded: ++ +** Green means "Full GPU offload possible", which yields the best results. +** Blue means "Partial GPU offload possible", which may work. +** Red for "Likely too large for this machine", which typically will not work. +. Download one or more models. + +[IMPORTANT] +==== +For security reasons, before downloading a model, verify that it is from a trusted source. It can be helpful to review community feedback on the model (for example using a site like Hugging Face). +==== + +[role="screenshot"] +image::images/lms-model-select.png[The LM Studio model selection interface] + +In this example we used https://huggingface.co/TheBloke/Mixtral-8x7B-Instruct-v0.1-GGUF[`TheBloke/Mixtral-8x7B-Instruct-v0.1.Q3_K_M.gguf`]. It has 46.7B total parameters, a 32,000 token context window, and uses GGUF https://huggingface.co/docs/transformers/main/en/quantization/overview[quanitization]. For more information about model names and format information, refer to the following table. + +|=== +| Model Name| Parameter Size| Tokens/Context Window| Quantization Format + +| Name of model, sometimes with a version number. +| LLMs are often compared by their number of parameters — higher numbers mean more powerful models. +| Tokens are small chunks of input information. Tokens do not necessarily correspond to characters. You can use https://platform.openai.com/tokenizer[Tokenizer] to see how many tokens a given prompt might contain. +| Quantization reduces overall parameters and helps the model to run faster, but reduces accuracy. + +| Examples: Llama, Mistral, Phi-3, Falcon. +| The number of parameters is a measure of the size and the complexity of the model. The more parameters a model has, the more data it can process, learn from, generate, and predict. +| The context window defines how much information the model can process at once. If the number of input tokens exceeds this limit, input gets truncated. +| Specific formats for quantization vary, most models now support GPU rather than CPU offloading. +|=== + +[discrete] +[[connect-to-byo-llm-load-a-model-in-lm-studio]] +== Load a model in LM Studio + +After downloading a model, load it in LM Studio using the GUI or LM Studio's https://lmstudio.ai/blog/lms[CLI tool]. + +[discrete] +[[connect-to-byo-llm-option-1-load-a-model-using-the-cli-recommended]] +=== Option 1: load a model using the CLI (Recommended) + +It is a best practice to download models from the marketplace using the GUI, and then load or unload them using the CLI. The GUI allows you to search for models, whereas the CLI only allows you to import specific paths, but the CLI provides a good interface for loading and unloading. + +Use the following commands in your CLI: + +. Verify LM Studio is installed: `lms` +. Check LM Studio's status: `lms status` +. List all downloaded models: `lms ls` +. Load a model: `lms load` + +[role="screenshot"] +image::images/lms-cli-welcome.png[The CLI interface during execution of initial LM Studio commands] + +After the model loads, you should see a `Model loaded successfully` message in the CLI. + +[role="screenshot"] +image::images/lms-studio-model-loaded-msg.png[The CLI message that appears after a model loads] + +To verify which model is loaded, use the `lms ps` command. + +[role="screenshot"] +image::images/lms-ps-command.png[The CLI message that appears after running lms ps] + +If your model uses NVIDIA drivers, you can check the GPU performance with the `sudo nvidia-smi` command. + +[discrete] +[[connect-to-byo-llm-option-2-load-a-model-using-the-gui]] +=== Option 2: load a model using the GUI + +Refer to the following video to see how to load a model using LM Studio's GUI. You can change the **port** setting, which is referenced in the Nginx configuration file. Note that the **GPU offload** was set to **Max**. + +++++ + + +++++ + +[discrete] +[[connect-to-byo-llm-optional-collect-logs-using-elastics-custom-logs-integration]] +== (Optional) Collect logs using Elastic's Custom Logs integration + +You can monitor the performance of the host running LM Studio using Elastic's https://www.elastic.co/docs/current/integrations/log[Custom Logs integration]. This can also help with troubleshooting. Note that the default path for LM Studio logs is `/tmp/lmstudio-server-log.txt`, as in the following screenshot: + +[role="screenshot"] +image::images/lms-custom-logs-config.png[The configuration window for the custom logs integration] + +[discrete] +[[connect-to-byo-llm-configure-the-connector-in-elastic-sec]] +== Configure the connector in {elastic-sec} + +Finally, configure the connector in your Security project: + +. Log in to your Security project. +. Navigate to **Stack Management → Connectors → Create Connector → OpenAI**. The OpenAI connector enables this use case because LM Studio uses the OpenAI SDK. +. Name your connector to help keep track of the model version you are using. +. Under **Select an OpenAI provider**, select **Other (OpenAI Compatible Service)**. +. Under **URL**, enter the domain name specified in your Nginx configuration file, followed by `/v1/chat/completions`. +. Under **Default model**, enter `local-model`. +. Under **API key**, enter the secret token specified in your Nginx configuration file. +. Click **Save**. + +[role="screenshot"] +image::images/lms-edit-connector.png[The Edit connector page in the {security-app}, with appropriate values populated] + +Setup is now complete. You can use the model you've loaded in LM Studio to power Elastic's generative AI features. You can test a variety of models as you interact with AI Assistant to see what works best without having to update your connector. + +[NOTE] +==== +While local models work well for <>, we recommend you use one of <> for interacting with <>. As local models become more performant over time, this is likely to change. +==== diff --git a/docs/serverless/AI-for-security/connect-to-openai.asciidoc b/docs/serverless/AI-for-security/connect-to-openai.asciidoc new file mode 100644 index 0000000000..704502951d --- /dev/null +++ b/docs/serverless/AI-for-security/connect-to-openai.asciidoc @@ -0,0 +1,74 @@ +[[connect-to-openai]] += Connect to OpenAI + +:description: Set up an OpenAI LLM connector. +:keywords: security, overview, get-started + +[discrete] +[[connect-to-openai-connect-to-openai]] += Connect to OpenAI + +This page provides step-by-step instructions for setting up an OpenAI connector for the first time. This connector type enables you to leverage OpenAI's large language models (LLMs) within {kib}. You'll first need to create an OpenAI API key, then configure the connector in {kib}. + +[discrete] +[[connect-to-openai-configure-openai]] +== Configure OpenAI + +[discrete] +[[connect-to-openai-select-a-model]] +=== Select a model + +Before creating an API key, you must choose a model. Refer to the https://platform.openai.com/docs/models/gpt-4-turbo-and-gpt-4[OpenAI docs] to select a model. Take note of the specific model name (for example `gpt-4-turbo`); you'll need it when configuring {kib}. + +[NOTE] +==== +`GPT-4o` offers increased performance over previous versions. For more information on how different models perform for different tasks, refer to the <>. +==== + +[discrete] +[[connect-to-openai-create-an-api-key]] +=== Create an API key + +To generate an API key: + +. Log in to the OpenAI platform and navigate to **API keys**. +. Select **Create new secret key**. +. Name your key, select an OpenAI project, and set the desired permissions. +. Click **Create secret key** and then copy and securely store the key. It will not be accessible after you leave this screen. + +The following video demonstrates these steps. + +++++ + +++++ + +[discrete] +[[connect-to-openai-configure-the-openai-connector]] +== Configure the OpenAI connector + +Finally, configure the connector in {kib}: + +. Log in to {kib}. +. Navigate to **Stack Management → Connectors → Create Connector → OpenAI**. +. Provide a name for your connector, such as `OpenAI (GPT-4 Turbo Preview)`, to help keep track of the model and version you are using. +. Under **Select an OpenAI provider**, choose **OpenAI**. +. The **URL** field can be left as default. +. Under **Default model**, specify which https://platform.openai.com/docs/models/gpt-4-turbo-and-gpt-4[model] you want to use. +. Paste the API key that you created into the corresponding field. +. Click **Save**. + +The following video demonstrates these steps. + +++++ + +++++ diff --git a/docs/serverless/AI-for-security/connect-to-vertex.asciidoc b/docs/serverless/AI-for-security/connect-to-vertex.asciidoc new file mode 100644 index 0000000000..72dc06a7d2 --- /dev/null +++ b/docs/serverless/AI-for-security/connect-to-vertex.asciidoc @@ -0,0 +1,115 @@ +[[connect-to-google-vertex]] += Connect to Google Vertex AI + +:description: Set up a Google Vertex LLM connector. +:keywords: security, overview, get-started + +This page provides step-by-step instructions for setting up a Google Vertex AI connector for the first time. This connector type enables you to leverage Vertex AI's large language models (LLMs) within {elastic-sec}. You'll first need to enable Vertex AI, then generate an API key, and finally configure the connector in your {elastic-sec} project. + +[IMPORTANT] +==== +Before continuing, you should have an active project in one of Google Vertex AI's https://cloud.google.com/vertex-ai/docs/general/locations#feature-availability[supported regions]. +==== + +[discrete] +[[connect-to-google-vertex-enable-the-vertex-ai-api]] +== Enable the Vertex AI API + +. Log in to the GCP console and navigate to **Vertex AI → Vertex AI Studio → Overview**. +. If you're new to Vertex AI, the **Get started with Vertex AI Studio** popup appears. Click **Vertex AI API**, then click **ENABLE**. + +The following video demonstrates these steps. + +++++ + + +++++ + +[NOTE] +==== +For more information about enabling the Vertex AI API, refer to https://cloud.google.com/vertex-ai/docs/start/cloud-environment[Google's documentation]. +==== + +[discrete] +[[connect-to-google-vertex-create-a-vertex-ai-service-account]] +== Create a Vertex AI service account + +. In the GCP console, navigate to **APIs & Services → Library**. +. Search for **Vertex AI API**, select it, and click **MANAGE**. +. In the left menu, navigate to **Credentials** then click **+ CREATE CREDENTIALS** and select **Service account**. +. Name the new service account, then click **CREATE AND CONTINUE**. +. Under **Select a role**, select **Vertex AI User**, then click **CONTINUE**. +. Click **Done**. + +The following video demonstrates these steps. + +++++ + + +++++ + +[discrete] +[[connect-to-google-vertex-generate-an-api-key]] +== Generate an API key + +. Return to Vertex AI's **Credentials** menu and click **Manage service accounts**. +. Search for the service account you just created, select it, then click the link that appears under **Email**. +. Go to the **KEYS** tab, click **ADD KEY**, then select **Create new key**. +. Select **JSON**, then click **CREATE** to download the key. Keep it somewhere secure. + +The following video demonstrates these steps. + +++++ + + +++++ + +[discrete] +[[connect-to-google-vertex-configure-the-google-gemini-connector]] +== Configure the Google Gemini connector + +Finally, configure the connector in {kib}: + +. Log in to {kib}. +. Navigate to **Stack Management → Connectors → Create Connector → Google Gemini**. +. Name your connector to help keep track of the model version you are using. +. Under **URL**, enter the URL for your region. +. Enter your **GCP Region** and **GCP Project ID**. +. Under **Default model**, specify either `gemini-1.5.pro` or `gemini-1.5-flash`. https://cloud.google.com/vertex-ai/generative-ai/docs/learn/models[Learn more about the models]. +. Under **Authentication**, enter your API key. +. Click **Save**. + +The following video demonstrates these steps. + +++++ + + +++++ diff --git a/docs/serverless/AI-for-security/llm-connector-guides.asciidoc b/docs/serverless/AI-for-security/llm-connector-guides.asciidoc new file mode 100644 index 0000000000..9a4fc5eacb --- /dev/null +++ b/docs/serverless/AI-for-security/llm-connector-guides.asciidoc @@ -0,0 +1,15 @@ +[[llm-connector-guides]] += LLM connector guides + +:description: Set up LLM connectors to enable AI features in {elastic-sec} +:keywords: security, overview, get-started + +This section contains instructions for setting up connectors for LLMs so you can use <> and <>. + +Setup guides are available for the following LLM providers: + +* <> +* <> +* <> +* <> +* <> diff --git a/docs/serverless/AI-for-security/llm-performance-matrix.asciidoc b/docs/serverless/AI-for-security/llm-performance-matrix.asciidoc new file mode 100644 index 0000000000..eb1058db5b --- /dev/null +++ b/docs/serverless/AI-for-security/llm-performance-matrix.asciidoc @@ -0,0 +1,56 @@ +[[llm-performance-matrix]] += Large language model performance matrix + +:description: Learn how different models perform on different tasks in {elastic-sec}. +:keywords: security, overview, get-started + +This table describes the performance of various large language models (LLMs) for different use cases in {elastic-sec}, based on our internal testing. To learn more about these use cases, refer to <> or <>. + +|=== +| **Feature**| **Model**| | | | | | + +| +| **Claude 3: Opus** +| **Claude 3.5: Sonnet** +| **Claude 3: Haiku** +| **GPT-4o** +| **GPT-4 Turbo** +| **Gemini 1.5 Pro** +| **Gemini 1.5 Flash** + +| **Assistant: general** +| Excellent +| Excellent +| Excellent +| Excellent +| Excellent +| Excellent +| Excellent + +| **Assistant: {esql} generation** +| Great +| Great +| Poor +| Excellent +| Poor +| Good +| Poor + +| **Assistant: alert questions** +| Excellent +| Excellent +| Excellent +| Excellent +| Poor +| Excellent +| Good + +| **Attack discovery** +| Excellent +| Excellent +| Poor +| Poor +| Good +| Great +| Poor +|=== diff --git a/docs/serverless/AI-for-security/usecase-attack-disc-ai-assistant-incident-reporting.asciidoc b/docs/serverless/AI-for-security/usecase-attack-disc-ai-assistant-incident-reporting.asciidoc new file mode 100644 index 0000000000..488967cca3 --- /dev/null +++ b/docs/serverless/AI-for-security/usecase-attack-disc-ai-assistant-incident-reporting.asciidoc @@ -0,0 +1,69 @@ +[[ai-usecase-incident-reporting]] += Identify, investigate, and document threats + +:description: Use Attack discovery and AI Assistant to manage threats. +:keywords: security, overview, get-started + +Together, <> and <> can help you identify and mitigate threats, investigate incidents, and generate incident reports in various languages so you can monitor and protect your environment. + +In this guide, you'll learn how to: + +* <> +* <> +* <> +* <> + +[discrete] +[[use-case-incident-reporting-use-attack-discovery-to-identify-threats]] +== Use Attack discovery to identify threats + +Attack discovery can detect a wide range of threats by finding relationships among alerts that may indicate a coordinated attack. This enables you to comprehend how threats move through and affect your systems. Attack discovery generates a detailed summary of each potential threat, which can serve as the basis for further analysis. Learn how to <>. + +[role="screenshot"] +image::images/attck-disc-11-alerts-disc.png[An Attack discovery card showing an attack with 11 related alerts] + +In the example above, Attack discovery found connections between nine alerts, and used them to identify and describe an attack chain. + +After Attack discovery outlines your threat landscape, use Elastic AI Assistant to quickly analyze a threat in detail. + +[discrete] +[[use-case-incident-reporting-use-ai-assistant-to-analyze-a-threat]] +== Use AI Assistant to analyze a threat + +From a discovery on the Attack discovery page, click **View in AI Assistant** to start a chat that includes the discovery as context. + +[role="screenshot"] +image::images/attck-disc-remediate-sodinokibi.gif[A dialogue with AI Assistant that has the attack discovery as context] + +AI Assistant can quickly compile essential data and provide suggestions to help you generate an incident report and plan an effective response. You can ask it to provide relevant data or answer questions, such as “How can I remediate this threat?” or “What {esql} query would isolate actions taken by this user?” + +[role="screenshot"] +image::images/attck-disc-esql-query-gen-example.png[An AI Assistant dialogue in which the user asks for a purpose-built ES|QL query] + +The image above shows an {esql} query generated by AI Assistant in response to a user prompt. Learn more about <>. + +At any point in a conversation with AI Assistant, you can add data, narrative summaries, and other information from its responses to {elastic-sec}'s case management system to generate incident reports. + +[discrete] +[[use-case-incident-reporting-create-a-case-using-ai-assistant]] +== Generate reports + +From the AI Assistant dialog window, click **Add to case** (image:images/icons/addDataApp.svg[Add data]) next to a message to add the information in that message to a <>. Cases help centralize relevant details in one place for easy sharing with stakeholders. + +If you add a message that contains a discovery to a case, AI Assistant automatically adds the attack summary and all associated alerts to the case. You can also add AI Assistant messages that contain remediation steps and relevant data to the case. + +[discrete] +[[use-case-incident-reporting-translate]] +== Translate incident information to a different human language using AI Assistant + +[role="screenshot"] +image::images/attck-disc-translate-japanese.png[An AI Assistant dialogue in which the assistant translates from English to Japanese] + +AI Assistant can translate its findings into other human languages, helping to enable collaboration among global security teams, and making it easier to operate within multilingual organizations. + +After AI Assistant provides information in one language, you can ask it to translate its responses. For example, if it provides remediation steps for an incident, you can instruct it to “Translate these remediation steps into Japanese.” You can then add the translated output to a case. This can help team members receive the same information and insights regardless of their primary language. + +[NOTE] +==== +In our internal testing, AI Assistant translations preserved the accuracy of the original content. However, all LLMs can make mistakes, so use caution. +==== diff --git a/docs/serverless/advanced-entity-analytics/advanced-behavioral-detections.asciidoc b/docs/serverless/advanced-entity-analytics/advanced-behavioral-detections.asciidoc new file mode 100644 index 0000000000..85d3f033a4 --- /dev/null +++ b/docs/serverless/advanced-entity-analytics/advanced-behavioral-detections.asciidoc @@ -0,0 +1,14 @@ +[[advanced-behavioral-detections]] += Advanced behavioral detections + +:description: Learn about advanced behavioral detections and its capabilities. +:keywords: serverless, security, overview, analyze + +preview:[] + +Elastic's {ml} capabilities and advanced correlation, scoring, and visualization techniques can help you identify potential behavioral threats that may be associated with security incidents. + +Advanced behavioral detections includes two key capabilities: + +* <> +* <> diff --git a/docs/serverless/advanced-entity-analytics/advanced-entity-analytics-overview.asciidoc b/docs/serverless/advanced-entity-analytics/advanced-entity-analytics-overview.asciidoc new file mode 100644 index 0000000000..ec85a6e3eb --- /dev/null +++ b/docs/serverless/advanced-entity-analytics/advanced-entity-analytics-overview.asciidoc @@ -0,0 +1,14 @@ +[[advanced-entity-analytics]] += Advanced Entity Analytics + +:description: Learn about Advanced Entity Analytics and its capabilities. +:keywords: serverless, security, overview, analyze + +preview:[] + +Advanced Entity Analytics generates a set of threat detection and risk analytics that allows you to expedite alert triage and hunt for new threats from within an entity's environment. This feature combines the power of the SIEM detection engine and Elastic's {ml} capabilities to identify unusual user behaviors and generate comprehensive risk analytics for hosts and users. + +Advanced Entity Analytics provides two key capabilities: + +* <> +* <> diff --git a/docs/serverless/advanced-entity-analytics/analyze-risk-score-data.asciidoc b/docs/serverless/advanced-entity-analytics/analyze-risk-score-data.asciidoc new file mode 100644 index 0000000000..e65d2b2bf1 --- /dev/null +++ b/docs/serverless/advanced-entity-analytics/analyze-risk-score-data.asciidoc @@ -0,0 +1,153 @@ +[[analyze-risk-score-data]] += View and analyze risk score data + +:description: Monitor risk score changes of hosts and users in your environment. +:keywords: serverless, security, how-to, analyze + +++++ +View risk score data +++++ + +preview:[] + +The {security-app} provides several options to monitor the change in the risk posture of hosts and users from your environment. Use the following places in the {security-app} to view and analyze risk score data: + +* <> +* <> +* <> +* <> +* <> +* <> + +[TIP] +==== +We recommend that you prioritize <> to identify anomalies or abnormal behavior patterns. +==== + +[discrete] +[[analyze-risk-score-data-entity-analytics-dashboard]] +== Entity Analytics dashboard + +From the Entity Analytics dashboard, you can access entity key performance indicators (KPIs), risk scores, and levels. You can also click the number link in the **Alerts** column to investigate and analyze the alerts on the Alerts page. + +[role="screenshot"] +image::images/detection-entity-dashboard/-dashboards-entity-dashboard.png[Entity Analytics dashboard] + +[discrete] +[[analyze-risk-score-data-alert-triaging]] +== Alert triaging + +You can prioritize alert triaging to analyze alerts associated with risky or business-critical entities using the following features in the {security-app}. + +[discrete] +[[analyze-risk-score-data-alerts-page]] +=== Alerts page + +Use the Alerts table to investigate and analyze: + +* Host and user risk levels +* Host and user risk scores +* Asset criticality + +To display entity risk score and asset criticality data in the Alerts table, select **Fields**, and add the following: + +* `user.risk.calculated_level` or `host.risk.calculated_level` +* `user.risk.calculated_score_norm` or `host.risk.calculated_score_norm` +* `user.asset.criticality` or `host.asset.criticality` + +Learn more about <>. + +[role="screenshot"] +image::images/analyze-risk-score-data/alerts-table-rs.png[Risk scores in the Alerts table] + +[discrete] +[[analyze-risk-score-data-triage-alerts-associated-with-high-risk-or-business-critical-entities]] +==== Triage alerts associated with high-risk or business-critical entities + +To analyze alerts associated with high-risk or business-critical entities, you can filter or group them by entity risk level or asset criticality level. + +[NOTE] +==== +If you change the entity's criticality level after an alert is generated, that alert document will include the original criticality level and will not reflect the new criticality level. +==== + +* Use the drop-down filter controls to filter alerts by entity risk level or asset criticality level. To do this, <> to filter by: ++ +** `user.risk.calculated_level` or `host.risk.calculated_level` for entity risk level: ++ +[role="screenshot"] +image::images/analyze-risk-score-data/filter-by-host-risk-level.png[Alerts filtered by high host risk level] +** `user.asset.criticality` or `host.asset.criticality` for asset criticality level: ++ +[role="screenshot"] +image::images/analyze-risk-score-data/filter-by-asset-criticality.png[Filter alerts by asset criticality level] +* To group alerts by entity risk level or asset criticality level, select **Group alerts by**, then select **Custom field** and search for: ++ +** `host.risk.calculated_level` or `user.risk.calculated_level` for entity risk level: ++ +[role="screenshot"] +image::images/analyze-risk-score-data/group-by-host-risk-level.png[Alerts grouped by host risk levels] +** `host.asset.criticality` or `user.asset.criticality` for asset criticality level: ++ +[role="screenshot"] +image::images/analyze-risk-score-data/group-by-asset-criticality.png[Alerts grouped by entity asset criticality levels] +** You can further sort the grouped alerts by highest entity risk score: ++ +... Expand a risk level group (for example, **High**) or an asset criticality group (for example, **high_impact**). +... Select **Sort fields** → **Pick fields to sort by**. +... Select fields in the following order: ++ +.... `host.risk.calculated_score_norm`or `user.risk.calculated_score_norm`: **High-Low** +.... `Risk score`: **High-Low** +.... `@timestamp`: **New-Old** ++ +[role="screenshot"] +image::images/analyze-risk-score-data/hrl-sort-by-host-risk-score.png[High-risk alerts sorted by host risk score] + +[discrete] +[[analyze-risk-score-data-alert-details-flyout]] +=== Alert details flyout + +To access risk score data in the alert details flyout, select **Insights** → **Entities** on the **Overview** tab: + +[role="screenshot"] +image::images/analyze-risk-score-data/alerts-flyout-rs.png[Risk scores in the Alerts flyout] + +[discrete] +[[analyze-risk-score-data-hosts-and-users-pages]] +=== Hosts and Users pages + +On the Hosts and Users pages, you can access the risk score data: + +* In the **Host risk level** or **User risk level** column on the **All hosts** or **All users** tab: ++ +[role="screenshot"] +image::images/analyze-risk-score-data/hosts-hr-level.png[Host risk level data on the All hosts tab of the Hosts page] +* On the **Host risk** or **User risk** tab: ++ +[role="screenshot"] +image::images/analyze-risk-score-data/hosts-hr-data.png[Host risk data on the Host risk tab of the Hosts page] + +[discrete] +[[analyze-risk-score-data-host-and-user-details-pages]] +=== Host and user details pages + +On the host details and user details pages, you can access the risk score data: + +* In the Overview section: ++ +[role="screenshot"] +image::images/analyze-risk-score-data/host-details-overview.png[Host risk data in the Overview section of the host details page] +* On the **Host risk** or **User risk** tab: ++ +[role="screenshot"] +image::images/analyze-risk-score-data/host-details-hr-tab.png[Host risk data on the Host risk tab of the host details page] + +[discrete] +[[analyze-risk-score-data-host-and-user-details-flyouts]] +=== Host and user details flyouts + +In the host details and user details flyouts, you can access the risk score data in the risk summary section: + +[role="screenshot"] +image::images/analyze-risk-score-data/risk-summary.png[Host risk data in the Host risk summary section] diff --git a/docs/serverless/advanced-entity-analytics/asset-criticality.asciidoc b/docs/serverless/advanced-entity-analytics/asset-criticality.asciidoc new file mode 100644 index 0000000000..19a6853896 --- /dev/null +++ b/docs/serverless/advanced-entity-analytics/asset-criticality.asciidoc @@ -0,0 +1,132 @@ +[[asset-criticality]] += Asset criticality + +:description: Learn how to use asset criticality to improve your security operations. +:keywords: serverless, security, overview, analyze + +preview:[] + +.Requirements +[NOTE] +==== +To view and assign asset criticality, you must: + +* Have the appropriate user role. +* Turn on the `securitySolution:enableAssetCriticality` <>. + +For more information, refer to <>. +==== + +The asset criticality feature allows you to classify your organization's entities based on various operational factors that are important to your organization. Through this classification, you can improve your threat detection capabilities by focusing your alert triage, threat-hunting, and investigation activities on high-impact entities. + +You can assign one of the following asset criticality levels to your entities, based on their impact: + +* Low impact +* Medium impact +* High impact +* Extreme impact + +For example, you can assign **Extreme impact** to business-critical entities, or **Low impact** to entities that pose minimal risk to your security posture. + +[discrete] +[[asset-criticality-view-and-assign-asset-criticality]] +== View and assign asset criticality + +Entities do not have a default asset criticality level. You can either assign asset criticality to your entities individually, or <> it to multiple entities by importing a text file. + +When you assign, change, or unassign an individual entity's asset criticality level, that entity's risk score is immediately recalculated. + +[NOTE] +==== +If you assign asset criticality using the file import feature, risk scores are **not** immediately recalculated. However, you can trigger an immediate recalculation by clicking **Recalculate entity risk scores now**. Otherwise, the newly assigned or updated asset criticality levels will be factored in during the next hourly risk scoring calculation. +==== + +You can view, assign, change, or unassign asset criticality from the following places in the {elastic-sec} app: + +* The <> and <>: ++ +[role="screenshot"] +image::images/asset-criticality/-assign-asset-criticality-host-details.png[Assign asset criticality from the host details page] +* The <> and <>: ++ +[role="screenshot"] +image::images/asset-criticality/-assign-asset-criticality-host-flyout.png[Assign asset criticality from the host details flyout] +* The host details flyout and user details flyout in <>: ++ +[role="screenshot"] +image::images/asset-criticality/-assign-asset-criticality-timeline.png[Assign asset criticality from the host details flyout in Timeline] + +[discrete] +[[asset-criticality-bulk-assign-asset-criticality]] +=== Bulk assign asset criticality + +You can bulk assign asset criticality to multiple entities by importing a CSV, TXT or TSV file from your asset management tools. + +The file must contain three columns, with each entity record listed on a separate row: + +. The first column should indicate whether the entity is a `host` or a `user`. +. The second column should specify the entity's `host.name` or `user.name`. +. The third column should specify one of the following asset criticality levels: ++ +** `extreme_impact` +** `high_impact` +** `medium_impact` +** `low_impact` + +The maximum file size is 1 MB. + +File structure example: + +[source] +---- +user,user-001,low_impact +user,user-002,medium_impact +host,host-001,extreme_impact +---- + +To import a file: + +. Go to **Project Settings** → **Stack Management** → **Entity Store**. +. Select or drag and drop the file you want to import. ++ +[NOTE] +==== +The file validation step highlights any lines that don't follow the required file structure. The asset criticality levels for those entities won't be assigned. We recommend that you fix any invalid lines and re-upload the file. +==== +. Click **Assign**. + +This process overwrites any previously assigned asset criticality levels for the entities included in the imported file. The newly assigned or updated asset criticality levels are immediately visible within all asset criticality workflows. + +You can trigger an immediate recalculation of entity risk scores by clicking **Recalculate entity risk scores now**. Otherwise, the newly assigned or updated asset criticality levels will be factored in during the next hourly risk scoring calculation. + +[discrete] +[[asset-criticality-improve-your-security-operations]] +== Improve your security operations + +With asset criticality, you can improve your security operations by: + +* <> +* <> + +[discrete] +[[asset-criticality-prioritize-open-alerts]] +=== Prioritize open alerts + +You can use asset criticality as a prioritization factor when triaging alerts and conducting investigations and response activities. + +Once you assign a criticality level to an entity, all subsequent alerts related to that entity are enriched with its criticality level. This additional context allows you to <>. + +[discrete] +[[asset-criticality-monitor-an-entitys-risk]] +=== Monitor an entity's risk + +The risk scoring engine dynamically factors in an entity's asset criticality, along with `Open` and `Acknowledged` detection alerts to <>. This dynamic risk scoring allows you to monitor changes in the risk profiles of your most sensitive entities, and quickly escalate high-risk threats. + +To view the impact of asset criticality on an entity's risk score, follow these steps: + +. Open the <> or <>. The risk summary section shows asset criticality's contribution to the overall risk score. +. Click **View risk contributions** to open the flyout's left panel. +. In the **Risk contributions** section, verify the entity's criticality level from the time the alert was generated. + +[role="screenshot"] +image::images/asset-criticality/-asset-criticality-impact.png[View asset criticality impact on host risk score] diff --git a/docs/serverless/advanced-entity-analytics/behavioral-detection-use-cases.asciidoc b/docs/serverless/advanced-entity-analytics/behavioral-detection-use-cases.asciidoc new file mode 100644 index 0000000000..676db9f9c1 --- /dev/null +++ b/docs/serverless/advanced-entity-analytics/behavioral-detection-use-cases.asciidoc @@ -0,0 +1,34 @@ +[[behavioral-detection-use-cases]] += Behavioral detection use cases + +:description: Detect internal and external threats using behavioral detection integrations. +:keywords: serverless, security, overview, analyze + +preview:[] + +Behavioral detection identifies potential internal and external threats based on user and host activity. It uses a threat-centric approach to flag suspicious activity by analyzing patterns, anomalies, and context enrichment. + +The behavioral detection feature is built on {elastic-sec}'s foundational SIEM detection capabilities, leveraging {ml} algorithms to enable proactive threat detection and hunting. + +[discrete] +[[behavioral-detection-use-cases-elastic-integrations-for-behavioral-detection-use-cases]] +== Elastic integrations for behavioral detection use cases + +Behavioral detection integrations provide a convenient way to enable behavioral detection capabilities. They streamline the deployment of components that implement behavioral detection, such as data ingestion, transforms, rules, {ml} jobs, and scripts. + +.Requirements +[NOTE] +==== +* Behavioral detection integrations require the Security Analytics Complete https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature]. +* To learn more about the requirements for using {ml} jobs, refer to <>. +==== + +Here's a list of integrations for various behavioral detection use cases: + +* {integrations-docs}/ded[Data Exfiltration Detection] +* {integrations-docs}/dga[Domain Generation Algorithm Detection] +* {integrations-docs}/lmd[Lateral Movement Detection] +* {integrations-docs}/problemchild[Living off the Land Attack Detection] +* {integrations-docs}/beaconing[Network Beaconing Identification] + +To learn more about {ml} jobs enabled by these integrations, refer to {security-guide}/prebuilt-ml-jobs.html[Prebuilt job reference]. diff --git a/docs/serverless/advanced-entity-analytics/entity-risk-scoring.asciidoc b/docs/serverless/advanced-entity-analytics/entity-risk-scoring.asciidoc new file mode 100644 index 0000000000..a56d337a12 --- /dev/null +++ b/docs/serverless/advanced-entity-analytics/entity-risk-scoring.asciidoc @@ -0,0 +1,120 @@ +[[entity-risk-scoring]] += Entity risk scoring + +:description: Learn about the risk scoring engine and its features. +:keywords: serverless, security, overview, analyze + +preview:[] + +Entity risk scoring is an advanced {elastic-sec} analytics feature that helps security analysts detect changes in an entity's risk posture, hunt for new threats, and prioritize incident response. + +Entity risk scoring allows you to monitor risk score changes of hosts and users in your environment. When generating advanced scoring analytics, the risk scoring engine utilizes threats from its end-to-end XDR use cases, such as SIEM, cloud, and endpoint. It leverages the Elastic SIEM detection engine to generate host and user risk scores from the last 30 days. + +It also generates risk scores on a recurring interval, and allows for easy onboarding and management. The engine is built to factor in risks from all {elastic-sec} use cases, and allows you to customize and control how and when risk is calculated. + +[discrete] +[[entity-risk-scoring-risk-scoring-inputs]] +== Risk scoring inputs + +Entity risk scores are determined by the following risk inputs: + +|=== +| Risk input | Storage location + +| <> +| `.alerts-security.alerts-` index alias + +| <> +| `.asset-criticality.asset-criticality-` index alias +|=== + +The resulting entity risk scores are stored in the `risk-score.risk-score-` data stream alias. + +[NOTE] +==== +* Entities without any alerts, or with only `Closed` alerts, are not assigned a risk score. +* To use asset criticality, you must enable the `securitySolution:enableAssetCriticality` <>. +==== + +[discrete] +[[entity-risk-scoring-how-is-risk-score-calculated]] +== How is risk score calculated? + +. The risk scoring engine runs hourly to aggregate `Open` and `Acknowledged` alerts from the last 30 days. For each entity, the engine processes up to 10,000 alerts. +. The engine groups alerts by `host.name` or `user.name`, and aggregates the individual alert risk scores (`kibana.alert.risk_score`) such that alerts with higher risk scores contribute more than alerts with lower risk scores. The resulting aggregated risk score is assigned to the **Alerts** category in the entity's <>. +. The engine then verifies the entity's <>. If there is no asset criticality assigned, the entity risk score remains equal to the aggregated score from the **Alerts** category. If a criticality level is assigned, the engine updates the risk score based on the default risk weight for each criticality level. The asset criticality risk input is assigned to the **Asset Criticality** category in the entity's risk summary. ++ +|=== +| Asset criticality level| Default risk weight + +| Low impact +| 0.5 + +| Medium impact +| 1 + +| High impact +| 1.5 + +| Extreme impact +| 2 +|=== ++ +[NOTE] +==== +Asset criticality levels and default risk weights are subject to change. +==== +. Based on the two risk inputs, the risk scoring engine generates a single entity risk score of 0-100. It assigns a risk level by mapping the risk score to one of these levels: ++ +|=== +| Risk level| Risk score + +| Unknown +| < 20 + +| Low +| 20-40 + +| Moderate +| 40-70 + +| High +| 70-90 + +| Critical +| > 90 +|=== + +.Click for a risk score calculation example +[%collapsible] +===== +This example shows how the risk scoring engine calculates the user risk score for `User_A`, whose asset criticality level is **Extreme impact**. + +There are 5 open alerts associated with `User_A`: + +* Alert 1 with alert risk score 21 +* Alert 2 with alert risk score 45 +* Alert 3 with alert risk score 21 +* Alert 4 with alert risk score 70 +* Alert 5 with alert risk score 21 + +*** + +To calculate the user risk score, the risk scoring engine: + +. Sorts the associated alerts in descending order of alert risk score: ++ +** Alert 4 with alert risk score 70 +** Alert 2 with alert risk score 45 +** Alert 1 with alert risk score 21 +** Alert 3 with alert risk score 21 +** Alert 5 with alert risk score 21 +. Generates an aggregated risk score of 36.16, and assigns it to `User_A`'s **Alerts** risk category. +. Looks up `User_A`'s asset criticality level, and identifies it as **Extreme impact**. +. Generates a new risk input under the **Asset Criticality** risk category, with a risk contribution score of 16.95. +. Increases the user risk score to 53.11, and assigns `User_A` a **Moderate** user risk level. + +If `User_A` had no asset criticality level assigned, the user risk score would remain unchanged at 36.16. +===== + +Learn how to <>. diff --git a/docs/serverless/advanced-entity-analytics/ers-req.asciidoc b/docs/serverless/advanced-entity-analytics/ers-req.asciidoc new file mode 100644 index 0000000000..aea5822185 --- /dev/null +++ b/docs/serverless/advanced-entity-analytics/ers-req.asciidoc @@ -0,0 +1,94 @@ +[[ers-requirements]] += Entity risk scoring requirements + +:description: Requirements for using entity risk scoring and asset criticality. +:keywords: serverless, security, reference, manage + +To use entity risk scoring and asset criticality, you need the appropriate user roles. These features require the Security Analytics Complete https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature]. + +This page covers the requirements for using the entity risk scoring and asset criticality features, as well as their known limitations. + +[discrete] +[[ers-requirements-entity-risk-scoring]] +== Entity risk scoring + +[discrete] +[[ers-requirements-user-roles]] +=== User roles + +To turn on the risk scoring engine, you need either the appropriate https://www.elastic.co/docs/current/serverless/general/assign-user-roles[predefined Security user role] or a https://www.elastic.co/docs/current/serverless/custom-roles[custom role] with the right privileges: + +**Predefined roles** + +* Platform engineer +* Detections admin +* Admin + +**Custom role privileges** + +|=== +| Cluster | Index | {kib} + +| * `manage_index_templates` +* `manage_transform` +| `all` privilege for `risk-score.risk-score-*` +| **Read** for the **Security** feature +|=== + +[discrete] +[[ers-requirements-known-limitations]] +=== Known limitations + +* The risk scoring engine uses an internal user role to score all hosts and users. After you turn on the risk scoring engine, all alerts in the project will contribute to host and user risk scores. +* You cannot customize alert data views or risk weights associated with alerts and asset criticality levels. + +[discrete] +[[ers-requirements-asset-criticality]] +== Asset criticality + +To use the asset criticality feature, turn on the `securitySolution:enableAssetCriticality` <>. + +[discrete] +[[ers-requirements-user-roles-1]] +=== User roles + +To use asset criticality, you need either the appropriate https://www.elastic.co/docs/current/serverless/general/assign-user-roles[predefined Security user role] or a https://www.elastic.co/docs/current/serverless/custom-roles[custom role] with the right privileges: + +**Predefined roles** + +|=== +| Action | Predefined role + +| View asset criticality +| * Viewer +* Tier 1 analyst + +| View, assign, change, or unassign asset criticality +| * Editor +* Tier 2 analyst +* Tier 3 analyst +* Threat intelligence analyst +* Rule author +* SOC manager +* Endpoint operations analyst +* Platform engineer +* Detections admin +* Endpoint policy manager +|=== + +**Custom role privileges** + +Custom roles need the following privileges for the `.asset-criticality.asset-criticality-` index: + +|=== +| Action | Index privilege + +| View asset criticality +| `read` + +| View, assign, or change asset criticality +| `read` and `write` + +| Unassign asset criticality +| `delete` +|=== diff --git a/docs/serverless/advanced-entity-analytics/machine-learning.asciidoc b/docs/serverless/advanced-entity-analytics/machine-learning.asciidoc new file mode 100644 index 0000000000..fb2ab27b07 --- /dev/null +++ b/docs/serverless/advanced-entity-analytics/machine-learning.asciidoc @@ -0,0 +1,89 @@ +[[machine-learning]] += Detect anomalies + +:description: Use the power of machine learning to detect outliers and suspicious events. +:keywords: serverless, security, overview, manage + +preview:[] + +{ml-docs}/ml-ad-overview.html[{ml-cap}] functionality is available when +you have the appropriate role. Refer to <> for more information. + +You can view the details of detected anomalies within the `Anomalies` table +widget shown on the Hosts, Network, and associated details pages, or even narrow +to the specific date range of an anomaly from the `Max anomaly score by job` field +in the overview of the details pages for hosts and IPs. These interfaces also +offer the ability to drag and drop details of the anomaly to Timeline, such as +the `Entity` itself, or any of the associated `Influencers`. + +[discrete] +[[manage-jobs]] +== Manage {ml} jobs + +If you have the `machine_learning_admin` role, you can use the **ML job settings** interface on the **Alerts**, **Rules**, and **Rule Exceptions** pages to view, start, and stop {elastic-sec} {ml} jobs. + +[role="screenshot"] +image::images/machine-learning/-detections-machine-learning-ml-ui.png[ML job settings UI on the Alerts page] + +[discrete] +[[manage-ml-rules]] +=== Manage {ml} detection rules + +You can also check the status of {ml} detection rules, and start or stop their associated {ml} jobs: + +* On the **Rules** page, the **Last response** column displays the rule's current <>. An indicator icon (image:images/icons/warning.svg[Error]) also appears if a required {ml} job isn't running. Click the icon to list the affected jobs, then click **Visit rule details page to investigate** to open the rule's details page. ++ +[role="screenshot"] +image::images/machine-learning/-detections-machine-learning-rules-table-ml-job-error.png[Rules table {ml} job error] +* On a rule's details page, check the **Definition** section to confirm whether the required {ml} jobs are running. Switch the toggles on or off to run or stop each job. ++ +[role="screenshot"] +image::images/machine-learning/-troubleshooting-rules-ts-ml-job-stopped.png[Rule details page with ML job stopped] + +[discrete] +[[included-jobs]] +=== Prebuilt jobs + +{elastic-sec} comes with prebuilt {ml} {anomaly-jobs} for automatically detecting +host and network anomalies. The jobs are displayed in the `Anomaly Detection` +interface. They are available when either: + +* You ship data using https://www.elastic.co/products/beats[Beats] or the +<>, and {kib} is configured with the required index +patterns (such as `auditbeat-*`, `filebeat-*`, `packetbeat-*`, or `winlogbeat-*` +in **Project settings** → **Management** → **Index Management**). + +Or + +* Your shipped data is ECS-compliant, and {kib} is configured with the shipped +data's index patterns in **Project settings** → **Management** → **Index Management**. + +Or + +* You install one or more of the <>. + +<> describes all available {ml} jobs and lists which ECS +fields are required on your hosts when you are not using {beats} or the {agent} +to ship your data. For information on tuning anomaly results to reduce the +number of false positives, see <>. + +[NOTE] +==== +Machine learning jobs look back and analyze two weeks of historical data +prior to the time they are enabled. After jobs are enabled, they continuously +analyze incoming data. When jobs are stopped and restarted within the two-week +time frame, previously analyzed data is not processed again. +==== + +[discrete] +[[view-anomalies]] +== View detected anomalies + +To view the `Anomalies` table widget and `Max Anomaly Score By Job` details, +the user must have the `machine_learning_admin` or `machine_learning_user` role. + +[NOTE] +==== +To adjust the `score` threshold that determines which anomalies are shown, +you can modify the **`securitySolution:defaultAnomalyScore`** advanced setting. +==== diff --git a/docs/serverless/advanced-entity-analytics/machine-learning.mdx b/docs/serverless/advanced-entity-analytics/machine-learning.mdx index f78ecb703d..367d1f463f 100644 --- a/docs/serverless/advanced-entity-analytics/machine-learning.mdx +++ b/docs/serverless/advanced-entity-analytics/machine-learning.mdx @@ -32,7 +32,7 @@ If you have the `machine_learning_admin` role, you can use the **ML job settings You can also check the status of ((ml)) detection rules, and start or stop their associated ((ml)) jobs: -* On the **Rules** page, the **Last response** column displays the rule's current status. An indicator icon () also appears if a required ((ml)) job isn't running. Click the icon to list the affected jobs, then click **Visit rule details page to investigate** to open the rule's details page. +* On the **Rules** page, the **Last response** column displays the rule's current status. An indicator icon () also appears if a required ((ml)) job isn't running. Click the icon to list the affected jobs, then click **Visit rule details page to investigate** to open the rule's details page. ![Rules table ((ml)) job error](../images/machine-learning/-detections-machine-learning-rules-table-ml-job-error.png) diff --git a/docs/serverless/advanced-entity-analytics/ml-requirements.asciidoc b/docs/serverless/advanced-entity-analytics/ml-requirements.asciidoc new file mode 100644 index 0000000000..e9227c5360 --- /dev/null +++ b/docs/serverless/advanced-entity-analytics/ml-requirements.asciidoc @@ -0,0 +1,27 @@ +[[ml-requirements]] += {ml-cap} job and rule requirements + +:description: Requirements for using {ml} jobs and rules. +:keywords: serverless, security, reference, manage + +preview:[] + +To run and create {ml} jobs and rules, you need the appropriate https://www.elastic.co/docs/current/serverless/general/assign-user-roles[user role]. + +Additionally, for https://www.elastic.co/docs/current/serverless/custom-roles[custom roles], to configure <> for {ml} rules, your role needs the following index privilege: + +* `read` permission for the `.ml-anomalies-*` index + +For more information, go to {ml-docs}/setup.html[Set up {ml-features}]. + +[IMPORTANT] +==== +Some roles give +access to the results of _all_ {anomaly-jobs}, irrespective of whether the user +has access to the source indices. Likewise, a user who has full or read-only +access to {ml-features} within a given {kib} space can view the results of _all_ +{anomaly-jobs} that are visible in that space. You must carefully consider who +is given these roles and feature privileges; {anomaly-job} results may propagate +field values that contain sensitive information from the source indices to the +results. +==== diff --git a/docs/serverless/advanced-entity-analytics/prebuilt-ml-jobs.asciidoc b/docs/serverless/advanced-entity-analytics/prebuilt-ml-jobs.asciidoc new file mode 100644 index 0000000000..f5261ea3d2 --- /dev/null +++ b/docs/serverless/advanced-entity-analytics/prebuilt-ml-jobs.asciidoc @@ -0,0 +1,8 @@ +[[prebuilt-ml-jobs]] += Prebuilt ML job reference + +:keywords: serverless, security, reference + +preview:[] + +Refer to {security-guide}/prebuilt-ml-jobs.html[Prebuilt job reference] for information on available prebuilt {ml} jobs. diff --git a/docs/serverless/advanced-entity-analytics/tuning-anomaly-results.asciidoc b/docs/serverless/advanced-entity-analytics/tuning-anomaly-results.asciidoc new file mode 100644 index 0000000000..f398e48e0e --- /dev/null +++ b/docs/serverless/advanced-entity-analytics/tuning-anomaly-results.asciidoc @@ -0,0 +1,170 @@ +[[tuning-anomaly-results]] += Optimizing anomaly results + +:description: Learn how to fine-tune and filter anomaly results. +:keywords: serverless, security, how-to + +preview:[] + +To gain clearer insights into real threats, you can tune the anomaly results. The following procedures help to reduce the number of false positives: + +* <> +* <> + +[discrete] +[[rarely-used-processes]] +== Filter out anomalies from rarely used applications and processes + +When anomalies include results from a known process that only runs occasionally, +you can filter out the unwanted results. + +For example, to filter out results from a housekeeping process, named +`maintenanceservice.exe`, that only executes occasionally you need to: + +. <> +. <> +. <> (optional) + +[discrete] +[[create-fiter-list]] +=== Create a filter list + +. Go to **Machine learning** → **Anomaly Detection** → **Settings**. +. Click **Filter Lists** and then **Create**. ++ +The **Create new filter list** pane is displayed. +. Enter a filter list ID. +. Enter a description for the filter list (optional). +. Click **Add item**. +. In the **Items** textbox, enter the name of the process for which you want to +filter out anomaly results (`maintenanceservice.exe` in our example). ++ +[role="screenshot"] +image::images/tuning-anomaly-results/-detections-machine-learning-filter-add-item.png[] +. Click **Add** and then **Save**. ++ +The new filter appears in the Filter List and can be added to relevant jobs. + +[discrete] +[[add-job-filter]] +=== Add the filter to the relevant job + +. Go to **Machine learning** → **Anomaly Detection** → **Anomaly Explorer**. +. Navigate to the job results for which the filter is required. If the job results +are not listed, click **Edit job selection** and select the relevant job. +. In the **actions** column, click the gear icon and then select _Configure rules_. ++ +The **Create Rule** window is displayed. ++ +[role="screenshot"] +image::images/tuning-anomaly-results/-detections-machine-learning-rule-scope.png[] +. Select: ++ +.. _Add a filter list to limit where the rule applies_. +.. The _WHEN_ statement for the relevant detector (`process.name` in our +example). +.. The _IS IN_ statement. +.. The filter you created as part of the <> procedure. ++ +[TIP] +==== +For more information, see +{ml-docs}/ml-configuring-detector-custom-rules.html[Customizing detectors with custom rules]. +==== +. Click **Save**. + +[NOTE] +==== +Changes to rules only affect new results. All anomalies found by the job +before the filter was added are still displayed. +==== + +[discrete] +[[clone-job]] +=== Clone and rerun the job + +If you want to remove all the previously detected results for the process, you +must clone and run the cloned job. + +[IMPORTANT] +==== +Running the cloned job can take some time. Only run the job after you +have completed all job rule changes. +==== + +. Go to **Machine learning** → **Anomaly Detection** → **Jobs**. +. Navigate to the job for which you configured the rule. + +// Should this be "Navigate to the job that you want to clone"? + +. Optionally, expand the job row and click **JSON** to verify the configured filter +appears under `custom rules` in the JSON code. +. In the **actions** column, click the options menu (image:images/icons/boxesHorizontal.svg[Options menu]) and select **Clone job**. ++ +The **Configure datafeed** page is displayed. +. Click **Data Preview** and check the data is displayed without errors. + +// Unable to verify this step - don't think it exists anymore. + +. Click **Next** until the **Job details** page is displayed. +. Enter a Job ID for the cloned job that indicates it is an iteration of the +original one. For example, append a number or a username to the original job +name, such as `windows-rare-network-process-2`. ++ +[role="screenshot"] +image::images/tuning-anomaly-results/-detections-machine-learning-cloned-job-details.png[] +. Click **Next** and check the job validates without errors. You can ignore +warnings about multiple influencers. +. Click **Next** and then **Create job**. ++ +The **Start ** window is displayed. ++ +// This page doesn't display. ++ +[role="screenshot"] +image::images/tuning-anomaly-results/-detections-machine-learning-start-job-window.png[] +. Select the point of time from which the job will analyze anomalies. + +// Users can't do this. I think their only option is to start the job in real time. + +. Click **Start**. ++ +After a while, results will start to appear on the **Anomaly Explorer** page. + +[discrete] +[[define-rule-threshold]] +== Define an anomaly threshold for a job + +// Unable to test these steps because I don't have the privs needed to enable/run ML jobs + +Certain jobs use a high-count function to look for unusual spikes in +process events. For some processes, a burst of activity is a normal, such as +automation and housekeeping jobs running on server fleets. However, sometimes a +high-delta event count is unlikely to be the result of routine behavior. In +these cases, you can define a minimum threshold for when a high-event count is +considered an anomaly. + +Depending on your anomaly detection results, you may want to set a +minimum event count threshold for the `packetbeat_dns_tunneling` job: + +. Go to **Machine learning** → **Anomaly Detection** → **Anomaly Explorer**. +. Navigate to the job results for the `packetbeat_dns_tunneling` job. If the +job results are not listed, click **Edit job selection** and select +`packetbeat_dns_tunneling`. +. In the **actions** column, click the gear icon and then select +**Configure rules**. ++ +The **Create Rule** window is displayed. ++ +[role="screenshot"] +image::images/tuning-anomaly-results/-detections-machine-learning-ml-rule-threshold.png[] +. Select **Add numeric conditions for when the rule applies** and the following +`when` statement: ++ +_WHEN actual IS GREATER THAN _ ++ +Where `` is the threshold above which anomalies are detected. +. Click **Save**. +. To apply the new threshold, rerun the job (**Job Management** → **Actions** → **Start datafeed**). + +// Re-added the part that was missing from this step (might've not been migrated over), but am unable to verify this step because idk where the Job Management page is. diff --git a/docs/serverless/advanced-entity-analytics/turn-on-risk-engine.asciidoc b/docs/serverless/advanced-entity-analytics/turn-on-risk-engine.asciidoc new file mode 100644 index 0000000000..e27224c10e --- /dev/null +++ b/docs/serverless/advanced-entity-analytics/turn-on-risk-engine.asciidoc @@ -0,0 +1,50 @@ +[[turn-on-risk-engine]] += Turn on the risk scoring engine + +:description: Start generating host and user risk scores. +:keywords: serverless, security, how-to, manage + +++++ +Turn on risk scoring +++++ + +preview:[] + +.Requirements +[NOTE] +==== +To use entity risk scoring, you must have the appropriate user role. For more information, refer to <>. +==== + +[discrete] +[[turn-on-risk-engine-preview-risky-entities]] +== Preview risky entities + +You can preview risky entities before installing the risk engine. The preview shows the riskiest hosts and users found in the 1000 sampled entities during the time frame selected in the date picker. + +[NOTE] +==== +The preview is limited to two risk scores per {serverless-short} {security} project. +==== + +To preview risky entities, go to **Project settings** → **Management** → **Entity Risk Score**: + +[role="screenshot"] +image::images/turn-on-risk-engine/preview-risky-entities.png[Preview of risky entities] + +[discrete] +[[turn-on-risk-engine-turn-on-the-risk-engine]] +== Turn on the risk engine + +[NOTE] +==== +To view risk score data, you must have alerts generated in your environment. +==== + +If you're installing the risk scoring engine for the first time: + +. Go to **Project settings** → **Management** → **Entity Risk Score**. +. Turn the **Entity risk score** toggle on. + +[role="screenshot"] +image::images/turn-on-risk-engine/turn-on-risk-engine.png[Turn on entity risk scoring] diff --git a/docs/serverless/alerts/alert-schema.asciidoc b/docs/serverless/alerts/alert-schema.asciidoc new file mode 100644 index 0000000000..e67b5fbef3 --- /dev/null +++ b/docs/serverless/alerts/alert-schema.asciidoc @@ -0,0 +1,445 @@ +[[alert-schema]] += Alert schema + +:description: The alert schema describes all the fields present in alert events. +:keywords: serverless, security, alerting, reference, manage + +preview:[] + +{elastic-sec} stores alerts that have been generated by detection rules in hidden {es} indices. The index pattern is `.alerts-security.alerts-`. + +[NOTE] +==== +Users are advised NOT to use the `_source` field in alert documents, but rather to use the `fields` option in the search API to programmatically obtain the list of fields used in these documents. Learn more about {ref}/search-fields.html[retrieving selected fields from a search]. +==== + +[NOTE] +==== +The non-ECS fields listed below are beta and subject to change. +==== + +|=== +| Alert field | Description + +| `@timestamp` +| ECS field, represents the time when the alert was created or most recently updated. + +| `message` +| ECS field copied from the source document, if present, for custom query and indicator match rules. + +| `tags` +| ECS field copied from the source document, if present, for custom query and indicator match rules. + +| `labels` +| ECS field copied from the source document, if present, for custom query and indicator match rules. + +| `ecs.version` +| ECS mapping version of the alert. + +| `event.kind` +| ECS field, always `signal` for alert documents. + +| `event.category` +| ECS field, copied from the source document, if present, for custom query and indicator match rules. + +| `event.type` +| ECS field, copied from the source document, if present, for custom query and indicator match rules. + +| `event.outcome` +| ECS field, copied from the source document, if present, for custom query and indicator match rules. + +| `agent.*` +| ECS `agent.*` fields copied from the source document, if present, for custom query and indicator match rules. + +| `client.*` +| ECS `client.*` fields copied from the source document, if present, for custom query and indicator match rules. + +| `cloud.*` +| ECS `cloud.*` fields copied from the source document, if present, for custom query and indicator match rules. + +| `container.*` +| ECS `container.* fields` copied from the source document, if present, for custom query and indicator match rules. + +| `data_stream.*` +a| ECS `data_stream.*` fields copied from the source document, if present, for custom query and indicator match rules. + +[NOTE] +==== +These fields may be constant keywords in the source documents, but are copied into the alert documents as keywords. +==== + +| `destination.*` +| ECS `destination.*` fields copied from the source document, if present, for custom query and indicator match rules. + +| `dll.*` +| ECS `dll.*` fields copied from the source document, if present, for custom query and indicator match rules. + +| `dns.*` +| ECS `dns.*` fields copied from the source document, if present, for custom query and indicator match rules. + +| `error.*` +| ECS `error.*` fields copied from the source document, if present, for custom query and indicator match rules. + +| `event.*` +a| ECS `event.*` fields copied from the source document, if present, for custom query and indicator match rules. + +[NOTE] +==== +categorization fields above (`event.kind`, `event.category`, `event.type`, `event.outcome`) are listed separately above. +==== + +| `file.*` +| ECS `file.*` fields copied from the source document, if present, for custom query and indicator match rules. + +| `group.*` +| ECS `group.*` fields copied from the source document, if present, for custom query and indicator match rules. + +| `host.*` +| ECS `host.*` fields copied from the source document, if present, for custom query and indicator match rules. + +| `http.*` +| ECS `http.*` fields copied from the source document, if present, for custom query and indicator match rules. + +| `log.*` +| ECS `log.*` fields copied from the source document, if present, for custom query and indicator match rules. + +| `network.*` +| ECS `network.*` fields copied from the source document, if present, for custom query and indicator match rules. + +| `observer.*` +| ECS `observer.*` fields copied from the source document, if present, for custom query and indicator match rules. + +| `orchestrator.*` +| ECS `orchestrator.*` fields copied from the source document, if present, for custom query and indicator match rules. + +| `organization.*` +| ECS `organization.*` fields copied from the source document, if present, for custom query and indicator match rules. + +| `package.*` +| ECS `package.*` fields copied from the source document, if present, for custom query and indicator match rules. + +| `process.*` +| ECS `process.*` fields copied from the source document, if present, for custom query and indicator match rules. + +| `registry.*` +| ECS `registry.*` fields copied from the source document, if present, for custom query and indicator match rules. + +| `related.*` +| ECS `related.*` fields copied from the source document, if present, for custom query and indicator match rules. + +| `rule.*` +a| ECS `rule.*` fields copied from the source document, if present, for custom query and indicator match rules. + +[NOTE] +==== +These fields are not related to the detection rule that generated the alert. +==== + +| `server.*` +| ECS `server.*` fields copied from the source document, if present, for custom query and indicator match rules. + +| `service.*` +| ECS `service.*` fields copied from the source document, if present, for custom query and indicator match rules. + +| `source.*` +| ECS `source.*` fields copied from the source document, if present, for custom query and indicator match rules. + +| `span.*` +| ECS `span.*` fields copied from the source document, if present, for custom query and indicator match rules. + +| `threat.*` +| ECS `threat.*` fields copied from the source document, if present, for custom query and indicator match rules. + +| `tls.*` +| ECS `tls.*` fields copied from the source document, if present, for custom query and indicator match rules. + +| `trace.*` +| ECS `trace.*` fields copied from the source document, if present, for custom query and indicator match rules. + +| `transaction.*` +| ECS `transaction.*` fields copied from the source document, if present, for custom query and indicator match rules. + +| `url.*` +| ECS `url.*` fields copied from the source document, if present, for custom query and indicator match rules. + +| `user.*` +| ECS `user.*` fields copied from the source document, if present, for custom query and indicator match rules. + +| `user_agent.*` +| ECS `user_agent.*` fields copied from the source document, if present, for custom query and indicator match rules. + +| `vulnerability.*` +| ECS `vulnerability.*` fields copied from the source document, if present, for custom query and indicator match rules. + +| `kibana.alert.ancestors.*` +| Type: object + +| `kibana.alert.depth` +| Type: Long + +| `kibana.alert.new_terms` +a| The value of the new term that generated this alert. + +Type: keyword + +| `kibana.alert.original_event.*` +| Type: object + +| `kibana.alert.original_time` +a| The value copied from the source event (`@timestamp`). + +Type: date + +| `kibana.alert.reason` +| Type: keyword + +| `kibana.alert.rule.author` +a| The value of the `author` who created the rule. Refer to <>. + +Type: keyword + +| `kibana.alert.building_block_type` +a| The value of `building_block_type` from the rule that generated this alert. Refer to <>. + +Type: keyword + +| `kibana.alert.rule.created_at` +a| The value of `created.at` from the rule that generated this alert. + +Type: date + +| `kibana.alert.rule.created_by` +| Type: keyword + +| `kibana.alert.rule.description` +| Type: keyword + +| `kibana.alert.rule.enabled` +| Type: keyword + +| `kibana.alert.rule.false_positives` +| Type: keyword + +| `kibana.alert.rule.from` +| Type: keyword + +| `kibana.alert.rule.uuid` +| Type: keyword + +| `kibana.alert.rule.immutable` +| Type: keyword + +| `kibana.alert.rule.interval` +| Type: keyword + +| `kibana.alert.rule.license` +| Type: keyword + +| `kibana.alert.rule.max_signals` +| Type: long + +| `kibana.alert.rule.name` +| Type: keyword + +| `kibana.alert.rule.note` +| Type: keyword + +| `kibana.alert.rule.references` +| Type: keyword + +| `kibana.alert.risk_score` +| Type: float + +| `kibana.alert.rule.rule_id` +| Type: keyword + +| `kibana.alert.rule.rule_name_override` +| Type: keyword + +| `kibana.alert.severity` +a| Alert severity, populated by the `rule_type` at alert creation. Must have a value of `low`, `medium`, `high`, `critical`. + +Type: keyword + +| `kibana.alert.rule.tags` +| Type: keyword + +| `kibana.alert.rule.threat.*` +| Type: object + +| `kibana.alert.rule.timeline_id` +| Type: keyword + +| `kibana.alert.rule.timeline_title` +| Type: keyword + +| `kibana.alert.rule.timestamp_override` +| Type: keyword + +| `kibana.alert.rule.to` +| Type: keyword + +| `kibana.alert.rule.type` +| Type: keyword + +| `kibana.alert.rule.updated_at` +| Type: date + +| `kibana.alert.rule.updated_by` +| Type: keyword + +| `kibana.alert.rule.version` +a| A number that represents a rule's version. + +Type: keyword + +| `kibana.alert.rule.revision` +a| A number that gets incremented each time you edit a rule. + +Type: long + +| `kibana.alert.workflow_status` +| Type: keyword + +| `kibana.alert.workflow_status_updated_at` +a| The timestamp of when the alert's status was last updated. + +Type: date + +| `kibana.alert.threshold_result.*` +| Type: object + +| `kibana.alert.group.id` +| Type: keyword + +| `kibana.alert.group.index` +| Type: integer + +| `kibana.alert.rule.parameters.index` +| Type: flattened + +| `kibana.alert.rule.parameters.language` +| Type: flattened + +| `kibana.alert.rule.parameters.query` +| Type: flattened + +| `kibana.alert.rule.parameters.risk_score_mapping` +| Type: flattened + +| `kibana.alert.rule.parameters.saved_id` +| Type: flattened + +| `kibana.alert.rule.parameters.severity_mapping` +| Type: flattened + +| `kibana.alert.rule.parameters.threat_filters` +| Type: flattened + +| `kibana.alert.rule.parameters.threat_index` +a| Names of the indicator indices. + +Type: flattened + +| `kibana.alert.rule.parameters.threat_indicator_path` +| Type: flattened + +| `kibana.alert.rule.parameters.threat_language` +| Type: flattened + +| `kibana.alert.rule.parameters.threat_mapping.*` +a| Controls which fields will be compared in the indicator and source documents. + +Type: flattened + +| `kibana.alert.rule.parameters.threat_query` +| Type: flattened + +| `kibana.alert.rule.parameters.threshold.*` +| Type: flattened + +| `kibana.space_ids` +| Type: keyword + +| `kibana.alert.rule.consumer` +| Type: keyword + +| `kibana.alert.status` +| Type: keyword + +| `kibana.alert.rule.category` +| Type: keyword + +| `kibana.alert.rule.execution.uuid` +| Type: keyword + +| `kibana.alert.rule.producer` +| Type: keyword + +| `kibana.alert.rule.rule_type_id` +| Type: keyword + +| `kibana.alert.suppression.terms.field` +a| The fields used to group alerts for suppression. + +Type: keyword + +| `kibana.alert.suppression.terms.value` +a| The values in the suppression fields. + +Type: keyword + +| `kibana.alert.suppression.start` +a| The timestamp of the first document in the suppression group. + +Type: date + +| `kibana.alert.suppression.end` +a| The timestamp of the last document in the suppression group. + +Type: date + +| `kibana.alert.suppression.docs_count` +a| The number of suppressed alerts. + +Type: long + +| `kibana.alert.url` +a| The shareable URL for the alert. + +[NOTE] +==== +This field only appears if you've set the {kibana-ref}/settings.html#server-publicBaseUrl[`server.publicBaseUrl`] configuration setting in the `kibana.yml` file. +==== + +Type: long + +| `kibana.alert.workflow_tags` +a| List of tags added to an alert. + +This field can contain an array of values, for example: `["False Positive", "production"]` + +Type: keyword + +| `kibana.alert.workflow_assignee_ids` +a| List of users assigned to an alert. + +An array of unique identifiers (UIDs) for user profiles, for example: `["u_1-0CcWliOCQ9T2MrK5YDjhpxZ_AcxPKt3pwaICcnAUY_0, u_2-0CcWliOCQ9T2MrK5YDjhpxZ_AcxPKt3pwaICcnAUY_1"]` + +UIDs are linked to user profiles that are automatically created when users first log into a project. These profiles contain names, emails, profile avatars, and other user settings. + +Type: string[] + +| `kibana.alert.intended_timestamp` +a| Shows the alert’s estimated timestamp, had the alert been created when the source event initially occurred. The value in this field is determined by the way the rule was run: + +* **Scheduled run**: Alerts created by scheduled runs have the same timestamp as the `@timestamp` field, which shows when the alert was created. +* **Manual run**: Alerts created by manual runs have a timestamp that falls within the time range specified for the manual run. For example, if you set a rule to manually run on event data from `10/01/2024 05:00 PM` to `10/07/2024 05:00 PM`, the `kibana.alert.intended_timestamp` value will be a date and time within that range. + +Type: date + +| `kibana.alert.rule.execution.type` +a| Shows if an alert was created by a manual run or a scheduled run. The value can be `manual` or `scheduled`. + +Type: keyword +|=== diff --git a/docs/serverless/alerts/alert-suppression.asciidoc b/docs/serverless/alerts/alert-suppression.asciidoc new file mode 100644 index 0000000000..3689542c95 --- /dev/null +++ b/docs/serverless/alerts/alert-suppression.asciidoc @@ -0,0 +1,134 @@ +[[alert-suppression]] += Suppress detection alerts + +:description: Reduce noise from rules that create repeated or duplicate alerts. +:keywords: serverless, security, how-to + +++++ +Suppress alerts +++++ + +preview:[] + +.Requirements and notice +[IMPORTANT] +==== +* {ml-cap} rules have <> for alert suppression. +* Alert suppression is in technical preview for event correlation rules. The functionality may be changed or removed in a future release. Elastic will work to fix any issues, but features in technical preview are not subject to the support SLA of official GA features. +==== + +Alert suppression allows you to reduce the number of repeated or duplicate detection alerts created by these detection rule types: + +* <> +* <> +* <> +* <> (non-sequence queries only) +* <> +* <> +* <> + +Normally, when a rule meets its criteria repeatedly, it creates multiple alerts, one for each time the rule's criteria are met. When alert suppression is configured, duplicate qualifying events are grouped, and only one alert is created for each group. Depending on the rule type, you can configure alert suppression to create alerts each time the rule runs, or once within a specified time window. You can also specify multiple fields to group events by unique combinations of values. + +The {security-app} displays several indicators in the Alerts table and the alert details flyout when a detection alert is created with alert suppression enabled. You can view the original events associated with suppressed alerts by investigating the alert in Timeline. + +[NOTE] +==== +Alert suppression is not available for Elastic prebuilt rules. However, if you want to suppress alerts for a prebuilt rule, you can duplicate it, then configure alert suppression on the duplicated rule. +==== + +[discrete] +[[alert-suppression-configure-alert-suppression]] +== Configure alert suppression + +You can configure alert suppression when you create or edit a supported rule type. Refer to documentation for creating <>, <>, <>, <>, <>, <>, or <> rules for detailed instructions. + +. When configuring the rule type (the **Define rule** step for a new rule, or the **Definition** tab for an existing rule), specify how you want to group events for alert suppression: ++ +** **Custom query rule, indicator match, threshold, event correlation (non-sequence queries only), new terms, {esql}, or {ml} rules:** In **Suppress alerts by**, enter 1-3 field names to group events by the fields' values. +** **Threshold rule:** In **Group by**, enter up to 3 field names to group events by the fields' values, or leave the setting empty to group all qualifying events together. ++ +[NOTE] +==== +If you specify a field with multiple values, alerts with that field are handled as follows: + +* **Custom query or threshold rules:** Alerts are grouped by each unique value. For example, if you suppress alerts by `destination.ip` of `[127.0.0.1, 127.0.0.2, 127.0.0.3]`, alerts will be suppressed separately for each value of `127.0.0.1`, `127.0.0.2`, and `127.0.0.3`. +* **Indicator match, event correlation (non-sequence queries only), new terms, {esql}, or {ml} rules:** Alerts with the specified field name and identical array values are grouped together. For example, if you suppress alerts by `destination.ip` of `[127.0.0.1, 127.0.0.2, 127.0.0.3]`, alerts with the entire array are grouped and only one alert is created for the group. +==== +. If available, select how often to create alerts for duplicate events: ++ +.NOTE +[NOTE] +==== +Both options are available for custom query, indicator match, event correlation, new terms, {esql}, and {ml} rules. Threshold rules only have the **Per time period** option. +==== ++ +** **Per rule execution**: Create an alert each time the rule runs and an event meets its criteria. +** **Per time period**: Create one alert for all qualifying events that occur within a specified time window, beginning from when an event first meets the rule criteria and creates the alert. ++ +For example, if a rule runs every 5 minutes but you don't need alerts that frequently, you can set the suppression time period to a longer time, such as 1 hour. If the rule meets its criteria, it creates an alert at that time, and for the next hour, it'll suppress any subsequent qualifying events. ++ +[role="screenshot"] +image:images/alert-suppression/-detections-alert-suppression-options.png[Alert suppression options] +. Under **If a suppression field is missing**, choose how to handle events with missing suppression fields (events in which one or more of the **Suppress alerts by** fields don't exist): ++ +.NOTE +[NOTE] +==== +These options are not available for threshold rules. +==== ++ +** **Suppress and group alerts for events with missing fields**: Create one alert for each group of events with missing fields. Missing fields get a `null` value, which is used to group and suppress alerts. +** **Do not suppress alerts for events with missing fields**: Create a separate alert for each matching event. This basically falls back to normal alert creation for events with missing suppression fields. +. Configure other rule settings, then save and enable the rule. + +.Tips +[TIP] +==== +* Use the **Rule preview** before saving the rule to visualize how alert suppression will affect the alerts created, based on historical data. +* If a rule times out while suppression is turned on, try shortening the rule's <> time or turn off suppression to improve the rule's performance. +==== + +[discrete] +[[alert-suppression-confirm-suppressed-alerts]] +== Confirm suppressed alerts + +The {security-app} displays several indicators of whether a detection alert was created with alert suppression enabled, and how many duplicate alerts were suppressed. + +[IMPORTANT] +==== +After an alert is moved to the `Closed` status, it will no longer suppress new alerts. To prevent interruptions or unexpected changes in suppression, avoid closing alerts before the suppression interval ends. +==== + +* **Alerts** table — Icon in the **Rule** column. Hover to display the number of suppressed alerts: ++ +[role="screenshot"] +image:images/alert-suppression/-detections-suppressed-alerts-table.png[Suppressed alerts icon and tooltip in Alerts table] +* **Alerts** table — Column for suppressed alerts count. Select **Fields** to open the fields browser, then add `kibana.alert.suppression.docs_count` to the table. ++ +[role="screenshot"] +image:images/alert-suppression/-detections-suppressed-alerts-table-column.png[Suppressed alerts count field column in Alerts table] +* Alert details flyout — **Insights** section: ++ +[role="screenshot"] +image:images/alert-suppression/-detections-suppressed-alerts-details.png[Suppressed alerts Insights section in alert details flyout] + +[discrete] +[[alert-suppression-investigate-events-for-suppressed-alerts]] +== Investigate events for suppressed alerts + +With alert suppression, detection alerts aren't created for the grouped source events, but you can still retrieve the events for further analysis or investigation. Do one of the following to open Timeline with the original events associated with both the created alert and the suppressed alerts: + +* **Alerts** table — Select **Investigate in timeline** in the **Actions** column. ++ +[role="screenshot"] +image:images/alert-suppression/-detections-timeline-button.png[Investigate in timeline button] +* Alert details flyout — Select **Take action** → **Investigate in timeline**. + +[discrete] +[[alert-suppression-alert-suppression-limit-by-rule-type]] +== Alert suppression limit by rule type + +Some rule types have a maximum number of alerts that can be suppressed (custom query rules don't have a suppression limit): + +* **Threshold, event correlation (non-sequence queries only, {esql}, and {ml}:** The maximum number is the value you choose for the rule's **Max alerts per run** <>, which is `100` by default. +* **Indicator match and new terms:** The maximum number is five times the value you choose for the the rule's **Max alerts per run** <>. The default value is `100`, which means the default maximum limit for indicator match rules and new terms rules is `500`. diff --git a/docs/serverless/alerts/alerts-ui-manage.asciidoc b/docs/serverless/alerts/alerts-ui-manage.asciidoc new file mode 100644 index 0000000000..55c9b54e05 --- /dev/null +++ b/docs/serverless/alerts/alerts-ui-manage.asciidoc @@ -0,0 +1,306 @@ +[[alerts-manage]] += Manage detection alerts + +:description: Filter alerts, view trends, and start investigating and analyzing detections on the Alerts page. +:keywords: serverless, security, alerting, how-to, manage + +++++ +Alerts +++++ + +preview:[] + +The Alerts page displays all detection alerts. + +[role="screenshot"] +image::images/alerts-ui-manage/-detections-alert-page.png[Alerts page overview] + +[discrete] +[[detection-view-and-filter-alerts]] +== View and filter detection alerts + +The Alerts page offers various ways for you to organize and triage detection alerts as you investigate suspicious events. You can: + +* View an alert's details. Click the **View details** button from the Alerts table to open the alert details flyout. Learn more at <>. ++ +[role="screenshot"] +image:images/alerts-ui-manage/-detections-view-alert-details.png[View details button] +* View the rule that created an alert. Click a name in the **Rule** column to open the rule's details page. +* View the details of the host and user associated with the alert. In the Alerts table, click a host name to open the <>, or a user name to open the <>. +* Filter for a specific rule in the KQL bar (for example, `kibana.alert.rule.name :"SSH (Secure Shell) from the Internet"`). KQL autocomplete is available for `.alerts-security.alerts-*` indices. +* Use the date and time filter to define a specific time range. By default, this filter is set to search the last 24 hours. +* Use the drop-down filter controls to filter alerts by up to four fields. By default, you can filter alerts by **Status**, **Severity**, **User**, and **Host**, and you can <> to use other fields. +* Visualize and group alerts by specific fields in the visualization section. Use the buttons on the left to select a view type (**Summary**, **Trend**, **Counts**, or **Treemap**), and use the menus on the right to select the ECS fields used for grouping alerts. Refer to <> for more on each view type. +* Hover over a value to display available <>, such as **Filter In**, **Filter Out**, and **Add to timeline**. Click the expand icon for more options, including **Show top _x_** and **Copy to Clipboard**. The available options vary based on the type of data. ++ +[role="screenshot"] +image:images/alerts-ui-manage/-detections-inline-actions-menu.png[Inline additional actions menu] +* Filter alert results to include building block alerts or to only show alerts from indicator match rules by selecting the **Additional filters** drop-down. By default, <> are excluded from the Overview and Alerts pages. You can choose to include building block alerts on the Alerts page, which expands the number of alerts. ++ +[role="screenshot"] +image::images/alerts-ui-manage/-detections-additional-filters.png[Alerts table with Additional filters menu highlighted] ++ +[NOTE] +==== +When updating alert results to include building block alerts, the Security app searches the `.alerts-security.alerts-` index for the `kibana.alert.building_block_type` field. When looking for alerts created from indicator match rules, the app searches the same index for `kibana.alert.rule.type:'threat_match'`. +==== +* View detection alerts generated by a specific rule. Go to **Rules** → **Detection rules (SIEM)**, then select a rule name in the table. The rule details page displays a comprehensive view of the rule's settings, and the Alerts table under the Trend histogram displays the alerts associated with the rule, including alerts from any previous or deleted revision of that rule. + +[discrete] +[[drop-down-filter-controls]] +== Edit drop-down filter controls + +By default, the drop-down controls on the Alerts page filter alerts by **Status**, **Severity**, **User**, and **Host**. You can edit them to filter by different fields, as well as remove, add, and reorder them if you prefer a different order. + +[role="screenshot"] +image::images/alerts-ui-manage/-detections-alert-page-dropdown-controls.png[Alerts page with drop-down controls highlighted] + +[NOTE] +==== +* You can have a maximum of four controls on the Alerts page. +* You can't remove the **Status** control. +* If you make any changes to the controls, you _must_ save the pending changes for them to persist. +* Saved changes are stored in your browser's local storage, not your {ref}/user-profile.html[user profile]. If you clear your browser's storage or log into your user profile from a different browser, you will lose your customizations. +==== + +. Click the three-dot icon next to the controls (image:images/icons/boxesHorizontal.svg[More actions]), then select **Edit Controls**. +. Do any of the following: ++ +** To reorder controls, click and drag a control by its handle (image:images/icons/grabHorizontal.svg[Reorder]). +** To remove a control, hover over it and select **Remove control** (image:images/icons/cross.svg[Remove]). +** To edit a control, hover over it and select **Edit control** (image:images/icons/pencil.svg[Edit]). +** To add a new control, click **Add Controls** (image:images/icons/plusInCircle.svg[Add]). If you already have four controls, you must first remove one to make room for the new one. +. If you're editing or adding a control, do the following in the configuration flyout that opens: ++ +.. In the **Field** list, select the field for the filter. The **Control type** is automatically applied to the field you selected. +.. Enter a **Label** to identify the control. +.. Click **Save and close**. +. Click **Save pending changes** (image:images/icons/save.svg[Save]). + +[discrete] +[[group-alerts]] +== Group alerts + +You can group alerts by rule name, user name, host name, source IP address, or any other field. Select **Group alerts by**, then select an option or **Custom field** to specify a different field. + +Select up to three fields for grouping alerts. The groups will nest in the order you selected them, and the nesting order is displayed above the table next to **Group alerts by**. + +[role="screenshot"] +image::images/alerts-ui-manage/-detections-group-alerts.png[Alerts table with Group alerts by drop-down] + +Each group displays information such as the alerts' severity and how many users, hosts, and alerts are in the group. The information displayed varies depending on the selected fields. + +To interact with grouped alerts: + +* Select the **Take actions** menu to perform a bulk action on all alerts in a group, such as <>. +* Click a group's name or the expand icon (image:images/icons/arrowRight.svg[Next]) to display alerts within that group. You can filter and customize this view like any other alerts table. ++ +[role="screenshot"] +image::images/alerts-ui-manage/-detections-group-alerts-expand.png[Expanded alert group with alerts table] + +[discrete] +[[customize-the-alerts-table]] +== Customize the Alerts table + +Use the toolbar buttons in the upper-left of the Alerts table to customize the columns you want displayed: + +* **Columns**: Reorder the columns. +* **_x_ fields sorted**: Sort the table by one or more columns. +* **Fields**: Select the fields to display in the table. You can also add <> to detection alerts and display them in the Alerts table. + +Click the **Full screen** button in the upper-right to view the table in full-screen mode. + +[role="screenshot"] +image::images/alerts-ui-manage/-detections-alert-table-toolbar-buttons.png[Alerts table with toolbar buttons highlighted] + +Use the view options drop-down in the upper-right of the Alerts table to control how alerts are displayed: + +* **Grid view**: Displays alerts in a traditional table view with columns for each field +* **Event rendered view**: Display alerts in a descriptive event flow that includes relevant details and context about the event. + +[role="screenshot"] +image::images/alerts-ui-manage/-detections-event-rendered-view.png[Alerts table with the Event rendered view enabled] + +[TIP] +==== +When using grid view, you can view alert-rendered reason statements and event renderings for specific alerts by clicking the expand icon in the **Reason** column. Some events do not have event renderings. +==== + +[discrete] +[[alert-actions]] +== Take actions on an alert + +From the Alerts table or the alert details flyout, you can: + +* <> +* <> +* <> +* <> +* <> +* <> +* <> +* <> +* <> (Alert details flyout only) +* <> +* <> +* <> + +[discrete] +[[detection-alert-status]] +=== Change an alert's status + +You can set an alert's status to indicate whether it needs to be investigated +(**Open**), is under active investigation (**Acknowledged**), or has been resolved +(**Closed**). By default, the Alerts page displays open alerts. To filter alerts that are **Acknowledged** or **Closed**, use the **Status** drop-down filter at the top of the Alerts page. + +To change an alert's status, do one of the following: + +* In the Alerts table, click **More actions** (**...**) in the alert's row, then select a status. +* In the Alerts table, select the alerts you want to change, click **Selected _x_ alerts** at the upper-left above the table, and then select a status. ++ +[role="screenshot"] +image:images/alerts-ui-manage/-detections-alert-change-status.png[Bulk action menu with multiple alerts selected] +* beta:[] To bulk-change the status of <>, select the **Take actions** menu for the group, then select a status. +* In an alert's details flyout, click **Take action** and select a status. + +[discrete] +[[apply-alert-tags]] +=== Apply and filter alert tags + +Use alert tags to organize related alerts into categories that you can filter and group. For example, use the `False Positive` alert tag to label a group of alerts as false positives. Then, search for them by entering the `kibana.alert.workflow_tags : "False Positive"` query into the KQL bar. Alternatively, use the Alert table's <> to filter for tagged alerts. + +[NOTE] +==== +You can manage alert tag options by updating the `securitySolution:alertTags` advanced setting. Refer to <> for more information. +==== + +[TIP] +==== +To display alert tags in the Alerts table, click **Fields** and add the `kibana.alert.workflow_tags` field. +==== + +To apply or remove alert tags on individual alerts, do one of the following: + +* In the Alerts table, click **More actions** (**...**) in an alert's row, then click **Apply alert tags**. Select or unselect tags, then click **Apply tags**. +* In an alert’s details flyout, click **Take action → Apply alert tags**. Select or unselect tags, then click **Apply tags**. + +To apply or remove alert tags on multiple alerts, select the alerts you want to change, then click **Selected _x_ alerts** at the upper-left above the table. Click **Apply alert tags**, select or unselect tags, then click **Apply tags**. + +[role="screenshot"] +image::images/alerts-ui-manage/-detections-bulk-apply-alert-tag.png[Bulk action menu with multiple alerts selected, 450] + +[discrete] +[[assign-users-to-alerts]] +=== Assign users to alerts + +Assign users to alerts that you want them to investigate, and manage alert assignees throughout an alert's lifecycle. + +.Requirements +[NOTE] +==== +All https://www.elastic.co/docs/current/serverless/general/assign-user-roles[Security roles], except for the Viewer role, can assign and unassign users to alerts. +==== + +[IMPORTANT] +==== +Users are not notified when they've been assigned to, or unassigned from, alerts. +==== + +|=== +| Action | Instructions + +| Assign users to an alert +a| Choose one of the following: + +* **Alerts table** - Click **More actions** (**...**) in an alert's row, then click **Assign alert**. Select users, then click **Apply**. +* **Alert details flyout** - Click **Take action → Assign alert**. Alternatively, click the **Assign alert** icon (image:images/icons/plusInCircle.svg[Assign alert]) at the top of the alert details flyout, select users, then click **Apply**. + +| Unassign all users from an alert +a| Choose one of the following: + +* **Alerts table** - Click **More actions** (**...**) in an alert's row, then click **Unassign alert**. +* **Alert details flyout** - Click **Take action → Unassign alert**. + +| Assign users to multiple alerts +a| From the Alerts table, select the alerts you want to change. Click **Selected _x_ alerts** at the upper-left above the table, then click **Assign alert**. Select users, then click **Apply**. + +[NOTE] +==== +Users assigned to some of the selected alerts will be displayed as unassigned in the selection list. Selecting said users will assign them to all alerts they haven't been assigned to yet. +==== + +| Unassign users from multiple alerts +| From the Alerts table, select the alerts you want to change and click **Selected _x_ alerts** at the upper-left above the table. Click **Unassign alert** to remove users from the alert. +|=== + +Show users that have been assigned to alerts by adding the **Assignees** column to the Alerts table (**Fields** → `kibana.alert.workflow_assignee_ids`). Up to four assigned users can appear in the **Assignees** column. If an alert is assigned to five or more users, a number appears instead. + +[role="screenshot"] +image::images/alerts-ui-manage/-detections-alert-assigned-alerts.png[Alert assignees in the Alerts table] + +Assigned users are automatically displayed in the alert details flyout. Up to two assigned users can be shown in the flyout. If an alert is assigned to three or more users, a numbered badge displays instead. + +[role="screenshot"] +image::images/alerts-ui-manage/-detections-alert-flyout-assignees.png[Alert assignees in the alert details flyout] + +[discrete] +[[filter-assigned-alerts]] +=== Filter assigned alerts + +Click the **Assignees** filter above the Alerts table, then select the users you want to filter by. + +[role="screenshot"] +image::images/alerts-ui-manage/-detections-alert-filter-assigned-alerts.png[Filtering assigned alerts] + +[discrete] +[[add-exception-from-alerts]] +=== Add a rule exception from an alert + +You can add exceptions to the rule that generated an alert directly from the +Alerts table. Exceptions prevent a rule from generating alerts even when its +criteria are met. + +To add an exception, click the **More actions** menu (**...**) in the Alerts table, then select +**Add exception**. Alternatively, select **Take action** → **Add rule exception** in the alert details flyout. + +For information about exceptions and how to use them, refer to +<>. + +[discrete] +[[signals-to-timelines]] +=== View alerts in Timeline + +* To view a single alert in Timeline, click the **Investigate in timeline** button in the Alerts table. Alternatively, select **Take action** → **Investigate in timeline** in the alert details flyout. ++ +[role="screenshot"] +image:images/alerts-ui-manage/-detections-timeline-button.png[Investigate in timeline button] +* To view multiple alerts in Timeline (up to 2,000), select the checkboxes next to the alerts, then click **Selected _x_ alerts** → **Investigate in timeline**. ++ +[role="screenshot"] +image:images/alerts-ui-manage/-detections-bulk-add-alerts-to-timeline.png[Bulk add alerts to timeline button] + +[TIP] +==== +When you send an alert generated by a +<> to Timeline, all matching events are +listed in the Timeline, even ones that did not reach the threshold value. For +example, if you have an alert generated by a threshold rule that detects 10 +failed login attempts, when you send that alert to Timeline, all failed login +attempts detected by the rule are listed. +==== + +Suppose the rule that generated the alert uses a Timeline template. In this case, when you investigate the alert in Timeline, the dropzone query values defined in the template are replaced with their corresponding alert values. + +**Example** + +This Timeline template uses the `host.name: "{host.name}"` dropzone filter in +the rule. When alerts generated by the rule are investigated in Timeline, the +`{host.name}` value is replaced with the alert's `host.name` value. If the +alerts's `host.name` value is `Windows-ArsenalFC`, the Timeline dropzone query +is `host.name: "Windows-ArsenalFC"`. + +[NOTE] +==== +Refer to <> for information on creating Timelines and Timeline +templates. For information on how to add Timeline templates to rules, refer to <>. +==== diff --git a/docs/serverless/alerts/query-alert-indices.asciidoc b/docs/serverless/alerts/query-alert-indices.asciidoc new file mode 100644 index 0000000000..8ed9b1ce41 --- /dev/null +++ b/docs/serverless/alerts/query-alert-indices.asciidoc @@ -0,0 +1,21 @@ +[[query-alert-indices]] += Query alert indices + +:description: Index patterns for querying alert data. +:keywords: serverless, security, how-to + +preview:[] + +This page explains how you should query alert indices, for example, when building rule queries, custom dashboards, or visualizations. For more information about alert event field definitions, review the <>. + +[discrete] +[[query-alert-indices-alert-index-aliases]] +== Alert index aliases + +We recommend querying the `.alerts-security.alerts-` index alias. You should not include a dash or wildcard after the space ID. To query all spaces, use the following syntax: `.alerts-security.alerts-*`. + +[discrete] +[[query-alert-indices-alert-indices]] +== Alert indices + +For additional context, alert events are stored in hidden {es} indices. We do not recommend querying them directly. The naming convention for these indices and their aliases is `.internal.alerts-security.alerts--NNNNNN`, where `NNNNNN` is a number that increases over time, starting from 000001. diff --git a/docs/serverless/alerts/reduce-notifications-alerts.asciidoc b/docs/serverless/alerts/reduce-notifications-alerts.asciidoc new file mode 100644 index 0000000000..f656a7f85c --- /dev/null +++ b/docs/serverless/alerts/reduce-notifications-alerts.asciidoc @@ -0,0 +1,33 @@ +[[reduce-notifications-alerts]] += Reduce notifications and alerts + +:description: A comparison of alert-reduction features. +:keywords: serverless, security, how-to + +preview:[] + +{elastic-sec} offers several features to help reduce the number of notifications and alerts generated by your detection rules. This table provides a general comparison of these features, with links for more details: + +|=== +| | + +| <> +a| **_Stops a specific rule's notification actions from running_**. + +Use to avoid unnecessary notifications from a specific rule. The rule continues to run and generate alerts during the snooze period, but its <> don't run. + +| {kibana-ref}/maintenance-windows.html[Maintenance window] +a| **_Prevents all rules' notification actions from running_**. + +Use to avoid false alarms and unnecessary notifications during planned outages. All rules continue to run and generate alerts during the maintenance window, but their <> don't run. + +| <> +a| **_Reduces repeated or duplicate alerts_**. + +Use to reduce the number of alerts created when a rule meets its criteria repeatedly. Duplicate qualifying events are grouped, and only one alert is created for each group. + +| <> +a| **_Prevents a rule from creating alerts under specific conditions_**. + +Use to reduce false positive alerts by preventing trusted processes and network activity from generating unnecessary alerts. You can configure an exception to be used by a single rule or shared among multiple rules, but they typically don't affect _all_ rules. +|=== diff --git a/docs/serverless/alerts/signals-to-cases.asciidoc b/docs/serverless/alerts/signals-to-cases.asciidoc new file mode 100644 index 0000000000..88f570c2fa --- /dev/null +++ b/docs/serverless/alerts/signals-to-cases.asciidoc @@ -0,0 +1,70 @@ +[[signals-to-cases]] += Add detection alerts to cases + +:description: Add alerts to new or existing cases in {elastic-sec}. +:keywords: serverless, security, how-to, analyze + +++++ +Add alerts to cases +++++ + +preview:[] + +From the Alerts table, you can attach one or more alerts to a <> or <>. Alerts from any rule type can be added to a case. + +[NOTE] +==== +* After you add an alert to a case, you can remove it from the case activity under the alert summary or by using the {security-guide}/cases-api-overview.html[{elastic-sec} Cases API]. +* Each case can have a maximum of 1,000 alerts. + +// Link to classic docs until serverless API docs are available. +==== + +[role="screenshot"] +image::images/signals-to-cases/-detections-add-alert-to-case.gif[Animation of adding an alert to a case] + +[discrete] +[[signals-to-new-cases]] +== Add alerts to a new case + +To add alerts to a new case: + +. Do one of the following: ++ +** To add a single alert to a case, select the **More actions** menu (_..._) in the Alerts table or **Take action** in the alert details flyout, then select **Add to a new case**. +** To add multiple alerts, select the alerts, then select **Add to a new case** from the **Bulk actions** menu. +. Give the case a name, assign a severity level, and provide a description. You can use +https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax[Markdown] syntax in the case description. ++ +[NOTE] +==== +If you do not assign your case a severity level, it will be assigned **Low** by default. +==== +. Optionally, add a category, assignees and relevant tags. You can add users only if they +meet the necessary <>. +. Specify whether you want to sync the status of associated alerts. It is enabled by default; however, you can toggle this setting on or off at any time. If it remains enabled, the alert's status updates whenever the case's status is modified. +. Select a connector. If you've previously added one, that connector displays as the default selection. Otherwise, the default setting is `No connector selected`. +. Click **Create case** after you've completed all of the required fields. A confirmation message is displayed with an option to view the new case. Click the link in the notification or go to the Cases page to view the case. ++ +[role="screenshot"] +image:images/signals-to-cases/-detections-add-alert-to-new-case.png[Create case flyout with sample data filled in] + +[discrete] +[[signals-to-existing-cases]] +== Add alerts to an existing case + +To add alerts to an existing case: + +. Do one of the following: ++ +** To add a single alert to a case, select the **More actions** menu (_..._) in the Alerts table or **Take action** in the alert details flyout, then select **Add to existing case**. +** To add multiple alerts, select the alerts, then select **Add to an existing case** from the **Bulk actions** menu. +. From the **Select case** dialog box, select the case to which you want to attach the alert. A confirmation message is displayed with an option to view the updated case. Click the link in the notification or go to the Cases page to view the case's details. ++ +[NOTE] +==== +If you attach the alert to a case that has been configured to sync its status with associated alerts, the alert's status updates any time the case's status is modified. +==== ++ +[role="screenshot"] +image::images/signals-to-cases/-detections-add-alert-to-existing-case.png[Select case dialog listing existing cases] diff --git a/docs/serverless/alerts/view-alert-details.asciidoc b/docs/serverless/alerts/view-alert-details.asciidoc new file mode 100644 index 0000000000..b9a9842589 --- /dev/null +++ b/docs/serverless/alerts/view-alert-details.asciidoc @@ -0,0 +1,292 @@ +[[view-alert-details]] += View detection alert details + +:description: Expand an alert to view detailed alert data. +:keywords: serverless, security, defend, reference, manage + +++++ +View alert details +++++ + +preview:[] + +To learn more about an alert, click the **View details** button from the Alerts table. This opens the alert details flyout, which helps you understand and manage the alert. + +[role="screenshot"] +image::images/view-alert-details/-detections-open-alert-details-flyout.gif[Expandable flyout] + +Use the alert details flyout to begin an investigation, open a case, or plan a response. Click **Take action** at the bottom of the flyout to find more options for interacting with the alert. + +[discrete] +[[alert-details-flyout-ui]] +== Alert details flyout UI + +The alert details flyout has a right panel, a preview panel, and a left panel. Each panel provides a different perspective of the alert. + +[discrete] +[[right-panel]] +=== Right panel + +The right panel provides an overview of the alert. Expand any of the collapsed sections to learn more about the alert. You can also hover over fields on the **Overview** and **Table** tabs to display available <>. + +[role="screenshot"] +image::images/view-alert-details/-detections-alert-details-flyout-right-panel.png[Right panel of the alert details flyout] + +From the right panel, you can also: + +* Click **Expand details** to open the <>, which shows more information about sections in the right panel. +* Click the **Chat** icon (image:images/icons/discuss.svg[Chat]) to access the <>. +* Click the **Share alert** icon (image:images/icons/share.svg[Share alert]) to get a shareable alert URL. We _do not_ recommend copying the URL from your browser's address bar, which can lead to inconsistent results if you've set up filters or relative time ranges for the Alerts page. ++ +[NOTE] +==== +If you've configured the {kibana-ref}/settings.html#server-publicBaseUrl[`server.publicBaseUrl`] setting in the `kibana.yml` file, the shareable URL is also in the `kibana.alert.url` field. You can find the field by searching for `kibana.alert.url` on the **Table** tab. +==== ++ +[IMPORTANT] +==== +If you've enabled grouping on the Alerts page, the alert details flyout won't open until you expand a collapsed group and select an individual alert. +==== +* Find basic details about the alert, such as the: ++ +** Associated rule +** Alert status +** Date and time the alert was created +** Alert severity and risk score (these are inherited from rule that generated the alert) +** Users assigned to the alert (click the image:images/icons/plusInCircle.svg[Assign alert] icon to assign more users) +* Click the **Table** or **JSON** tabs to display the alert details in table or JSON format. In table format, alert details are displayed as field-value pairs. + +[discrete] +[[preview-panel]] +=== Preview panel + +Some areas in the flyout provide previews when you click on them. For example, clicking **Show rule summary** in the rule description displays a preview of the rule's details. To close the preview, click **x**. + +[role="screenshot"] +image::images/view-alert-details/-detections-alert-details-flyout-preview-panel.gif[Preview panel of the alert details flyout] + +[discrete] +[[left-panel]] +=== Left panel + +The left panel provides an expanded view of what's shown in the right panel. To open the left panel, do one of the following: + +* Click **Expand details** at the top of the right panel. ++ +[role="screenshot"] +image:images/view-alert-details/-detections-expand-details-button.png[Expand details button at the top of the alert details flyout] +* Click one of the section titles on the **Overview** tab within the right panel. ++ +[role="screenshot"] +image:images/view-alert-details/-detections-alert-details-flyout-left-panel.png[Left panel of the alert details flyout] + +[discrete] +[[about-section]] +== About + +The About section is located on the **Overview** tab in the right panel. It provides a brief description of the rule that's related to the alert and an explanation of what generated the alert. + +[role="screenshot"] +image::images/view-alert-details/-detections-about-section-rp.png[About section of the Overview tab] + +The About section has the following information: + +* **Rule description**: Describes the rule's purpose or detection goals. Click **Show rule summary** to display a preview of the rule's details. From the preview, click **Show rule details** to view the rule's details page. +* **Alert reason**: Describes the source event that generated the alert. Event details are displayed in plain text and ordered logically to provide context for the alert. Click **Show full reason** to display the alert reason in the event rendered format within the <>. ++ +[NOTE] +==== +The event renderer only displays if an event renderer exists for the alert type. Fields are interactive; hover over them to access the available actions. +==== +* **Last Alert Status Change**: Shows the last time the alert's status was changed, along with the user who changed it. +* **MITRE ATT&CK**: Provides relevant https://attack.mitre.org/[MITRE ATT&CK] framework tactics, techniques, and sub-techniques. + +[discrete] +[[investigation-section]] +== Investigation + +The Investigation section is located on the **Overview** tab in the right panel. It offers a couple of ways to begin investigating the alert. + +[role="screenshot"] +image::images/view-alert-details/-detections-investigation-section-rp.png[Investigation section of the Overview tab] + +The Investigation section provides the following information: + +* **Investigation guide**: The **Show investigation guide** button displays if the rule associated with the alert has an investigation guide. Click the button to open the expanded Investigation view in the left panel. ++ +[TIP] +==== +Add an <> to a rule when creating a new custom rule or modifying an existing custom rule's settings. +==== +* **Highlighted fields**: Shows relevant fields for the alert and any <> you added to the rule. Custom highlighted fields with values are added to this section. Those without values aren't added. + +[discrete] +[[visualizations-section]] +== Visualizations + +The Visualizations section is located on the **Overview** tab in the right panel. It offers a glimpse of the processes that led up to the alert and occurred after it. + +[role="screenshot"] +image::images/view-alert-details/-detections-visualizations-section-rp.png[Visualizations section of the Overview tab] + +Click **Visualizations** to display the following previews: + +* **Session view preview**: Shows a preview of <> data. Click **Session viewer preview** to open the **Session View** tab in Timeline. +* **Analyzer preview**: Shows a preview of the <>. The preview displays up to three levels of the analyzed event's ancestors and up to three levels of the event's descendants and children. The ellipses symbol (**`...`**) indicates the event has more ancestors and descendants to examine. Click **Analyzer preview** to open the **Event Analyzer** tab in Timeline. + +[discrete] +[[insights-section]] +== Insights + +The Insights section is located on the **Overview** tab in the right panel. It offers different perspectives from which you can assess the alert. Click **Insights** to display overviews for <>, <>, <>, and <>. + +[role="screenshot"] +image::images/view-alert-details/-detections-insights-section-rp.png[Insights section of the Overview tab] + +[discrete] +[[entities-overview]] +=== Entities + +The Entities overview provides high-level details about the user and host that are related to the alert. Host and user risk classifications are also available if you have the Security Analytics Complete https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature]. + +[role="screenshot"] +image::images/view-alert-details/-detections-entities-overview.png[Overview of the entity details section in the right panel] + +[discrete] +[[expanded-entities-view]] +==== Expanded entities view + +From the right panel, click **Entities** to open a detailed view of the host and user associated with the alert. The expanded view also includes risk scores and classifications (if you have the Security Analytics Complete https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature]) and activity on related hosts and users. + +[role="screenshot"] +image::images/view-alert-details/-detections-expanded-entities-view.png[Expanded view of entity details] + +[discrete] +[[threat-intelligence-overview]] +=== Threat intelligence + +The Threat intelligence overview shows matched indicators, which provide threat intelligence relevant to the alert. + +[role="screenshot"] +image::images/view-alert-details/-detections-threat-intelligence-overview.png[Overview of threat intelligence on the alert] + +The Threat intelligence overview provides the following information: + +* **Threat match detected**: Only available when examining an alert generated from an <> rule. Shows the number of matched indicators that are present in the alert document. Shows zero if there are no matched indicators or you're examining an alert generated by another type of rule. +* **Fields enriched with threat intelligence**: Shows the number of matched indicators that are present on an alert that _wasn't_ generated from an indicator match rule. If none exist, the total number of matched indicators is zero. + +[discrete] +[[expanded-threat-intel-view]] +==== Expanded threat intelligence view + +From the right panel, click **Threat intelligence** to open the expanded Threat intelligence view within the left panel. + +[NOTE] +==== +The expanded threat intelligence view queries indices specified in the `securitySolution:defaultThreatIndex` advanced setting. Refer to <> to learn more about threat intelligence indices. +==== + +[role="screenshot"] +image::images/view-alert-details/-detections-expanded-threat-intelligence-view.png[Expanded view of threat intelligence on the alert] + +The expanded Threat intelligence view shows individual indicators within the alert document. You can expand and collapse indicator details by clicking the arrow button at the end of the indicator label. Each indicator is labeled with values from the `matched.field` and `matched.atomic` fields and displays the threat intelligence provider. + +Matched threats are organized into two sections, described below. Within each section, matched threats are shown in reverse chronological order, with the most recent at the top. All mapped fields are displayed for each matched threat. + +**Threat match detected** + +The Threat match detected section is only populated with indicator match details if you're examining an alert that was generated from an indicator match rule. Indicator matches occur when alert field values match with threat intelligence data you've ingested. + +**Fields enriched with threat intelligence** + +Threat intelligence can also be found on alerts that weren't generated from indicator match rules. To find this information, {elastic-sec} queries alert documents from the past 30 days and searches for fields that contain known threat intelligence. If any are found, they're logged in this section. + +[TIP] +==== +Use the date time picker to modify the query time frame, which looks at the past 30 days by default. You can also click the **Inspect** button to examine the query that the Fields enriched with threat intelligence section uses. +==== + +When searching for threat intelligence, {elastic-sec} queries the alert document for the following fields: + +* `file.hash.md5`: The MD5 hash +* `file.hash.sha1`: The SHA1 hash +* `file.hash.sha256`: The SHA256 hash +* `file.pe.imphash`: Imports in a PE file +* `file.elf.telfhash`: Imports in an ELF file +* `file.hash.ssdeep`: The SSDEEP hash +* `source.ip`: The IP address of the source (IPv4 or IPv6) +* `destination.ip`: The event's destination IP address +* `url.full`: The full URL of the event source +* `registry.path`: The full registry path, including the hive, key, and value + +[discrete] +[[correlations-overview]] +=== Correlations + +The Correlations overview shows how an alert is related to other alerts and offers ways to investigate related alerts. Use this information to quickly find patterns between alerts and then take action. + +[role="screenshot"] +image::images/view-alert-details/-detections-correlations-overview.png[Overview of available correlation data] + +The Correlations overview provides the following information: + +* **Suppressed alerts**: Indicates that the alert was created with alert suppression, and shows how many duplicate alerts were suppressed. This information only appears if alert suppression is enabled for the rule. +* **Alerts related by source event**: Shows the number of alerts that were created by the same source event. +* **Cases related to the alert**: Shows the number of cases to which the alert has been added. +* **Alerts related by session ID**: Shows the number of alerts generated by the same session. +* **Alerts related by process ancestry**: Shows the number of alerts that are related by process events on the same linear branch. + +[discrete] +[[expanded-correlations-view]] +==== Expanded correlations view + +From the right panel, click **Correlations** to open the expanded Correlations view within the left panel. + +[role="screenshot"] +image::images/view-alert-details/-detections-expanded-correlations-view.png[Expanded view of correlation data] + +In the expanded view, corelation data is organized into several tables: + +* **Suppressed alerts**: preview:[] Shows how many duplicate alerts were suppressed. This information only appears if alert suppression is enabled for the rule. +* **Related cases**: Shows cases to which the alert has been added. Click a case's name to open its details. +* **Alerts related by source event**: Shows alerts created by the same source event. This can help you find alerts with a shared origin and provide more context about the source event. Click the **Investigate in timeline** button to examine related alerts in Timeline. +* **Alerts related by session**: Shows alerts generated during the same <>. These alerts share the same session ID, which is a unique ID for tracking a given Linux session. To use this feature, you must enable the **Collect session data** setting in your {elastic-defend} integration policy. Refer to <> for more information. +* **Alerts related by ancestry**: Shows alerts that are related by process events on the same linear branch. Note that alerts generated from processes on child or related branches are not shown. To further examine alerts, click **Investigate in timeline**. + +[discrete] +[[prevalence-overview]] +=== Prevalence + +The Prevalence overview shows whether data from the alert was frequently observed on other host events from the last 30 days. Prevalence calculations use values from the alert’s highlighted fields. Highlighted field values that are observed on less than 10% of hosts in your environment are considered uncommon (not prevalent) and are listed individually in the Prevalence overview. Highlighted field values that are observed on more than 10% of hosts in your environment are considered common (prevalent) and are described as frequently observed in the Prevalence overview. + +[discrete] +[[expanded-prevalence-view]] +==== Expanded prevalence view + +From the right panel, click **Prevalence** to open the expanded Prevalence view within the left panel. Examine the table to understand the alert's relationship with other alerts, events, users, and hosts. + +[TIP] +==== +Update the date time picker for the table to show data from a different time range. +==== + +[role="screenshot"] +image::images/view-alert-details/-detections-expanded-prevalence-view.png[Expanded view of prevalence data] + +The expanded Prevalence view provides the following details: + +* **Field**: Shows <> for the alert and any custom highlighted fields that were added to the alert's rule. +* **Value**: Shows values for highlighted fields and any custom highlighted fields that were added to the alert's rule. +* **Alert count**: Shows the total number of alert documents that have identical highlighted field values, including the alert you're currently examining. For example, if the `host.name` field has an alert count of 5, that means there are five total alerts with the same `host.name` value. The Alert count column only retrieves documents that contain the {ecs-ref}/ecs-allowed-values-event-kind.html#ecs-event-kind-signal[`event.kind:signal`] field-value pair. +* **Document count**: Shows the total number of event documents that have identical field values. A dash (`——`) displays if there are no event documents that match the field value. The Document count column only retrieves documents that don't contain the {ecs-ref}/ecs-allowed-values-event-kind.html#ecs-event-kind-signal[`event.kind:signal`] field-value pair. +* **Host prevalence**: Shows the percentage of unique hosts that have identical field values. Host prevalence for highlighted fields is calculated by taking the number of unique hosts with identical highlighted field values and dividing that number by the total number of unique hosts in your environment. +* **User prevalence**: Shows the percentage of unique users that have identical highlighted field values. User prevalence for highlighted fields is calculated by taking the number of unique users with identical field values and dividing that number by the total number of unique users in your environment. + +[discrete] +[[response-overview]] +== Response + +The **Response** section is located on the **Overview** tab in the right panel. It shows <> that were added to the rule associated with the alert. Click **Response** to display the response action's results in the left panel. + +[role="screenshot"] +image::images/view-alert-details/-detections-response-action-rp.png[Response section of the Overview tab] diff --git a/docs/serverless/alerts/visual-event-analyzer.asciidoc b/docs/serverless/alerts/visual-event-analyzer.asciidoc new file mode 100644 index 0000000000..e8dfa373b2 --- /dev/null +++ b/docs/serverless/alerts/visual-event-analyzer.asciidoc @@ -0,0 +1,151 @@ +[[visual-event-analyzer]] += Visual event analyzer + +:description: Examine events and processes in a graphical timeline. +:keywords: serverless, security, how-to + +preview:[] + +{elastic-sec} allows any event detected by {elastic-endpoint} to be analyzed using a process-based visual analyzer, which shows a graphical timeline of processes that led up to the alert and the events that occurred immediately after. Examining events in the visual event analyzer is useful to determine the origin of potentially malicious activity and other areas in your environment that may be compromised. It also enables security analysts to drill down into all related hosts, processes, and other events to aid in their investigations. + +[TIP] +==== +If you're experiencing performance degradation, you can <> from analyzer queries. +==== + +[discrete] +[[find-events-analyze]] +== Find events to analyze + +You can only visualize events triggered by hosts configured with the {elastic-defend} integration or any `sysmon` data from `winlogbeat`. + +In KQL, this translates to any event with the `agent.type` set to either: + +* `endpoint` +* `winlogbeat` with `event.module` set to `sysmon` + +To find events that can be visually analyzed: + +. First, display a list of events by doing one of the following: ++ +** Go to **Explore** → **Hosts**, then select the **Events** tab. A list of all your hosts' events appears at the bottom of the page. +** Go to **Alerts**, then scroll down to the Alerts table. +. Filter events that can be visually analyzed by entering either of the following queries in the KQL search bar, then selecting **Enter**: ++ +** `agent.type:"endpoint" and process.entity_id :*` ++ +Or +** `agent.type:"winlogbeat" and event.module: "sysmon" and process.entity_id : *` +. Events that can be visually analyzed are denoted by a cubical **Analyze event** icon. Select this option to open the event in the visual analyzer. ++ +[role="screenshot"] +image:images/visual-event-analyzer/-detections-analyze-event-button.png[Shows analyze event option] ++ +[NOTE] +==== +Events that cannot be analyzed will not have the **Analyze event** option available. This might occur if the event has incompatible field mappings. +==== ++ +[role="screenshot"] +image::images/visual-event-analyzer/-detections-analyze-event-timeline.png[] ++ +[TIP] +==== +You can also analyze events from <>. +==== + +[discrete] +[[visual-analyzer-ui]] +== Visual event analyzer UI + +Within the visual analyzer, each cube represents a process, such as an executable file or network event. Click and drag in the analyzer to explore the hierarchy of all process relationships. + +To understand what fields were used to create the process, select the **Process Tree** to show the schema that created the graphical view. The fields included are: + +* `SOURCE`: Can be either `endpoint` or `winlogbeat` +* `ID`: Event field that uniquely identifies a node +* `EDGE`: Event field which indicates the relationship between two nodes + +[role="screenshot"] +image::images/visual-event-analyzer/-detections-process-schema.png[] + +Click the **Legend** to show the state of each process node. + +[role="screenshot"] +image::images/visual-event-analyzer/-detections-node-legend.png[] + +Use the date and time filter to analyze the event within a specific time range. By default, the selected time range matches that of the table from which you opened the alert. + +[role="screenshot"] +image::images/visual-event-analyzer/-detections-date-range-selection.png[] + +Select a different data view to further filter the alert's related events. + +[role="screenshot"] +image::images/visual-event-analyzer/-detections-data-view-selection.png[] + +To expand the analyzer to a full screen, select the **Full Screen** icon above the left panel. + +[role="screenshot"] +image::images/visual-event-analyzer/-detections-full-screen-analyzer.png[] + +The left panel contains a list of all processes related to the event, starting with the event chain's first process. **Analyzed Events** — the event you selected to analyze from the events list or Timeline — are highlighted with a light blue outline around the cube. + +[role="screenshot"] +image::images/visual-event-analyzer/-detections-process-list.png[] + +In the graphical view, you can: + +* Zoom in and out of the graphical view using the slider on the far right +* Click and drag around the graphical view to more process relationships +* Observe child process events that spawned from the parent process +* Determine how much time passed between each process +* Identify all events related to each process + +[role="screenshot"] +image::images/visual-event-analyzer/-detections-graphical-view.png[] + +[discrete] +[[process-and-event-details]] +== Process and event details + +To learn more about each related process, select the process in the left panel or the graphical view. The left panel displays process details such as: + +* The number of events associated with the process +* The timestamp of when the process was executed +* The file path of the process within the host +* The `process-pid` +* The user name and domain that ran the process +* Any other relevant process information +* Any associated alerts + +[role="screenshot"] +image::images/visual-event-analyzer/-detections-process-details.png[] + +When you first select a process, it appears in a loading state. If loading data for a given process fails, click **Reload `{process_name}`** beneath the process to reload the data. + +Access event details by selecting that event's URL at the top of the process details view or choosing one of the event pills in the graphical view. + +Events are categorized based on the `event.category` value. + +[role="screenshot"] +image::images/visual-event-analyzer/-detections-event-type.png[] + +When you select an `event.category` pill, all the events within that category are listed in the left panel. To display more details about a specific event, select it from the list. + +[role="screenshot"] +image::images/visual-event-analyzer/-detections-event-details.png[] + +[NOTE] +==== +There is no limit to the number of events that can be associated with a process. +==== + +You can also examine alerts associated with events. + +To examine alerts associated with the event, select the alert pill (**_x_ alert**). The left pane lists the total number of associated alerts, and alerts are ordered from oldest to newest. Each alert shows the type of event that produced it (`event.category`), the event timestamp (`@timestamp`), and rule that generated the alert (`kibana.alert.rule.name`). Click on the rule name to open the alert's details. + +In the example screenshot below, five alerts were generated by the analyzed event (`lsass.exe`). The left pane displays the associated alerts and basic information about each one. + +[role="screenshot"] +image::images/visual-event-analyzer/-detections-alert-pill.png[] diff --git a/docs/serverless/alerts/visualize-alerts.asciidoc b/docs/serverless/alerts/visualize-alerts.asciidoc new file mode 100644 index 0000000000..2099a0f206 --- /dev/null +++ b/docs/serverless/alerts/visualize-alerts.asciidoc @@ -0,0 +1,106 @@ +[[visualize-alerts]] += Visualize detection alerts + +:description: Display alert trends and distributions on the Alerts page. +:keywords: serverless, security, how-to + +++++ +Visualize alerts +++++ + +preview:[] + +Visualize and group detection alerts by specific parameters in the visualization section of the Alerts page. + +[role="screenshot"] +image::images/visualize-alerts/-detections-alert-page-visualizations.png[Alerts page with visualizations section highlighted] + +Use the left buttons to select a view type (**Summary**, **Trend**, **Counts**, or **Treemap**), and use the right menus to select the ECS fields to use for grouping: + +* **Top alerts by** or **Group by**: Primary field for grouping alerts. +* **Group by top** (if available): Secondary field for further subdividing grouped alerts. + +For example, you can group first by rule name (`Group by: kibana.alert.rule.name`), then by host name (`Group by top: host.name`) to visualize which detection rules generated alerts, and which hosts triggered each of those rules. For groupings with a lot of unique values, the top 1,000 results are displayed. + +[NOTE] +==== +Some view types don't have the **Group by top** option. You can also leave **Group by top** blank to group by only the primary field in **Group by**. +==== + +To reset a view to default settings, hover over it and click the options menu (image:images/icons/boxesHorizontal.svg[More actions]) that appears, then select **Reset group by fields**. + +[TIP] +==== +The options menu also lets you inspect the visualization's queries. For the trend and counts views, you can add the visualization to a new or existing case, or open it in Lens. +==== + +Click the collapse icon (image:images/icons/arrowDown.svg[Markdown]) to minimize the visualization section and display a summary of key information instead. + +[role="screenshot"] +image::images/visualize-alerts/-detections-alert-page-viz-collapsed.png[Alerts page with visualizations section collapsed] + +[discrete] +[[visualize-alerts-summary]] +== Summary + +On the Alerts page, the summary visualization displays by default and shows how alerts are distributed across these indicators: + +* **Severity levels**: How many alerts are in each severity level. +* **Alerts by name**: How many alerts each detection rule created. +* **Top alerts by**: Percentage of alerts with a specified field value: `host.name` (default), `user.name`, `source.ip`, or `destination.ip`. + +You can hover and click on elements within the summary — such as severity levels, rule names, and host names — to add filters with those values to the Alerts page. + +[role="screenshot"] +image::images/visualize-alerts/-detections-alerts-viz-summary.png[Summary visualization for alerts] + +[discrete] +[[visualize-alerts-trend]] +== Trend + +The trend view shows the occurrence of alerts over time. By default, it groups alerts by detection rule name (`kibana.alert.rule.name`). + +[NOTE] +==== +The **Group by top** menu is unavailable for the trend view. +==== + +[role="screenshot"] +image::images/visualize-alerts/-detections-alerts-viz-trend.png[Trend visualization for alerts] + +[discrete] +[[visualize-alerts-counts]] +== Counts + +The counts view shows the count of alerts in each group. By default, it groups alerts first by detection rule name (`kibana.alert.rule.name`), then by host name (`host.name`). + +[role="screenshot"] +image::images/visualize-alerts/-detections-alerts-viz-counts.png[Counts visualization for alerts] + +[discrete] +[[visualize-alerts-treemap]] +== Treemap + +The treemap view shows the distribution of alerts as nested, proportionally-sized tiles. This view can help you quickly pinpoint the most prevalent and critical alerts. + +[role="screenshot"] +image::images/visualize-alerts/-detections-alerts-viz-treemap.png[Treemap visualization for alerts] + +Larger tiles represent more frequent alerts, and each tile's color is based on the alerts' risk score: + +* **Green**: Low risk (`0` - `46`) +* **Yellow**: Medium risk (`47` - `72`) +* **Orange**: High risk (`73` - `98`) +* **Red**: Critical risk (`99` - `100`) + +By default, the treemap groups alerts first by detection rule name (`kibana.alert.rule.name`), then by host name (`host.name`). This shows which rules generated the most alerts, and which hosts were responsible. + +[NOTE] +==== +Depending on the amount of alerts, some tiles and text might be very small. Hover over the treemap to display information in a tooltip. +==== + +You can click on the treemap to narrow down the alerts displayed in both the treemap and the alerts table below. Click the label above a group to display the alerts in that group, or click an individual tile to display the alerts related to that tile. This adds filters under the KQL search bar, which you can edit or remove to further customize the view. + +[role="screenshot"] +image::images/visualize-alerts/-detections-treemap-click.gif[Animation of clicking the treemap] diff --git a/docs/serverless/assets/asset-management.asciidoc b/docs/serverless/assets/asset-management.asciidoc new file mode 100644 index 0000000000..3559c91948 --- /dev/null +++ b/docs/serverless/assets/asset-management.asciidoc @@ -0,0 +1,13 @@ +[[asset-management]] += Asset management + +:keywords: serverless, security, overview, manage + +preview:[] + +The **Assets** page allows you to manage the following features: + +* {fleet-guide}/manage-agents-in-fleet.html[{fleet}] +* {fleet-guide}/integrations.html[{integrations}] +* <> +* <> diff --git a/docs/serverless/billing.asciidoc b/docs/serverless/billing.asciidoc new file mode 100644 index 0000000000..e9eb1a6492 --- /dev/null +++ b/docs/serverless/billing.asciidoc @@ -0,0 +1,69 @@ +[[security-billing]] += Security billing dimensions + +:description: Learn about how Security usage affects pricing. +:keywords: serverless, security, overview + +preview:[] + +{elastic-sec} serverless projects provide you with all the capabilities of {elastic-sec} to perform SIEM, security analytics, endpoint security, and cloud security workflows. Projects are provided using a Software as a Service (SaaS) model, and pricing is entirely consumption based. Security Analytics/SIEM is available in two tiers of carefully selected features to enable common security operations: + +* **Security Analytics Essentials** — Includes everything you need to operationalize traditional SIEM in most organizations. +* **Security Analytics Complete** — Adds advanced security analytics and AI-driven features that many organizations will require when upgrading or replacing legacy SIEM systems. + +Your monthly bill is based on the capabilities you use. When you use Security Analytics/SIEM, your bill is calculated based on data volume, which has these components: + +* **Ingest** — Measured by the number of GB of log/event/info data that you send to your Security project over the course of a month. +* **Retention** — Measured by the total amount of ingested data stored in your Security project. + +Data volumes for both ingest and retention are based on the uncompressed data size at the point of ingest, before {es} compression is performed, and will be higher than the volumes traditionally reported by {es} index size. In addition, these volumes might be larger than the volumes reported by cloud provider proxy logs for data going into {es}. + +[discrete] +[[security-billing-endpoint-protection]] +== Endpoint Protection + +Endpoint Protection is an _optional_ add-on to Security Analytics that provides on-endpoint protection and prevention. Endpoint Protection is available in two tiers of selected features to enable common endpoint security operations: + +* **Endpoint Protection Essentials** — Includes robust protection against malware, ransomware, and other malicious behaviors. +* **Endpoint Protection Complete** — Adds endpoint response actions and advanced policy management. + +You pay based on the number of protected endpoints you configure with the {elastic-defend} integration. Note that logs, events, and alerts ingested into your Security project from endpoints running {elastic-defend} are billed using the **Ingest** and **Retention** pricing described above. + +[discrete] +[[security-billing-cloud-protection]] +== Cloud Protection + +Cloud Protection is an _optional_ add-on to Security Analytics that provides value-added protection capabilities for cloud assets. Cloud Protection is available in two tiers of carefully selected features to enable common cloud security operations: + +* **Cloud Protection Essentials** — Protects your cloud workloads, continuously tracks posture of your cloud assets, and helps you manage risks by detecting configuration issues per CIS benchmarks. +* **Cloud Protection Complete** — Adds response capabilities and configuration drift prevention for Cloud Workloads. + +Your total cost depends on the number of protected cloud workloads and other billable cloud assets you configure for use with Elastic Cloud Security. + +For <>, billing is based on how many billable resources (`resource.id`s) you monitor. The following types of assets are considered billable: + +* VMs: ++ +** **AWS:** EC2 instances +** **Azure:** Virtual machines +** **GCP:** Compute engine instances +* Storage resources: ++ +** **AWS:** S3, S3 Glacier, EBS +** **Azure:** Archive, Blob, Managed disk +** **GCP:** Cloud storage, Persistent disk, Coldline storage +* SQL databases and servers: ++ +** **AWS:** RDS, DynamoDB, Redshift +** **Azure:** SQL database, Cosmos DB, Synapse Analytics +** **GCP:** Cloud SQL, Firestore, BigQuery + +For <>, billing is based on how many Kubernetes nodes (`agent.id`s) you monitor. + +For <>, billing is based on how many cloud assets (`cloud.instance.id`s) you monitor. + +For <>, billing is based on how many agents (`agent.id`s) you use. + +Logs, events, alerts, and configuration data ingested into your security project are billed using the **Ingest** and **Retention** pricing described above. + +For more details about {elastic-sec} serverless project rates and billable assets, refer to Cloud Protection in the https://cloud.elastic.co/cloud-pricing-table?productType=serverless&project=security[Elastic Cloud pricing table]. diff --git a/docs/serverless/cloud-native-security/benchmark-rules.asciidoc b/docs/serverless/cloud-native-security/benchmark-rules.asciidoc new file mode 100644 index 0000000000..cafc3bbbdc --- /dev/null +++ b/docs/serverless/cloud-native-security/benchmark-rules.asciidoc @@ -0,0 +1,53 @@ +[[benchmark-rules]] += Benchmarks + +:description: Review the cloud security benchmark rules used by the CSPM and KSPM integrations. +:keywords: serverless, security, overview, cloud security + +preview:[] + +The Benchmarks page lets you view the cloud security posture (CSP) benchmarks for the <> (CSPM) and <> (KSPM) integrations. + +[role="screenshot"] +image::images/benchmark-rules/-cloud-native-security-benchmark-rules.png[Benchmark rules page] + +[discrete] +[[benchmark-rules-what-are-benchmarks]] +== What are benchmarks? + +Each benchmark contains benchmark rules which are used by the CSPM and KSPM integrations to identify configuration risks in your cloud infrastructure. There are different benchmarks for different cloud services, such as AWS, GCP, or Azure. They are based on the Center for Internet Security's (CIS) https://www.cisecurity.org/cis-benchmarks/[secure configuration benchmarks]. + +Each benchmark rule checks to see if a specific type of resource is configured according to a CIS Benchmark. The names of rules describe what they check, for example: + +* `Ensure Kubernetes Secrets are encrypted using Customer Master Keys (CMKs) managed in AWS KMS` +* `Ensure the default namespace is not in use` +* `Ensure IAM policies that allow full "*:*" administrative privileges are not attached` +* `Ensure the default namespace is not in use` + +When benchmark rules are evaluated, the resulting <> data appears on the <>. + +[NOTE] +==== +Benchmark rules are not editable. +==== + +[discrete] +[[benchmark-rules-review-your-benchmarks]] +== Review your benchmarks + +To access your active benchmarks, go to **Rules -> Benchmarks**. From there, you can click a benchmark's name to view the benchmark rules associated with it. You can click a benchmark rule's name to see details including information about how to remediate it, and related links. + +Benchmark rules are enabled by default, but you can disable some of them — at the benchmark level — to suit your environment. This means for example that if you have two CSPM integrations using the `CIS AWS` benchmark, disabling a rule for that benchmark affects both integrations. To enable or disable a rule, use the **Enabled** toggle on the right of the rules table. + +[NOTE] +==== +Disabling a benchmark rule automatically disables any associated detection rules and alerts. Re-enabling a benchmark rule **does not** automatically re-enable them. +==== + +[discrete] +[[benchmark-rules-how-benchmark-rules-work]] +== How benchmark rules work + +. When a security posture management integration is deployed, and every four hours after that, {agent} fetches relevant cloud resources. +. After resources are fetched, they are evaluated against all applicable enabled benchmark rules. +. Finding values of `pass` or `fail` indicate whether the standards defined by benchmark rules were met. diff --git a/docs/serverless/cloud-native-security/cloud-native-security-overview.asciidoc b/docs/serverless/cloud-native-security/cloud-native-security-overview.asciidoc new file mode 100644 index 0000000000..83879cfa2e --- /dev/null +++ b/docs/serverless/cloud-native-security/cloud-native-security-overview.asciidoc @@ -0,0 +1,52 @@ +[[cloud-native-security-overview]] += Secure cloud native resources + +:description: Helps you improve your cloud security posture. +:keywords: serverless, security, overview, cloud security + +preview:[] + +Elastic Security for Cloud helps you improve your cloud security posture by comparing your cloud configuration to best practices, and scanning for vulnerabilities. It also helps you monitor and investigate your cloud workloads inside and outside Kubernetes. + +This page describes what each solution does and provides links to more information. + +[discrete] +[[cloud-native-security-overview-cloud-security-posture-management-cspm]] +== Cloud Security Posture Management (CSPM) + +Discovers and evaluates the services in your cloud environment — like storage, compute, IAM, and more — against configuration security guidelines defined by the https://www.cisecurity.org/[Center for Internet Security] (CIS) to help you identify and remediate risks that could undermine the confidentiality, integrity, and availability of your cloud data. + +<>. + +[discrete] +[[cloud-native-security-overview-kubernetes-security-posture-management-kspm]] +== Kubernetes Security Posture Management (KSPM) + +Allows you to identify configuration risks in the various components that make up your Kubernetes cluster. +It does this by evaluating your Kubernetes clusters against secure configuration guidelines defined by the Center for Internet Security (CIS) and generating findings with step-by-step instructions for remediating potential security risks. + +<>. + +[discrete] +[[cloud-native-security-overview-cloud-native-vulnerability-management-cnvm]] +== Cloud Native Vulnerability Management (CNVM) + +Scans your cloud workloads for known vulnerabilities. When it finds a vulnerability, it supports your risk assessment by quickly providing information such as the vulnerability's CVSS and severity, which software versions it affects, and whether a fix is available. + +<>. + +[discrete] +[[cloud-native-security-overview-cloud-workload-protection-for-kubernetes]] +== Cloud Workload Protection for Kubernetes + +Provides cloud-native runtime protections for containerized environments by identifying and (optionally) blocking unexpected system behavior in Kubernetes containers. These capabilities are sometimes referred to as container drift detection and prevention. The solution also captures detailed process and file telemetry from monitored containers, allowing you to set up custom alerts and protection rules. + +<>. + +[discrete] +[[cloud-native-security-overview-cloud-workload-protection-for-vms]] +== Cloud Workload Protection for VMs + +Helps you monitor and protect your Linux VMs. It uses {elastic-defend} to instantly detect and prevent malicious behavior and malware, and captures workload telemetry data for process, file, and network activity. You can use this data with Elastic's out-of-the-box detection rules and {ml} models. These detections generate alerts that quickly help you identify and remediate threats. + +<>. diff --git a/docs/serverless/cloud-native-security/cloud-workload-protection.asciidoc b/docs/serverless/cloud-native-security/cloud-workload-protection.asciidoc new file mode 100644 index 0000000000..3b459a08c8 --- /dev/null +++ b/docs/serverless/cloud-native-security/cloud-workload-protection.asciidoc @@ -0,0 +1,26 @@ +[[cloud-workload-protection]] += Cloud workload protection for VMs + +:description: Use cloud workload protection to monitor and protect your Linux VMs. +:keywords: serverless, security, overview, cloud security + +preview:[] + +Cloud workload protection helps you monitor and protect your Linux VMs. It uses the <> integration to capture cloud workload telemetry containing process, file, and network activity. + +Use this telemetry with out-of-the-box detection rules and machine learning models to automate processes that identify cloud threats. + +[discrete] +[[cloud-workload-protection-use-cases]] +== Use cases + +* **Runtime monitoring of cloud workloads:** Provides visibility into cloud workloads, context for detected threats, and the historical data needed for retroactive threat investigations. +* **Cloud-native threat detection and prevention:** Provides security coverage for Linux, containers, and serverless applications. Protects against known and unknown threats using on-host detections and protections against malicious behavior, memory threats, and malware. +* **Reducing the time to detect and remediate runtime threats:** Helps you resolve potential threats by showing alerts in context, making the data necessary for further investigations readily available, and providing remediation options. + +To continue setting up your cloud workload protection, learn more about: + +* <>: configure {elastic-defend} to protect your hosts. Be sure to select one of the "Cloud workloads" presets if you want to collect session data by default, including process, file, and network telemetry. +* <>: examine Linux process data organized in a tree-like structure according to the Linux logical event model, with processes organized by parentage and time of execution. Use it to monitor and investigate session activity, and to understand user and service behavior on your Linux infrastructure. +* <>: Explore an overview of your protected Kubernetes clusters, and drill down into individual sessions within your Kubernetes infrastructure. +* <>: Capture the environment variables associated with process events, such as `PATH`, `LD_PRELOAD`, or `USER`. diff --git a/docs/serverless/cloud-native-security/cspm-findings-page.asciidoc b/docs/serverless/cloud-native-security/cspm-findings-page.asciidoc new file mode 100644 index 0000000000..2c2b6106ff --- /dev/null +++ b/docs/serverless/cloud-native-security/cspm-findings-page.asciidoc @@ -0,0 +1,87 @@ +[[cspm-findings-page]] += Findings page + +:description: Review your cloud security posture management data. +:keywords: serverless, security, overview, cloud security + +preview:[] + +The **Misconfigurations** tab on the Findings page displays the configuration risks identified by the <> and <> integrations. + +[role="screenshot"] +image::images/findings-page/-cloud-native-security-findings-page.png[Findings page] + +[discrete] +[[cspm-findings-page-what-are-findings]] +== What are CSPM and KSPM findings? + +CSPM and KSPM findings indicate whether a given resource passed or failed evaluation against a specific security guideline. Each finding includes metadata about the resource evaluated and the security guideline used to evaluate it. Each finding's result (`pass` or `fail`) indicates whether a particular part of your infrastructure meets a security guideline. + +[discrete] +[[cspm-findings-page-group-filter]] +== Group and filter findings + +By default, the Findings page lists all findings, without grouping or filtering. + +[discrete] +[[cspm-findings-page-group-findings]] +=== Group findings + +Click **Group findings by** to group your data by a field. Select one of the suggested fields or **Custom field** to choose your own. You can select up to three group fields at once. + +* When grouping is turned on, click a group to expand it and examine all sub-groups or findings within that group. +* To turn off grouping, click **Group findings by** and select **None**. + +[NOTE] +==== +Multiple groupings apply to your data in the order you selected them. For example, if you first select **Cloud account**, then select **Resource**, the top-level grouping will be based on **Cloud account**, and its subordinate grouping will be based on **Resource**. +==== + +[discrete] +[[cspm-findings-page-filter-findings]] +=== Filter findings + +You can filter findings data in two ways: + +* **KQL search bar**: For example, search for `result.evaluation : failed` to view all failed findings. +* **In-table value filters**: Hover over a finding to display available inline actions. Use the **Filter In** (plus) and **Filter Out** (minus) buttons. + +[discrete] +[[cspm-findings-page-customize-the-findings-table]] +== Customize the Findings table + +You can use the toolbar buttons in the upper-left of the Findings table to select which columns appear: + +* **Columns**: Select the left-to-right order in which columns appear. +* **Sort fields**: Sort the table by one or more columns, or turn sorting off. +* **Fields**: Select which fields to display for each finding. Selected fields appear in the table and the **Columns** menu. + +[TIP] +==== +You can also click a column's name to open a menu that allows you to perform multiple actions on the column. +==== + +[discrete] +[[cspm-findings-page-remediate-findings]] +== Remediate failed findings + +To remediate failed findings and reduce your attack surface: + +. First, <>. +. Click the arrow to the left of a failed finding to open the findings flyout. +. Follow the steps under **Remediation**. ++ +[NOTE] +==== +Remediation steps typically include commands for you to execute. These sometimes contain placeholder values that you must replace before execution. +==== + +[discrete] +[[cspm-create-rule-from-finding]] +== Generate alerts for failed Findings + +You can create detection rules that detect specific failed findings directly from the Findings page. + +. Click the arrow to the left of a Finding to open the findings flyout. +. Click **Take action**, then **Create a detection rule**. This automatically creates a detection rule that creates alerts when the associated benchmark rule generates a failed finding. +. To review or customize the new rule, click **View rule**. diff --git a/docs/serverless/cloud-native-security/cspm-get-started-azure.asciidoc b/docs/serverless/cloud-native-security/cspm-get-started-azure.asciidoc new file mode 100644 index 0000000000..b811a3381b --- /dev/null +++ b/docs/serverless/cloud-native-security/cspm-get-started-azure.asciidoc @@ -0,0 +1,179 @@ +[[cspm-get-started-azure]] += Get started with CSPM for Azure + +:description: Start monitoring the security posture of your Azure cloud assets. +:keywords: serverless, security, overview, cloud security + +preview:[] + +[discrete] +[[cspm-overview-azure]] +== Overview + +This page explains how to get started monitoring the security posture of your cloud assets using the Cloud Security Posture Management (CSPM) feature. + +.Requirements +[NOTE] +==== +* CSPM only works in the `Default` {kib} space. Installing the CSPM integration on a different {kib} space will not work. +* CSPM is supported only on AWS, GCP, and Azure commercial cloud platforms, and AWS GovCloud. Other government cloud platforms are not supported (https://github.com/elastic/kibana/issues/new/choose[request support]). +* To view posture data, you need `read` privileges for the following {es} indices: ++ +** `logs-cloud_security_posture.findings_latest-*` +** `logs-cloud_security_posture.scores-*` +** `logs-cloud_security_posture.findings` +* The user who gives the CSPM integration permissions in Azure must be an Azure subscription `admin`. +==== + +[discrete] +[[cspm-setup-azure]] +== Set up CSPM for Azure + +You can set up CSPM for Azure by by enrolling an Azure organization (management group) containing multiple subscriptions, or by enrolling a single subscription. Either way, first add the CSPM integration, then enable cloud account access. + +[discrete] +[[cspm-add-and-name-integration-azure]] +=== Add your CSPM integration + +. From the Elastic Security **Get started** page, click **Add integrations**. +. Search for `CSPM`, then click on the result. +. Click **Add Cloud Security Posture Management (CSPM)**. +. Under **Configure integration**, select **Azure**, then select either **Azure Organization** or **Single Subscription**, depending on which resources you want to monitor. +. Give your integration a name that matches the purpose or team of the Azure resources you want to monitor, for example, `azure-CSPM-dev-1`. + +[discrete] +[[cspm-set-up-cloud-access-section-azure]] +=== Set up cloud account access + +To set up CSPM for an Azure organization or subscription, you will need admin privileges for that organization or subscription. + +For most users, the simplest option is to use an Azure Resource Manager (ARM) template to automatically provision the necessary resources and permissions in Azure. If you prefer a more hands-on approach or require a specific configuration not supported by the ARM template, you can use one of the manual setup options described below. + +[discrete] +[[cspm-set-up-ARM]] +=== ARM template setup (recommended) + +. Under **Setup Access**, select **ARM Template**. +. Under **Where to add this integration**: ++ +.. Select **New Hosts**. +.. Name the {agent} policy. Use a name that matches the resources you want to monitor, for example, `azure-dev-policy`. Click **Save and continue**. The **ARM Template deployment** window appears. +.. In a new tab, log in to the Azure portal, then return to {kib} and click **Launch ARM Template**. This will open the ARM template in Azure. +.. If you are deploying to an Azure organization, select the management group you want to monitor from the drop-down menu. Next, enter the subscription ID of the subscription where you want to deploy the VM that will scan your resources. +.. Copy the `Fleet URL` and `Enrollment Token` that appear in {kib} to the corresponding fields in the ARM Template, then click **Review + create**. +.. (Optional) Change the `Resource Group Name` parameter. Otherwise, the name of the resource group defaults to a timestamp prefixed with `cloudbeat-`. +. Return to {kib} and wait for the confirmation of data received from your new integration. Then you can click **View Assets** to see your data. + +[discrete] +[[cspm-set-up-manual-azure]] +=== Manual setup + +For manual setup, multiple authentication methods are available: + +. Managed identity (recommended) +. Service principal with client secret +. Service principal with client certificate + +[discrete] +[[cspm-azure-managed-identity-setup]] +=== Option 1: Managed identity (recommended) + +This method involves creating an Azure VM (or using an existing one), giving it read access to the resources you want to monitor with CSPM, and installing {agent} on it. + +. Go to the Azure portal to create a new Azure VM. +. Follow the setup process, and make sure you enable **System assigned managed identity** under the **Management** tab. +. Go to your Azure subscription list and select the subscription or management group you want to monitor with CSPM. +. Go to **Access control (IAM)**, and select **Add Role Assignment**. +. Select the `Reader` role, assign access to **Managed Identity**, then select your VM. + +After assigning the role: + +. Return to the **Add CSPM** page in {kib}. +. Under **Configure integration**, select **Azure**. Under **Setup access**, select **Manual**. +. Under **Where to add this integration**, select **New hosts**. +. Click **Save and continue**, then follow the instructions to install {agent} on your Azure VM. + +Wait for the confirmation that {kib} received data from your new integration. Then you can click **View Assets** to see your data. + +[discrete] +[[cspm-azure-client-secret]] +=== Option 2: Service principal with client secret + +Before using this method, you must have set up a https://learn.microsoft.com/en-us/entra/identity-platform/howto-create-service-principal-portal#get-tenant-and-app-id-values-for-signing-in[Microsoft Entra application and service principal that can access resources]. + +. On the **Add Cloud Security Posture Management (CSPM) integration** page, scroll to the **Setup access** section, then select **Manual**. +. Under **Preferred manual method**, select **Service principal with Client Secret**. +. Go to the **Registered apps** section of https://ms.portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/RegisteredApps[Microsoft Entra ID]. +. Click on **New Registration**, name your app and click **Register**. +. Copy your new app's `Directory (tenant) ID` and `Application (client) ID`. Paste them into the corresponding fields in {kib}. +. Return to the Azure portal. Select **Certificates & secrets**, then go to the **Client secrets** tab. Click **New client secret**. +. Copy the new secret. Paste it into the corresponding field in {kib}. +. Return to Azure. Go to your Azure subscription list and select the subscription or management group you want to monitor with CSPM. +. Go to **Access control (IAM)** and select **Add Role Assignment**. +. Select the `Reader` function role, assign access to **User, group, or service principal**, and select your new app. +. Return to the **Add CSPM** page in {kib}. +. Under **Where to add this integration**, select **New hosts**. +. Click **Save and continue**, then follow the instructions to install {agent} on your selected host. + +Wait for the confirmation that {kib} received data from your new integration. Then you can click **View Assets** to see your data. + +[discrete] +[[cspm-azure-client-certificate]] +=== Option 3: Service principal with client certificate + +Before using this method, you must have set up a https://learn.microsoft.com/en-us/entra/identity-platform/howto-create-service-principal-portal#get-tenant-and-app-id-values-for-signing-in[Microsoft Entra application and service principal that can access resources]. + +. On the **Add Cloud Security Posture Management (CSPM) integration** page, under **Setup access**, select **Manual**. +. Under **Preferred manual method**, select **Service principal with client certificate**. +. Go to the **Registered apps** section of https://ms.portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/RegisteredApps[Microsoft Entra ID]. +. Click on **New Registration**, name your app and click **Register**. +. Copy your new app's `Directory (tenant) ID` and `Application (client) ID`. Paste them into the corresponding fields in {kib}. +. Return to Azure. Go to your Azure subscription list and select the subscription or management group you want to monitor with CSPM. +. Go to **Access control (IAM)** and select **Add Role Assignment**. +. Select the `Reader` function role, assign access to **User, group, or service principal**, and select your new app. + +Next, create a certificate. If you intend to use a password-protected certificate, you must use a pkcs12 certificate. Otherwise, you must use a pem certificate. + +Create a pkcs12 certificate, for example: + +[source,shell] +---- +# Create PEM file +openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes + +# Create pkcs12 bundle using legacy flag (CLI will ask for export password) +openssl pkcs12 -legacy -export -out bundle.p12 -inkey key.pem -in cert.pem +---- + +Create a PEM certificate, for example: + +[source,shell] +---- +# Generate certificate signing request (csr) and key +openssl req -new -newkey rsa:4096 -nodes -keyout cert.key -out cert.csr + +# Generate PEM and self-sign with key +openssl x509 -req -sha256 -days 365 -in cert.csr -signkey cert.key -out signed.pem + +# Create bundle +cat cert.key > bundle.pem +cat signed.pem >> bundle.pem +---- + +. Return to Azure. +. Navigate to the **Certificates & secrets** menu. Select the **Certificates** tab. +. Click **Upload certificate**. ++ +.. If you're using a PEM certificate that was created using the example commands above, upload `signed.pem`. +.. If you're using a pkcs12 certificate that was created using the example commands above, upload `cert.pem`. +. Upload the certificate bundle to the VM where you will deploy {agent}. ++ +.. If you're using a PEM certificate that was created using the example commands above, upload `bundle.pem`. +.. If you're using a pkcs12 certificate that was created using the example commands above, upload `bundle.p12`. +. Return to the **Add CSPM** page in {kib}. +. For **Client Certificate Path**, enter the full path to the certificate that you uploaded to the host where you will install {agent}. +. If you used a pkcs12 certificate, enter its password under **Client Certificate Password**. +. Under **Where to add this integration**, select **New hosts**. +. Click **Save and continue**, then follow the instructions to install {agent} on your selected host. + +Wait for the confirmation that {kib} received data from your new integration. Then you can click **View Assets** to see your data. diff --git a/docs/serverless/cloud-native-security/cspm-get-started-gcp.asciidoc b/docs/serverless/cloud-native-security/cspm-get-started-gcp.asciidoc new file mode 100644 index 0000000000..441ed59aa5 --- /dev/null +++ b/docs/serverless/cloud-native-security/cspm-get-started-gcp.asciidoc @@ -0,0 +1,186 @@ +[[cspm-get-started-gcp]] += Get started with CSPM for GCP + +:description: Start monitoring the security posture of your GCP cloud assets. +:keywords: serverless, security, overview, cloud security + +preview:[] + +[discrete] +[[cspm-overview-gcp]] +== Overview + +This page explains how to get started monitoring the security posture of your cloud assets using the Cloud Security Posture Management (CSPM) feature. + +.Requirements +[NOTE] +==== +* CSPM only works in the `Default` {kib} space. Installing the CSPM integration on a different {kib} space will not work. +* CSPM is supported only on AWS, GCP, and Azure commercial cloud platforms, and AWS GovCloud. Other government cloud platforms are not supported (https://github.com/elastic/kibana/issues/new/choose[request support]). +* To view posture data, you need the appropriate user role to read the following {es} indices: ++ +** `logs-cloud_security_posture.findings_latest-*` +** `logs-cloud_security_posture.scores-*` +** `Logs-cloud_security_posture.findings` +* The user who gives the CSPM integration GCP permissions must be a GCP project `admin`. +==== + +[discrete] +[[cspm-setup-gcp]] +== Initial setup + +You can set up CSPM for GCP either by enrolling a single project, or by enrolling an organization containing multiple projects. Either way, you need to first add the CSPM integration, then enable cloud account access. + +[discrete] +[[cspm-add-and-name-integration-gcp]] +=== Add your CSPM integration + +. From the Elastic Security **Get started** page, click **Add integrations**. +. Search for `CSPM`, then click on the result. +. Click **Add Cloud Security Posture Management (CSPM)**. +. Under **Configure integration**, select **GCP**, then either **GCP Organization** (recommended) or **Single Account**. +. Give your integration a name that matches the purpose or team of the GCP account you want to monitor, for example, `dev-gcp-project`. + +[discrete] +[[cspm-set-up-cloud-access-section-gcp]] +=== Set up cloud account access + +To set up CSPM for a GCP project, you need admin privileges for the project. + +For most users, the simplest option is to use a Google Cloud Shell script to automatically provision the necessary resources and permissions in your GCP account. This method, as well as two manual options, are described below. + +[discrete] +[[cspm-set-up-cloudshell]] +== Cloud Shell script setup (recommended) + +. Under **Setup Access**, select **Google Cloud Shell**. Enter your GCP Project ID, and for GCP Organization deployments, your GCP Organization ID. +. Under **Where to add this integration**: ++ +.. Select **New Hosts**. +.. Name the {agent} policy. Use a name that matches the purpose or team of the cloud account or accounts you want to monitor. For example, `dev-gcp-account`. +.. Click **Save and continue**, then **Add {agent} to your hosts**. The **Add agent** wizard appears and provides {agent} binaries, which you can download and deploy to a VM in your GCP account. +. Click **Save and continue**. +. Copy the command that appears, then click **Launch Google Cloud Shell**. It opens in a new window. +. Check the box to trust Elastic's `cloudbeat` repo, then click **Confirm** ++ +[role="screenshot"] +image::images/cspm-get-started-gcp/-cloud-native-security-cspm-cloudshell-trust.png[The cloud shell confirmation popup] +. In Google Cloud Shell, execute the command you copied. Once it finishes, return to {kib} and wait for the confirmation of data received from your new integration. Then you can click **View Assets** to see your data. + +[NOTE] +==== +During Cloud Shell setup, the CSPM integration adds roles to Google's default service account, which enables custom role creation and attachment of the service account to a compute instance. +After setup, these roles are removed from the service account. If you attempt to delete the deployment but find the deployment manager lacks necessary permissions, consider adding the missing roles to the service account: +https://cloud.google.com/iam/docs/understanding-roles#resourcemanager.projectIamAdmin[Project IAM Admin], https://cloud.google.com/iam/docs/understanding-roles#iam.roleAdmin[Role Administrator]. +==== + +[discrete] +[[cspm-manual-auth-org]] +== Manual authentication (GCP organization) + +To authenticate manually to monitor a GCP organization, you'll need to create a new GCP service account, assign it the necessary roles, generate credentials, then provide those credentials to the CSPM integration. + +Use the following commands, after replacing `` with the name of your new service account, `` with your GCP organization's ID, and `` with the GCP project ID of the project where you want to provision the compute instance that will run CSPM. + +Create a new service account: + +[source,shell] +---- +gcloud iam service-accounts create \ + --description="Elastic agent service account for CSPM" \ + --display-name="Elastic agent service account for CSPM" \ + --project= +---- + +Assign the necessary roles to the service account: + +[source,shell] +---- +gcloud organizations add-iam-policy-binding \ + --member=serviceAccount:@.iam.gserviceaccount.com \ + --role=roles/cloudasset.viewer + +gcloud organizations add-iam-policy-binding \ + --member=serviceAccount:@.iam.gserviceaccount.com \ + --role=roles/browser +---- + +The `Cloud Asset Viewer` role grants read access to cloud asset metadata. The `Browser` role grants read access to the project hierarchy. + +Download the credentials JSON (first, replace `` with the location where you want to save it): + +[source,shell] +---- +gcloud iam service-accounts keys create \ + --iam-account=@.iam.gserviceaccount.com +---- + +Keep the credentials JSON in a secure location; you will need it later. + +Provide credentials to the CSPM integration: + +. On the CSPM setup screen under **Setup Access**, select **Manual**. +. Enter your GCP **Organization ID**. Enter the GCP **Project ID** of the project where you want to provision the compute instance that will run CSPM. +. Select **Credentials JSON**, and enter the value you generated earlier. +. Under **Where to add this integration**, select **New Hosts**. +. Name the {agent} policy. Use a name that matches the purpose or team of the cloud account or accounts you want to monitor. For example, `dev-gcp-account`. +. Click **Save and continue**, then follow the instructions to install {agent} in your chosen GCP project. + +Wait for the confirmation that {kib} received data from your new integration. Then you can click **View Assets** to see your data. + +[discrete] +[[cspm-manual-auth-proj]] +== Manual authentication (GCP project) + +To authenticate manually to monitor an individual GCP project, you'll need to create a new GCP service account, assign it the necessary roles, generate credentials, then provide those credentials to the CSPM integration. + +Use the following commands, after replacing `` with the name of your new service account, and `` with your GCP project ID. + +Create a new service account: + +[source,shell] +---- +gcloud iam service-accounts create \ + --description="Elastic agent service account for CSPM" \ + --display-name="Elastic agent service account for CSPM" \ + --project= +---- + +Assign the necessary roles to the service account: + +[source,shell] +---- +gcloud projects add-iam-policy-binding \ + --member=serviceAccount:@.iam.gserviceaccount.com \ + --role=roles/cloudasset.viewer + +gcloud projects add-iam-policy-binding \ + --member=serviceAccount:@.iam.gserviceaccount.com \ + --role=roles/browser +---- + +[NOTE] +==== +The `Cloud Asset Viewer` role grants read access to cloud asset metadata. The `Browser` role grants read access to the project hierarchy. +==== + +Download the credentials JSON (first, replace `` with the location where you want to save it): + +[source,shell] +---- +gcloud iam service-accounts keys create \ + --iam-account=@.iam.gserviceaccount.com +---- + +Keep the credentials JSON in a secure location; you will need it later. + +Provide credentials to the CSPM integration: + +. On the CSPM setup screen under **Setup Access**, select **Manual**. +. Enter your GCP **Project ID**. +. Select **Credentials JSON**, and enter the value you generated earlier. +. Under **Where to add this integration**, select **New Hosts**. +. Name the policy. Use a name that matches the purpose or team of the cloud account or accounts you want to monitor. For example, `dev-gcp-account`. +. Click **Save and continue**, then follow the instructions to install the agent in your chosen GCP project. + +Wait for the confirmation that Kibana received data from your new integration. Then you can click **View Assets** to see your data. diff --git a/docs/serverless/cloud-native-security/cspm-get-started.asciidoc b/docs/serverless/cloud-native-security/cspm-get-started.asciidoc new file mode 100644 index 0000000000..802795ade1 --- /dev/null +++ b/docs/serverless/cloud-native-security/cspm-get-started.asciidoc @@ -0,0 +1,328 @@ +[[cspm-get-started]] += Get started with CSPM for AWS + +:description: Start monitoring the security posture of your AWS cloud assets. +:keywords: serverless, security, overview, cloud security + +preview:[] + +[discrete] +[[cspm-overview]] +== Overview + +This page explains how to get started monitoring the security posture of your cloud assets using the Cloud Security Posture Management (CSPM) feature. + +.Requirements +[NOTE] +==== +* CSPM only works in the `Default` {kib} space. Installing the CSPM integration on a different {kib} space will not work. +* CSPM is supported only on AWS, GCP, and Azure commercial cloud platforms, and AWS GovCloud. Other government cloud platforms are not supported (https://github.com/elastic/kibana/issues/new/choose[request support]). +* To view posture data, you need the appropriate user role to read the following {es} indices: ++ +** `logs-cloud_security_posture.findings_latest-*` +** `logs-cloud_security_posture.scores-*` +** `Logs-cloud_security_posture.findings` +* The user who gives the CSPM integration AWS permissions must be an AWS account `admin`. +==== + +[discrete] +[[cspm-setup]] +== Set up CSPM for AWS + +You can set up CSPM for AWS either by enrolling a single cloud account, or by enrolling an organization containing multiple accounts. Either way, first you will add the CSPM integration, then enable cloud account access. + +[discrete] +[[cspm-add-and-name-integration]] +== Add the CSPM integration + +. From the Elastic Security **Get started** page, click **Add integrations**. +. Search for `CSPM`, then click on the result. +. Click **Add Cloud Security Posture Management (CSPM)**. +. Select **AWS**, then either **AWS Organization** to onboard multiple accounts, or **Single Account** to onboard an individual account. +. Give your integration a name that matches the purpose or team of the AWS account/organization you want to monitor, for example, `dev-aws-account`. + +[discrete] +[[cspm-set-up-cloud-access-section]] +== Set up cloud account access + +The CSPM integration requires access to AWS’s built-in https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html#jf_security-auditor[`SecurityAudit` IAM policy] in order to discover and evaluate resources in your cloud account. There are several ways to provide access. + +For most use cases, the simplest option is to use AWS CloudFormation to automatically provision the necessary resources and permissions in your AWS account. This method, as well as several manual options, are described below. + +[discrete] +[[cspm-set-up-cloudformation]] +=== CloudFormation (recommended) + +. In the **Add Cloud Security Posture Management (CSPM) integration** menu, under **Setup Access**, select **CloudFormation**. +. In a new browser tab or window, log in as an admin to the AWS account or organization you want to onboard. +. Return to your {kib} tab. Click **Save and continue** at the bottom of the page. +. Review the information, then click **Launch CloudFormation**. +. A CloudFormation template appears in a new browser tab. +. For organization-level deployments only, you must enter the ID of the organizational unit where you want to deploy into the `OrganizationalUnitIds` field in the CloudFormation template. You can find it in the AWS console under **AWS Organizations → AWS Accounts** (it appears under the organization name). +. (Optional) Switch to the AWS region where you want to deploy using the controls in the upper right corner. +. Tick the checkbox under **Capabilities** to authorize the creation of necessary resources. ++ +[role="screenshot"] +image::images/cspm-get-started/-cloud-native-security-cspm-cloudformation-template.png[The Add permissions screen in AWS] +. At the bottom of the template, select **Create stack**. + +When you return to {kib}, click **View assets** to review the data being collected by your new integration. + +[discrete] +[[cspm-setup-organization-manual]] +=== Manual authentication for organization-level onboarding + +[NOTE] +==== +If you're onboarding a single account instead of an organization, skip this section. +==== + +When using manual authentication to onboard at the organization level, you need to configure the necessary permissions using the AWS console for the organization where you want to deploy: + +* In the organization's management account (root account), create an IAM role called `cloudbeat-root` (the name is important). The role needs several policies: ++ +** The following inline policy: + +.Click to expand policy +[%collapsible] +===== +[source] +---- +{ + "Version": "2012-10-17", + "Statement": [ + { + "Action": [ + "organizations:List*", + "organizations:Describe*" + ], + "Resource": "*", + "Effect": "Allow" + }, + { + "Action": [ + "sts:AssumeRole" + ], + "Resource": "*", + "Effect": "Allow" + } + ] +} +---- +===== + +* The following trust policy: + +.Click to expand policy +[%collapsible] +===== +[source] +---- +{ + "Version": "2012-10-17", + "Statement": [ + { + "Effect": "Allow", + "Principal": { + "AWS": "arn:aws:iam:::root" + }, + "Action": "sts:AssumeRole" + }, + { + "Effect": "Allow", + "Principal": { + "Service": "ec2.amazonaws.com" + }, + "Action": "sts:AssumeRole" + } + ] +} +---- +===== + +* The AWS-managed `SecurityAudit` policy. + +[IMPORTANT] +==== +You must replace `` in the trust policy with your AWS account ID. +==== + +* Next, for each account you want to scan in the organization, create an IAM role named `cloudbeat-securityaudit` with the following policies: ++ +** The AWS-managed `SecurityAudit` policy. +** The following trust policy: + +.Click to expand policy +[%collapsible] +===== +[source] +---- +{ + "Version": "2012-10-17", + "Statement": [ + { + "Effect": "Allow", + "Principal": { + "AWS": "arn:aws:iam:::role/cloudbeat-root" + }, + "Action": "sts:AssumeRole" + } + ] +} +---- +===== + +[IMPORTANT] +==== +You must replace `` in the trust policy with your AWS account ID. +==== + +After creating the necessary roles, authenticate using one of the manual authentication methods. + +[IMPORTANT] +==== +When deploying to an organization using any of the authentication methods below, you need to make sure that the credentials you provide grant permission to assume `cloudbeat-root` privileges. +==== + +[discrete] +[[cspm-set-up-manual]] +== Manual authentication methods + +* <> +* <> +* <> +* <> +* <> + +[IMPORTANT] +==== +Whichever method you use to authenticate, make sure AWS’s built-in https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html#jf_security-auditor[`SecurityAudit` IAM policy] is attached. +==== + +[discrete] +[[cspm-use-instance-role]] +=== Option 1 - Default instance role + +[NOTE] +==== +If you are deploying to an AWS organization instead of an AWS account, you should already have <>, `cloudbeat-root`. Skip to step 2 "Attach your new IAM role to an EC2 instance", and attach this role. You can use either an existing or new EC2 instance. +==== + +Follow AWS's https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html[IAM roles for Amazon EC2] documentation to create an IAM role using the IAM console, which automatically generates an instance profile. + +. Create an IAM role: ++ +.. In AWS, go to your IAM dashboard. Click **Roles**, then **Create role**. +.. On the **Select trusted entity** page, under **Trusted entity type**, select **AWS service**. +.. Under **Use case**, select **EC2**. Click **Next**. ++ +[role="screenshot"] +image::images/cspm-get-started/-cloud-native-security-cspm-aws-auth-1.png[The Select trusted entity screen in AWS] +.. On the **Add permissions** page, search for and select `SecurityAudit`. Click **Next**. ++ +[role="screenshot"] +image::images/cspm-get-started/-cloud-native-security-cspm-aws-auth-2.png[The Add permissions screen in AWS] +.. On the **Name, review, and create** page, name your role, then click **Create role**. +. Attach your new IAM role to an EC2 instance: ++ +.. In AWS, select an EC2 instance. +.. Select **Actions → Security → Modify IAM role**. ++ +[role="screenshot"] +image::images/cspm-get-started/-cloud-native-security-cspm-aws-auth-3.png[The EC2 page in AWS, showing the Modify IAM role option] +.. On the **Modify IAM role** page, search for and select your new IAM role. +.. Click **Update IAM role**. +.. Return to {kib} and <>. + +[IMPORTANT] +==== +Make sure to deploy the CSPM integration to this EC2 instance. When completing setup in Kibana, in the **Setup Access** section, select **Assume role** and leave **Role ARN** empty. Click **Save and continue**. +==== + +[discrete] +[[cspm-use-keys-directly]] +=== Option 2 - Direct access keys + +Access keys are long-term credentials for an IAM user or AWS account root user. To use access keys as credentials, you must provide the `Access key ID` and the `Secret Access Key`. After you provide credentials, <>. + +For more details, refer to https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html[Access Keys and Secret Access Keys]. + +[IMPORTANT] +==== +You must select **Programmatic access** when creating the IAM user. +==== + +[discrete] +[[cspm-use-temp-credentials]] +=== Option 3 - Temporary security credentials + +You can configure temporary security credentials in AWS to last for a specified duration. They consist of an access key ID, a secret access key, and a security token, which is typically found using `GetSessionToken`. + +Because temporary security credentials are short term, once they expire, you will need to generate new ones and manually update the integration's configuration to continue collecting cloud posture data. Update the credentials before they expire to avoid data loss. + +[NOTE] +==== +IAM users with multi-factor authentication (MFA) enabled need to submit an MFA code when calling `GetSessionToken`. For more details, refer to AWS's https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html[Temporary Security Credentials] documentation. +==== + +You can use the AWS CLI to generate temporary credentials. For example, you could use the following command if you have MFA enabled: + +[source,console] +---- +sts get-session-token --serial-number arn:aws:iam::1234:mfa/your-email@example.com --duration-seconds 129600 --token-code 123456 +---- + +The output from this command includes the following fields, which you should provide when configuring the KSPM integration: + +* `Access key ID`: The first part of the access key. +* `Secret Access Key`: The second part of the access key. +* `Session Token`: The required token when using temporary security credentials. + +After you provide credentials, <>. + +[discrete] +[[cspm-use-a-shared-credentials-file]] +=== Option 4 - Shared credentials file + +If you use different AWS credentials for different tools or applications, you can use profiles to define multiple access keys in the same configuration file. For more details, refer to AWS' https://docs.aws.amazon.com/sdkref/latest/guide/file-format.html[Shared Credentials Files] documentation. + +Instead of providing the `Access key ID` and `Secret Access Key` to the integration, provide the information required to locate the access keys within the shared credentials file: + +* `Credential Profile Name`: The profile name in the shared credentials file. +* `Shared Credential File`: The directory of the shared credentials file. + +If you don't provide values for all configuration fields, the integration will use these defaults: + +* If `Access key ID`, `Secret Access Key`, and `ARN Role` are not provided, then the integration will check for `Credential Profile Name`. +* If there is no `Credential Profile Name`, the default profile will be used. +* If `Shared Credential File` is empty, the default directory will be used. ++ +** For Linux or Unix, the shared credentials file is located at `~/.aws/credentials`. + +After providing credentials, <>. + +[discrete] +[[cspm-use-iam-arn]] +=== Option 5 - IAM role Amazon Resource Name (ARN) + +An IAM role Amazon Resource Name (ARN) is an IAM identity that you can create in your AWS account. You define the role's permissions. Roles do not have standard long-term credentials such as passwords or access keys. Instead, when you assume a role, it provides temporary security credentials for your session. + +To use an IAM role ARN, select **Assume role** under **Preferred manual method**, enter the ARN, and continue to Finish manual setup. + +[discrete] +[[cspm-finish-manual]] +== Finish manual setup + +Once you’ve provided AWS credentials, under **Where to add this integration**: + +If you want to monitor an AWS account or organization where you have not yet deployed {agent}: + +* Select **New Hosts**. +* Name the {agent} policy. Use a name that matches the purpose or team of the cloud account or accounts you want to monitor. For example, `dev-aws-account`. +* Click **Save and continue**, then **Add {agent} to your hosts**. The **Add agent** wizard appears and provides {agent} binaries, which you can download and deploy to your AWS account. + +If you want to monitor an AWS account or organization where you have already deployed {agent}: + +* Select **Existing hosts**. +* Select an agent policy that applies the AWS account you want to monitor. +* Click **Save and continue**. diff --git a/docs/serverless/cloud-native-security/cspm-security-posture-faq.asciidoc b/docs/serverless/cloud-native-security/cspm-security-posture-faq.asciidoc new file mode 100644 index 0000000000..0278dc1130 --- /dev/null +++ b/docs/serverless/cloud-native-security/cspm-security-posture-faq.asciidoc @@ -0,0 +1,90 @@ +[[cspm-security-posture-faq]] += Frequently asked questions (FAQ) + +:description: Frequently asked questions about the CSPM and KSPM integrations. +:keywords: serverless, security, overview, cloud security + +preview:[] + +[discrete] +== CSPM FAQ + +Frequently asked questions about the Cloud Security Posture Management (CSPM) integration and features. + +**How often is my cloud security posture evaluated?** + +Cloud accounts are evaluated when you first deploy the CSPM integration and every 24 hours afterward. + +**Can I onboard multiple accounts at one time?** + +Yes. Follow the onboarding instructions in the getting started guides for AWS, GCP, or Azure. + +**When do newly enrolled cloud accounts appear on the dashboard?** + +After you deploy the CSPM integration, it can take up to 10 minutes for resource fetching, evaluation, and data processing before a newly enrolled account appears on the Cloud Security Posture dashboard. + +**When do unenrolled cloud accounts disappear from the dashboard?** + +Newly unenrolled cloud accounts can take a maximum of 24 hours to disappear from the Cloud Security Posture dashboard. + +[discrete] +[[cspm-security-posture-faq-kspm-faq]] +== KSPM FAQ + +Frequently asked questions about the Kubernetes Security Posture Management (KSPM) integration and features. + +**What versions of Kubernetes are supported?** + +For self-managed/vanilla clusters, Kubernetes version 1.23 is supported. + +For EKS clusters, all Kubernetes versions available at the time of cluster deployment are supported. + +**Do benchmark rules support multiple Kubernetes deployment types?** +Yes. There are different sets of benchmark rules for self-managed and third party-managed deployments. Refer to <> for more information about setting up each deployment type. + +**Can I evaluate the security posture of my Amazon EKS clusters?** +Yes. KSPM currently supports the security posture evaluation of Amazon EKS and unmanaged Kubernetes clusters. + +**How often is my cluster’s security posture evaluated?** +Clusters are evaluated when you deploy a KSPM integration, and every four hours after that. + +**When do newly-enrolled clusters appear on the dashboard?** +It can take up to 10 minutes for deployment, resource fetching, evaluation, and data processing to complete before a newly-enrolled cluster appears on the dashboard. + +**When do unenrolled clusters disappear from the dashboard?** +A cluster will disappear as soon as the KSPM integration fetches data while that cluster is not enrolled. The fetch process repeats every four hours, which means a newly unenrolled cluster can take a maximum of four hours to disappear from the dashboard. + +[discrete] +[[cspm-security-posture-faq-findings-page]] +== Findings page + +**Are all the findings page current?** +Yes. Only the most recent findings appear on the Findings page. + +**Can I build custom visualizations and dashboards that incorporate findings data?** +Yes, you can use custom visualization capabilities with findings data. To learn more, refer to {kibana-ref}/dashboard.html[Dashboards and visualizations]. + +**Where is Findings data saved?** +You can access findings data using the following index patterns: + +* **Current findings:** `logs-cloud_security_posture.findings_latest-*` +* **Historical findings:** `logs-cloud_security_posture.findings-*` + +[discrete] +[[cspm-security-posture-faq-benchmark-rules]] +== Benchmark rules + +**How often are my resources evaluated against benchmark rules?** +Resources are fetched and evaluated against benchmark rules when a security posture management integration is deployed. After that, the CSPM integration evaluates every 24 hours, and the KSPM integration evaluates every four hours. + +**Can I configure an integration's fetch cycle?** +No, the four-hour fetch cycle is not configurable. + +**Can I contribute to the CSP ruleset?** +You can't directly edit benchmark rules. The rules are defined https://github.com/elastic/csp-security-policies[in this repository], where you can raise issues with certain rules. They are written in https://www.openpolicyagent.org/docs/latest/policy-language/[Rego]. + +**How can I tell which specific version of the CIS benchmarks is in use?** +Refer to the `rule.benchmark.name` and `rule.benchmark.version` fields for documents in these datastreams: + +* `logs-cloud_security_posture.findings-default` +* `logs-cloud_security_posture.findings_latest-default` diff --git a/docs/serverless/cloud-native-security/cspm.asciidoc b/docs/serverless/cloud-native-security/cspm.asciidoc new file mode 100644 index 0000000000..984f4bd190 --- /dev/null +++ b/docs/serverless/cloud-native-security/cspm.asciidoc @@ -0,0 +1,25 @@ +[[cspm]] += Cloud security posture management + +:description: Identify misconfigured cloud resources. +:keywords: serverless, security, overview + +preview:[] + +The Cloud Security Posture Management (CSPM) feature discovers and evaluates the services in your cloud environment — like storage, compute, IAM, and more — against configuration security guidelines defined by the https://www.cisecurity.org/[Center for Internet Security] (CIS) to help you identify and remediate risks that could undermine the confidentiality, integrity, and availability of your cloud data. + +This feature currently supports Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure. For step-by-step getting started guides, refer to <>, <>, or <>. + +.Requirements +[NOTE] +==== +* CSPM only works in the `Default` {kib} space. Installing the CSPM integration on a different {kib} space will not work. +* CSPM is supported only on AWS, GCP, and Azure commercial cloud platforms, and AWS GovCloud. Other government cloud platforms are not supported (https://github.com/elastic/kibana/issues/new/choose[request support]). +==== + +[discrete] +[[cspm-how-it-works]] +== How CSPM works + +Using the read-only credentials you will provide during the setup process, it will evaluate the configuration of resources in your environment every 24 hours. +After each evaluation, the integration sends findings to Elastic. A high-level summary of the findings appears on the <>, and detailed findings appear on the <>. diff --git a/docs/serverless/cloud-native-security/d4c-get-started.asciidoc b/docs/serverless/cloud-native-security/d4c-get-started.asciidoc new file mode 100644 index 0000000000..4d8aa021ad --- /dev/null +++ b/docs/serverless/cloud-native-security/d4c-get-started.asciidoc @@ -0,0 +1,93 @@ +[[d4c-get-started]] += Get started with CWP + +:description: Secure your containerized workloads and start detecting threats and vulnerabilities. +:keywords: security, how-to, get-started, cloud security + +preview:[] + +beta:[] + +This page describes how to set up Cloud Workload Protection (CWP) for Kubernetes. + +.Requirements +[NOTE] +==== +* Kubernetes node operating systems must have Linux kernels 5.10.16 or higher. +==== + +[discrete] +[[d4c-get-started-initial-setup]] +== Initial setup + +First, you'll need to deploy Elastic's Defend for Containers integration to the Kubernetes clusters you wish to monitor. + +. Go to **Assets → Cloud**, then click **Add D4C Integration**. +. Name the integration. The default name, which you can change, is `cloud_defend-1`. +. Optional — make any desired changes to the integration's policy by adjusting the **Selectors** and **Responses** sections. (For more information, refer to the <>). You can also change these later. +. Under **Where to add this integration**, select an existing or new agent policy. +. Click **Save & Continue**, then **Add {agent} to your hosts**. +. On the {agent} policy page, click **Add agent** to open the Add agent flyout. +. In the flyout, go to step 3 (**Install {agent} on your host**) and select the **Kubernetes** tab. +. Download or copy the manifest (`elastic-agent-managed-kubernetes.yml`). +. Open the manifest using your favorite editor, and uncomment the `#capabilities` section: ++ +[source,console] +---- +#capabilities: +# add: +# - BPF # (since Linux 5.8) allows loading of BPF programs, create most map types, load BTF, iterate programs and maps. +# - PERFMON # (since Linux 5.8) allows attaching of BPF programs used for performance metrics and observability operations. +# - SYS_RESOURCE # Allow use of special resources or raising of resource limits. Used by 'Defend for Containers' to modify 'rlimit_memlock' +---- +. From the directory where you saved the manifest, run the command `kubectl apply -f elastic-agent-managed-kubernetes.yml`. +. Wait for the **Confirm agent enrollment** dialogue to show that data has started flowing from your newly-installed agent, then click **Close**. + +[discrete] +[[d4c-get-started-threat]] +== Get started with threat detection + +One of the <> sends process telemetry events (`fork` and `exec`) to {es}. + +In order to detect threats using this data, you'll need active <>. Elastic has prebuilt detection rules designed for this data. (You can also create your own <>.) + +To install and enable the prebuilt rules: + +. Go to **Security → Rules → Detection rules (SIEM)**, then click **Add Elastic rules**. +. Click the **Tags** filter next to the search bar, and search for the `Data Source: Elastic Defend for Containers` tag. +. Select all the displayed rules, then click **Install _x_ selected rule(s)**. +. Return to the **Rules** page. Click the **Tags** filter next to the search bar, and search for the `Data Source: Elastic Defend for Containers` tag. +. Select all the rules with the tag, and then click **Bulk actions → Enable**. + +[discrete] +[[d4c-get-started-drift]] +== Get started with drift detection and prevention + +{elastic-sec} defines container drift as the creation or modification of an executable within a container. Blocking drift restricts the number of attack vectors available to bad actors by prohibiting them from using external tools. + +To enable drift detection, you can use the default D4C policy: + +. Make sure the <> is active. +. Make sure you enabled at least the "Container Workload Protection" rule, by following the steps to install prebuilt rules, above. + +To enable drift prevention, create a new policy: + +. Add a new selector called `blockDrift`. +. Go to **Security → Manage → Container Workload Security → Your integration name**. +. Under **Selectors**, click **Add selector → File Selector**. By default, it selects the operations `createExecutable` and `modifyExecutable`. +. Name the selector, for example: `blockDrift`. +. Scroll down to the **Responses** section and click **Add response → File Response**. +. Under **Match selectors**, add the name of your new selector, for example: `blockDrift`. +. Select the **Alert** and **Block** actions. +. Click **Save integration**. + +[IMPORTANT] +==== +Before you enable blocking, we strongly recommend you observe a production workload that's using the default D4C policy to ensure that the workload does not create or modify executables as part of its normal operation. +==== + +[discrete] +[[d4c-get-started-validation]] +== Policy validation + +To ensure the stability of your production workloads, you should test policy changes before implementing them in production workloads. We also recommend you test policy changes on a simulated environment with workloads similar to production. This approach allows you to test that policy changes prevent undesirable behavior without disrupting your production workloads. diff --git a/docs/serverless/cloud-native-security/d4c-overview.asciidoc b/docs/serverless/cloud-native-security/d4c-overview.asciidoc new file mode 100644 index 0000000000..855ea01a24 --- /dev/null +++ b/docs/serverless/cloud-native-security/d4c-overview.asciidoc @@ -0,0 +1,88 @@ +[[d4c-overview]] += Container workload protection + +:description: Identify and block unexpected system behavior in Kubernetes containers. +:keywords: security, cloud, reference, manage + +preview:[] + +beta:[] + +Elastic Cloud Workload Protection (CWP) for Kubernetes provides cloud-native runtime protections for containerized environments by identifying and optionally blocking unexpected system behavior in Kubernetes containers. + +[discrete] +[[d4c-use-cases]] +== Use cases + +[discrete] +[[d4c-overview-threat-detection-and-threat-hunting]] +=== Threat detection & threat hunting + +CWP for Kubernetes sends system events from your containers to {es}. {elastic-sec}'s prebuilt security rules include many designed to detect malicious behavior in container runtimes. These can help you detect events that should never occur in containers, such as reverse shell executions, privilege escalation, container escape attempts, and more. + +[discrete] +[[d4c-overview-drift-detection-and-prevention]] +=== Drift detection & prevention + +Cloud-native containers should be immutable, meaning that their file systems should not change during normal operations. By leveraging this principle, security teams can detect unusual system behavior with a high degree of accuracy — without relying on more resource-intensive techniques like memory scanning or attack signature detection. Elastic’s Drift Detection mechanism has a low rate of false positives, so you can deploy it in most environments without worrying about creating excessive alerts. + +[discrete] +[[d4c-overview-workload-protection-policies]] +=== Workload protection policies + +CWP for Kubernetes uses a flexible policy language to restrict container workloads to a set of allowlisted capabilities chosen by you. When employed with Drift and Threat Detection, this can provide multiple layers of defense. + +[discrete] +[[d4c-overview-support-matrix]] +== Support matrix: + +|=== +| | EKS 1.24-1.27 (AL2022)| GKE 1.24-1.27 (COS) + +| Process event exports +| ✓ +| ✓ + +| Network event exports +| ✓ +| ✓ + +| File event exports +| ✓ +| ✓ + +| File blocking +| ✓ +| ✓ + +| Process blocking +| ✓ +| ✓ + +| Network blocking +| ✗ +| ✗ + +| Drift prevention +| ✓ +| ✓ + +| Mount point awareness +| ✓ +| ✓ +|=== + +[discrete] +[[d4c-overview-how-cwp-for-kubernetes-works]] +== How CWP for Kubernetes works + +CWP for Kubernetes uses a lightweight integration, Defend for Containers (D4C). When you set up the D4C integration, it gets deployed by {agent}. Specifically, the {agent} is installed as a DaemonSet on your Kubernetes clusters, where it enables D4C to use eBPF Linux Security Modules (https://docs.kernel.org/bpf/prog_lsm.html[LSM]) and tracepoint probes to record system events. Events are evaluated against LSM hook points, enabling {agent} to evaluate system activity against your policy before allowing it to proceed. + +Your D4C integration policy determines which system behaviors (for example, process execution or file creation or deletion) will result in which actions. _Selectors_ and _responses_ define each policy. Selectors define the conditions which cause the associated responses to run. Responses are associated with one or more selectors, and specify one or more actions (such as `log`, `alert`, or `block`) that will occur when the conditions defined in an associated selector are met. + +The default D4C policy sends data about all running processes to your {es} cluster. This data is used by {elastic-sec}'s prebuilt detection rules to detect malicious behavior in container workloads. + +[IMPORTANT] +==== +To learn more about D4C policies, including how to create your own, refer to the <>. +==== diff --git a/docs/serverless/cloud-native-security/d4c-policy-guide.asciidoc b/docs/serverless/cloud-native-security/d4c-policy-guide.asciidoc new file mode 100644 index 0000000000..7463f6f386 --- /dev/null +++ b/docs/serverless/cloud-native-security/d4c-policy-guide.asciidoc @@ -0,0 +1,163 @@ +[[d4c-policy-guide]] += Container workload protection policies + +:description: Learn to build policies for cloud workload protection for Kubernetes. +:keywords: security, cloud, reference, manage, cloud security + +preview:[] + +To unlock the full functionality of the Defend for Containers (D4C) integration, you'll need to understand its policy syntax. This will enable you to construct policies that precisely allow expected container behaviors and prevent unexpected behaviors — thereby hardening your container workloads' security posture. + +D4C integration policies consist of _selectors_ and _responses_. Each policy must contain at least one selector and one response. Currently, the system supports two types of selectors and responses: `file` and `process`. +Selectors define which system operations to match and can include multiple conditions (grouped using a logical `AND`) to precisely select events. Responses define which actions to take when a system operation matches the conditions specified in an associated selector. + +The default policy described on this page provides an example that's useful for understanding D4C policies in general. Following the description, you'll find a comprehensive glossary of selector conditions, response fields, and actions. + +[discrete] +[[d4c-default-policies]] +== Default policies: + +The default D4C integration policy includes two selector-response pairs. It is designed to implement core container workload protection capabilities: + +* **Threat Detection:** The first selector-response pair is designed to stream process telemetry data to your {es} cluster so {elastic-sec} can evaluate it to detect threats. Both the selector and response are named `allProcesses`. The selector selects all fork and exec events. The associated response specifies that selected events should be logged. +* **Drift Detection & Prevention:** The second selector-response pair is designed to create alerts when container drift is detected. Both the selector and response are named `executableChanges`. The selector selects all `createExecutable` and `modifyExecutable` events. The associated response specifies that the selected events should create alerts, which will be sent to your {es} cluster. You can modify the response to block drift operations by setting it to block. + +[role="screenshot"] +image::images/d4c-policy-guide/-cloud-native-security-d4c-policy-editor.png[The defend for containers policy editor with the default policies] + +[discrete] +[[d4c-selectors-glossary]] +== Selectors + +A selector requires a name and at least one operation. It will select all events of the specified operation types, unless you also include _conditions_ to narrow down the selection. Some conditions are available for both `file` and `process` selectors, while others only available for one type of selector. + +[discrete] +[[d4c-policy-guide-common-conditions]] +=== Common conditions + +These conditions are available for both `file` and `process` selectors. + +// [cols="1,1", options="header"] + +|=== +| Name| Description + +| containerImageFullName +| A list of full container image names to match on. For example: `docker.io/nginx`. + +| containerImageName +| A list of container image names to match on. For example: `nginx`. + +| containerImageTag +| A list of container image tags to match on. For example: `latest`. + +| kubernetesClusterId +| A list of Kubernetes cluster IDs to match on. For consistency with KSPM, the `kube-system` namespace's UID is used as a cluster ID. + +| kubernetesClusterName +| A list of Kubernetes cluster names to match on. + +| kubernetesNamespace +| A list of Kubernetes namespaces to match on. + +| kubernetesPodName +| A list of Kubernetes pod names to match on. Trailing wildcards supported. + +| kubernetesPodLabel +| A list of resource labels. Trailing wildcards supported (value only), for example: `key1:val*`. +|=== + +[discrete] +[[d4c-policy-guide-file-selector-conditions]] +=== File-selector conditions + +These conditions are available only for `file` selectors. + +// [cols="1,1", options="header"] + +|=== +| Name| Description + +| operation +| The list of system operations to match on. Options include `createExecutable`, `modifyExecutable`, `createFile`, `modifyFile`, `deleteFile`. + +| ignoreVolumeMounts +| If set, ignores file operations on _all_ volume mounts. + +| ignoreVolumeFiles +| If set, ignores operations on file mounts only. For example: mounted files, `configMaps`, and secrets. + +| targetFilePath +| A list of file paths to include. Paths are absolute and wildcards are supported. The `*` wildcard matches any sequence of characters within a single directory, while the `**` wildcard matches any sequence of characters across multiple directories and subdirectories. +|=== + +[NOTE] +==== +In order to ensure precise targeting of file integrity monitoring operations, a `TargetFilePath` is required whenever the `deleteFile`, `modifyFile`, or `createFile` operations are used within a selector. +==== + +[discrete] +[[d4c-policy-guide-process-selector-conditions]] +=== Process-selector conditions + +These conditions are available only for `process` selectors. + +// [cols="1,1", options="header"] + +|=== +| Name| Description + +| operation +| The list of system operations to match on. Options include `fork` and `exec`. + +| processExecutable +| A list of executables (full path included) to match on. For example: `/usr/bin/cat`. Wildcard support is same as targetFilePath above. + +| processName +| A list of process names (executable basename) to match on. For example: `bash`, `vi`, `cat`. + +| sessionLeaderInteractive +| If set to `true`, will only match on interactive sessions (defined as sessions with a controlling TTY). +|=== + +[discrete] +[[d4c-policy-guide-response-fields]] +=== Response fields + +A policy can include one or more responses. Each response is comprised of the following fields: + +// [cols="1,1", options="header"] + +|=== +| Field| Description + +| match +| An array of one or more selectors of the same type (`file` or `process`). + +| exclude +| Optional. An array of one or more selectors to use as exclusions to everything in `match`. + +| actions +| An array of actions to perform when at least one `match` selector matches and none of the `exclude` selectors match. Options include `log`, `alert`, and `block`. +|=== + +[discrete] +[[d4c-policy-guide-response-actions]] +=== Response actions + +D4C responses can include the following actions: + +|=== +| Action | Description + +| log +| Sends events to the `logs-cloud_defend.file-*` data stream for file responses, and the `logs-cloud_defend.process-*` data stream for process responses. + +| alert +| Writes events (file or process) to the `logs-cloud_defend.alerts-*` data stream. + +| block +a| Prevents the system operation from proceeding. This blocking action happens prior to the execution of the event. It is required that the alert action be set if block is enabled. + +**Note:** Currently, block is only supported on file operations. +|=== diff --git a/docs/serverless/cloud-native-security/enable-cloudsec.asciidoc b/docs/serverless/cloud-native-security/enable-cloudsec.asciidoc new file mode 100644 index 0000000000..2edfe856a9 --- /dev/null +++ b/docs/serverless/cloud-native-security/enable-cloudsec.asciidoc @@ -0,0 +1,23 @@ +[[enable-cloudsec]] += Enable cloud security features + +:description: Learn to turn on cloud security features in your project +:keywords: serverless, security, overview + +To use cloud security features in your {elastic-sec} project, you must have the `Cloud Protection Essentials` or `Cloud Protection Complete` options enabled for your project. + +To enable these options or check their current status: + +. Click your project name in the upper-left corner of {kib}. Select **Manage project**. + +[role="screenshot"] +image::images/cloud-security-enable/manage-project.png[The project menu with the manage project button highlighted] + +. To the right of **Project features**, select **Edit**. + +[role="screenshot"] +image::images/cloud-security-enable/project-features-edit.png[The project menu with the manage project button highlighted] + +. Enable the necessary options, then click **Save**. + +Continue with cloud security setup. diff --git a/docs/serverless/cloud-native-security/environment-variable-capture.asciidoc b/docs/serverless/cloud-native-security/environment-variable-capture.asciidoc new file mode 100644 index 0000000000..5d3f9fa83e --- /dev/null +++ b/docs/serverless/cloud-native-security/environment-variable-capture.asciidoc @@ -0,0 +1,42 @@ +[[environment-variable-capture]] += Capture environment variables + +:description: Capture environment variables from monitored Linux sessions. +:keywords: serverless, security, overview, cloud security + +preview:[] + +You can configure an Elastic Defend policy to capture up to five environment variables (`env vars`). + +[NOTE] +==== +* Env var names must be no more than 63 characters, and env var values must be no more than 1023 characters. Values outside these limits are silently ignored. +* Env var names are case sensitive. +==== + +To set up environment variable capture for an {agent} policy: + +. Go to **Assets → Fleet → Agent policies**. +. Select an {agent} policy, then the associated Elastic Defend policy. +. Go to the **Settings** tab, then scroll to the bottom and click **Show advanced settings**. +. Scroll down or search for `linux.advanced.capture_env_vars`, or `mac.advanced.capture_env_vars`. +. Enter the names of env vars you want to capture, separated by commas. For example: `PATH,USER` +. Click **Save**. + +[role="screenshot"] +image::images/environment-variable-capture/-cloud-native-security-env-var-capture.png[The "linux.advanced.capture_env_vars" advanced agent policy setting] + +[discrete] +[[find-cap-env-vars]] +== Find captured environment variables + +Captured environment variables are associated with process events, and appear in each event's `process.env_vars` field. + +To view environment variables in the **Events** table: + +. Click the **Events** tab on the **Hosts**, **Network**, or **Users** pages (**Explore**), then click **Fields** in the Events table. +. Search for the `process.env_vars` field, select it, and click **Close**. +A new column appears containing captured environment variable data. + +[role="screenshot"] +image::images/environment-variable-capture/-cloud-native-security-env-var-capture-detail.png[The Events table with the "process.env_vars" column highlighted] diff --git a/docs/serverless/cloud-native-security/get-started-with-kspm.asciidoc b/docs/serverless/cloud-native-security/get-started-with-kspm.asciidoc new file mode 100644 index 0000000000..27a2d2f3d5 --- /dev/null +++ b/docs/serverless/cloud-native-security/get-started-with-kspm.asciidoc @@ -0,0 +1,446 @@ +[[get-started-with-kspm]] += Get started with KSPM + +:keywords: serverless, security, overview, cloud security + +preview:[] + +This page explains how to configure the Kubernetes Security Posture Management (KSPM) integration. + +.Requirements +[NOTE] +==== +* KSPM only works in the `Default` {kib} space. Installing the KSPM integration on a different {kib} space will not work. +* KSPM is not supported on EKS clusters in AWS GovCloud (https://github.com/elastic/kibana/issues/new/choose[request support]). +* To view posture data, ensure you have the appropriate user role to read the following {es} indices: + +* `logs-cloud_security_posture.findings_latest-*` +* `logs-cloud_security_posture.scores-*` +* `logs-cloud_security_posture.findings` +==== + +The instructions differ depending on whether you're installing on EKS or on unmanaged clusters. + +* Install on EKS-managed clusters: ++ +.. <> +.. <> +.. <> +.. <> +* Install on unmanaged clusters: ++ +.. <> +.. <> + +[discrete] +[[kspm-setup-eks-start]] +== Set up KSPM for Amazon EKS clusters + +[discrete] +[[get-started-with-kspm-name-your-integration-and-select-a-kubernetes-deployment-type]] +=== Name your integration and select a Kubernetes Deployment type + +. Go to **Dashboards → Cloud Security Posture**. +. Click **Add a KSPM integration**. +. Read the integration's description to understand how it works. Then, click {integrations-docs}/cloud_security_posture[_Add Kubernetes Security Posture Management_]. +. Name your integration. Use a name that matches the purpose or team of the cluster(s) you want to monitor, for example, `IT-dev-k8s-clusters`. +. Select **EKS** from the **Kubernetes Deployment** menu. A new section for AWS credentials will appear. + +[discrete] +[[kspm-setup-eks-auth]] +=== Authenticate to AWS + +There are several options for how to provide AWS credentials: + +* <> +* <> +* <> +* <> +* <> +* <> + +Regardless of which option you use, you'll need to grant the following permissions: + +[source,console] +---- +ecr:GetRegistryPolicy, +eks:ListTagsForResource +elasticloadbalancing:DescribeTags +ecr-public:DescribeRegistries +ecr:DescribeRegistry +elasticloadbalancing:DescribeLoadBalancerPolicyTypes +ecr:ListImages +ecr-public:GetRepositoryPolicy +elasticloadbalancing:DescribeLoadBalancerAttributes +elasticloadbalancing:DescribeLoadBalancers +ecr-public:DescribeRepositories +eks:DescribeNodegroup +ecr:DescribeImages +elasticloadbalancing:DescribeLoadBalancerPolicies +ecr:DescribeRepositories +eks:DescribeCluster +eks:ListClusters +elasticloadbalancing:DescribeInstanceHealth +ecr:GetRepositoryPolicy +---- + +If you are using the AWS visual editor to create and modify your IAM Policies, you can copy and paste this IAM policy JSON object: + +.Click to view JSON object +[%collapsible] +===== +[source] +---- +{ + "Version": "2012-10-17", + "Statement": [ + { + "Sid": "VisualEditor0", + "Effect": "Allow", + "Action": [ + "ecr:GetRegistryPolicy", + "eks:ListTagsForResource", + "elasticloadbalancing:DescribeTags", + "ecr-public:DescribeRegistries", + "ecr:DescribeRegistry", + "elasticloadbalancing:DescribeLoadBalancerPolicyTypes", + "ecr:ListImages", + "ecr-public:GetRepositoryPolicy", + "elasticloadbalancing:DescribeLoadBalancerAttributes", + "elasticloadbalancing:DescribeLoadBalancers", + "ecr-public:DescribeRepositories", + "eks:DescribeNodegroup", + "ecr:DescribeImages", + "elasticloadbalancing:DescribeLoadBalancerPolicies", + "ecr:DescribeRepositories", + "eks:DescribeCluster", + "eks:ListClusters", + "elasticloadbalancing:DescribeInstanceHealth", + "ecr:GetRepositoryPolicy" + ], + "Resource": "*" + } + ] +} +---- +===== + +[discrete] +[[kspm-use-irsa]] +==== Option 1 - [Recommended] Use Kubernetes Service Account to assume IAM role + +Follow AWS's https://aws.github.io/aws-eks-best-practices/security/docs/iam/#iam-roles-for-service-accounts-irsa[EKS Best Practices] documentation to use the https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html[IAM Role to Kubernetes Service-Account] (IRSA) feature to get temporary credentials and scoped permissions. + +[IMPORTANT] +==== +During setup, do not fill in any option in the "Setup Access" section. Click **Save and continue**. +==== + +[discrete] +[[kspm-use-instance-role]] +==== Option 2 - Use default instance role + +Follow AWS's https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html[IAM roles for Amazon EC2] documentation to create an IAM role using the IAM console, which automatically generates an instance profile. + +[IMPORTANT] +==== +During setup, do not fill in any option in the "Setup Access" section. Click **Save and continue**. +==== + +[discrete] +[[kspm-use-keys-directly]] +==== Option 3 - Use access keys directly + +Access keys are long-term credentials for an IAM user or AWS account root user. To use access keys as credentials, you must provide the `Access key ID` and the `Secret Access Key`. + +For more details, refer to AWS' https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html[Access Keys and Secret Access Keys] documentation. + +[IMPORTANT] +==== +You must select "Programmatic access" when creating the IAM user. +==== + +[discrete] +[[kspm-use-temp-credentials]] +==== Option 4 - Use temporary security credentials + +You can configure temporary security credentials in AWS to last for a specified duration. They consist of an access key ID, a secret access key, and a security token, which is typically found using `GetSessionToken`. + +Because temporary security credentials are short term, once they expire, you will need to generate new ones and manually update the integration's configuration to continue collecting cloud posture data. Update the credentials before they expire to avoid data loss. + +[NOTE] +==== +IAM users with multi-factor authentication (MFA) enabled need to submit an MFA code when calling `GetSessionToken`. For more details, refer to AWS' https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html[Temporary Security Credentials] documentation. +==== + +You can use the AWS CLI to generate temporary credentials. For example, you could use the following command if you have MFA enabled: + +[source,console] +---- +`sts get-session-token --serial-number arn:aws:iam::1234:mfa/your-email@example.com --duration-seconds 129600 --token-code 123456` +---- + +The output from this command includes the following fields, which you should provide when configuring the KSPM integration: + +* `Access key ID`: The first part of the access key. +* `Secret Access Key`: The second part of the access key. +* `Session Token`: A token required when using temporary security credentials. + +[discrete] +[[kspm-use-a-shared-credentials-file]] +==== Option 5 - Use a shared credentials file + +If you use different AWS credentials for different tools or applications, you can use profiles to define multiple access keys in the same configuration file. For more details, refer to AWS' https://docs.aws.amazon.com/sdkref/latest/guide/file-format.html[Shared Credentials Files] documentation. + +Instead of providing the `Access key ID` and `Secret Access Key` to the integration, provide the information required to locate the access keys within the shared credentials file: + +* `Credential Profile Name`: The profile name in the shared credentials file. +* `Shared Credential File`: The directory of the shared credentials file. + +If you don't provide values for all configuration fields, the integration will use these defaults: + +* If `Access key ID`, `Secret Access Key`, and `ARN Role` are not provided, then the integration will check for `Credential Profile Name`. +* If there is no `Credential Profile Name`, the default profile will be used. +* If `Shared Credential File` is empty, the default directory will be used. ++ +** For Linux or Unix, the shared credentials file is located at `~/.aws/credentials`. + +[discrete] +[[kspm-use-iam-arn]] +==== Option 6 - Use an IAM role Amazon Resource Name (ARN) + +An IAM role Amazon Resource Name (ARN) is an IAM identity that you can create in your AWS account. You define the role's permissions. +Roles do not have standard long-term credentials such as passwords or access keys. +Instead, when you assume a role, it provides temporary security credentials for your session. +An IAM role's ARN can be used to specify which AWS IAM role to use to generate temporary credentials. + +For more details, refer to AWS' https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html[AssumeRole API] documentation. +Follow AWS' instructions to https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html[create an IAM user], and define the IAM role's permissions using the JSON permissions policy above. + +To use an IAM role's ARN, you need to provide either a <> or <> along with the `ARN role`. +The `ARN Role` value specifies which AWS IAM role to use for generating temporary credentials. + +[NOTE] +==== +If `ARN Role` is present, the integration will check if `Access key ID` and `Secret Access Key` are present. +If not, the package will check for a `Credential Profile Name`. +If a `Credential Profile Name` is not present, the default credential profile will be used. +==== + +[discrete] +[[kspm-setup-eks-finish]] +=== Finish configuring the KSPM integration for EKS + +Once you've provided AWS credentials, finish configuring the KSPM integration: + +. If you want to monitor Kubernetes clusters that aren’t yet enrolled in {fleet}, select **New Hosts** under “where to add this integration”. +. Name the {agent} policy. Use a name that matches the purpose or team of the cluster(s) you want to monitor. For example, `IT-dev-k8s-clusters`. +. Click **Save and continue**, then **Add agent to your hosts**. The **Add agent** wizard appears and provides a DaemonSet manifest `.yaml` file with pre-populated configuration information, such as the `Fleet ID` and `Fleet URL`. + +[discrete] +[[kspm-setup-eks-modify-deploy]] +=== Deploy the KSPM integration to EKS clusters + +The **Add agent** wizard helps you deploy the KSPM integration on the Kubernetes clusters you wish to monitor. For each cluster: + +. Download the manifest and make any necessary revisions to its configuration to suit the needs of your environment. +. Apply the manifest using the `kubectl apply -f` command. For example: `kubectl apply -f elastic-agent-managed-kubernetes.yaml` + +After a few minutes, a message confirming the {agent} enrollment appears, followed by a message confirming that data is incoming. You can then click **View assets** to see where the newly-collected configuration information appears, including the <> and the <>. + +[discrete] +[[kspm-setup-unmanaged]] +== Set up KSPM for unmanaged Kubernetes clusters + +Follow these steps to deploy the KSPM integration to unmanaged clusters. Keep in mind credentials are NOT required for unmanaged deployments. + +[discrete] +[[get-started-with-kspm-configure-the-kspm-integration]] +=== Configure the KSPM integration + +To install the integration on unmanaged clusters: + +. Go to **Dashboards → Cloud Security Posture**. +. Click **Add a KSPM integration**. +. Read the integration's description to understand how it works. Then, click {integrations-docs}/cloud_security_posture[_Add Kubernetes Security Posture Management_]. +. Name your integration. Use a name that matches the purpose or team of the cluster(s) you want to monitor, for example, `IT-dev-k8s-clusters`. +. Select **Unmanaged Kubernetes** from the **Kubernetes Deployment** menu. +. If you want to monitor Kubernetes clusters that aren’t yet enrolled in {fleet}, select **New Hosts** when choosing the {agent} policy. +. Select the {agent} policy where you want to add the integration. +. Click **Save and continue**, then **Add agent to your hosts**. The **Add agent** wizard appears and provides a DaemonSet manifest `.yaml` file with pre-populated configuration information, such as the `Fleet ID` and `Fleet URL`. + +[role="screenshot"] +image::images/get-started-with-kspm/-cloud-native-security-kspm-add-agent-wizard.png[The KSPM integration's Add agent wizard] + +[discrete] +[[kspm-setup-unmanaged-modify-deploy]] +=== Deploy the KSPM integration to unmanaged clusters + +The **Add agent** wizard helps you deploy the KSPM integration on the Kubernetes clusters you wish to monitor. To do this, for each cluster: + +. Download the manifest and make any necessary revisions to its configuration to suit the needs of your environment. +. Apply the manifest using the `kubectl apply -f` command. For example: `kubectl apply -f elastic-agent-managed-kubernetes.yaml` + +After a few minutes, a message confirming the {agent} enrollment appears, followed by a message confirming that data is incoming. You can then click **View assets** to see where the newly-collected configuration information appears, including the <> and the <>. + +[discrete] +[[kspm-eck]] +=== Set up KSPM on ECK deployments + +To run KSPM on an https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-quickstart.html[ECK] deployment, +you must edit the https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-elastic-agent-configuration.html[Elastic Agent CRD] and https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-elastic-agent-configuration.html#k8s-elastic-agent-role-based-access-control[Elastic Agent Cluster-Role] `.yaml` files. + +.Patch Elastic Agent +[%collapsible] +===== +Add `volumes` and `volumeMounts` to `podTemplate`: + +[source,yaml] +---- +podTemplate: + spec: + containers: + - name: agent + volumeMounts: + - name: proc + mountPath: /hostfs/proc + readOnly: true + - name: cgroup + mountPath: /hostfs/sys/fs/cgroup + readOnly: true + - name: varlibdockercontainers + mountPath: /var/lib/docker/containers + readOnly: true + - name: varlog + mountPath: /var/log + readOnly: true + - name: etc-full + mountPath: /hostfs/etc + readOnly: true + - name: var-lib + mountPath: /hostfs/var/lib + readOnly: true + - name: etc-mid + mountPath: /etc/machine-id + readOnly: true + volumes: + - name: proc + hostPath: + path: /proc + - name: cgroup + hostPath: + path: /sys/fs/cgroup + - name: varlibdockercontainers + hostPath: + path: /var/lib/docker/containers + - name: varlog + hostPath: + path: /var/log + - name: etc-full + hostPath: + path: /etc + - name: var-lib + hostPath: + path: /var/lib + # Mount /etc/machine-id from the host to determine host ID + # Needed for Elastic Security integration + - name: etc-mid + hostPath: + path: /etc/machine-id + type: File +---- +===== + +.Patch RBAC +[%collapsible] +===== +Make sure that the `elastic-agent` service-account has the following Role and ClusterRole: + +[source,yaml] +---- +apiVersion: rbac.authorization.k8s.io/v1 +kind: RoleBinding +metadata: + namespace: default + name: elastic-agent +subjects: +- kind: ServiceAccount + name: elastic-agent + namespace: default +roleRef: + kind: Role + name: elastic-agent + apiGroup: rbac.authorization.k8s.io +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: elastic-agent + labels: + k8s-app: elastic-agent +rules: +- apiGroups: [""] + resources: + - nodes + - namespaces + - events + - pods + - services + - configmaps + - serviceaccounts + - persistentvolumes + - persistentvolumeclaims + verbs: ["get", "list", "watch"] +- apiGroups: ["extensions"] + resources: + - replicasets + verbs: ["get", "list", "watch"] +- apiGroups: ["apps"] + resources: + - statefulsets + - deployments + - replicasets + - daemonsets + verbs: ["get", "list", "watch"] +- apiGroups: + - "" + resources: + - nodes/stats + verbs: + - get +- apiGroups: [ "batch" ] + resources: + - jobs + - cronjobs + verbs: [ "get", "list", "watch" ] +- nonResourceURLs: + - "/metrics" + verbs: + - get +- apiGroups: ["rbac.authorization.k8s.io"] + resources: + - clusterrolebindings + - clusterroles + - rolebindings + - roles + verbs: ["get", "list", "watch"] +- apiGroups: ["policy"] + resources: + - podsecuritypolicies + verbs: ["get", "list", "watch"] +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: Role +metadata: + name: elastic-agent + namespace: default + labels: + k8s-app: elastic-agent +rules: + - apiGroups: + - coordination.k8s.io + resources: + - leases + verbs: ["get", "create", "update"] +---- +===== diff --git a/docs/serverless/cloud-native-security/kspm.asciidoc b/docs/serverless/cloud-native-security/kspm.asciidoc new file mode 100644 index 0000000000..eabf076a30 --- /dev/null +++ b/docs/serverless/cloud-native-security/kspm.asciidoc @@ -0,0 +1,86 @@ +[[kspm]] += Kubernetes security posture management + +:description: Identify configuration risks in your Kubernetes clusters. +:keywords: serverless, security, overview, cloud security + +preview:[] + +[discrete] +[[kspm-overview]] +== Overview + +The Kubernetes Security Posture Management (KSPM) integration allows you to identify configuration risks in the various components that make up your Kubernetes cluster. +It does this by evaluating your Kubernetes clusters against secure configuration guidelines defined by the Center for Internet Security (CIS) and generating findings with step-by-step instructions for remediating potential security risks. + +This integration supports Amazon EKS and unmanaged Kubernetes clusters. For setup instructions, refer to <>. + +.Requirements +[NOTE] +==== +* KSPM only works in the `Default` {kib} space. Installing the KSPM integration on a different {kib} space will not work. +* KSPM is not supported on EKS clusters in AWS GovCloud (https://github.com/elastic/kibana/issues/new/choose[request support]). +* To view posture data, ensure you have the appropriate user role to read the following {es} indices: + +* `logs-cloud_security_posture.findings_latest-*` +* `logs-cloud_security_posture.scores-*` +* `logs-cloud_security_posture.findings` +==== + +[discrete] +[[kspm-how-kspm-works]] +== How KSPM works + +. When you add a KSPM integration, it generates a Kubernetes manifest. When applied to a cluster, the manifest deploys an {agent} as a https://kubernetes.io/docs/concepts/workloads/controllers/daemonset[DaemonSet] to ensure all nodes are evaluated. +. Upon deployment, the integration immediately assesses the security posture of your Kubernetes resources. The evaluation process repeats every four hours. +. After each evaluation, the integration sends findings to {es}. Findings appear on the <> and the <> page. + +[discrete] +[[kspm-use-cases]] +== Use cases + +The KSPM integration helps you to: + +* Identify and remediate `failed` findings +* Identify the most misconfigured resources +* Identify risks in particular CIS benchmark sections + +[discrete] +[[kspm-remediate-failed-findings]] +=== Identify and remediate failed findings + +To identify and remediate failed failed findings: + +. Go to the <>. +. Click **View all failed findings**, either for an individual cluster or for all monitored clusters. +. Click a failed finding. The findings flyout opens. +. Follow the steps under **Remediation** to correct the misconfiguration. ++ +[NOTE] +==== +Remediation steps typically include commands for you to execute. These sometimes contain placeholder values that you must replace before execution. +==== + +[discrete] +[[kspm-identify-misconfigured-resources]] +=== Identify the most misconfigured Kubernetes resources + +To identify the Kubernetes resources generating the most failed findings: + +. Go to the <> page. +. Click the **Group by** menu near the search box and select **Resource** to view a list of resources sorted by their total number of failed findings. +. Click a resource ID to view the findings associated with that resource. + +[discrete] +[[kspm-identify-config-risks-by-section]] +=== Identify configuration risks by CIS section + +To identify risks in particular CIS sections: + +. Go to the <> (**Dashboards → Cloud Security Posture**). +. In the Failed findings by CIS section widget, click the name of a CIS section to view all failed findings for that section. + +Alternatively: + +. Go to the Findings page. +. Filter by the `rule.section` field. For example, search for `rule.section : API Server` to view findings for benchmark rules in the API Server category. diff --git a/docs/serverless/cloud-native-security/security-posture-faq.asciidoc b/docs/serverless/cloud-native-security/security-posture-faq.asciidoc new file mode 100644 index 0000000000..73f9c8f76b --- /dev/null +++ b/docs/serverless/cloud-native-security/security-posture-faq.asciidoc @@ -0,0 +1,89 @@ +[[security-posture-faq]] += Frequently asked questions (FAQ) + +:description: Frequently asked questions about the CSPM integration. +:keywords: serverless, security, overview, cloud security + +preview:[] + +[discrete] +[[cspm-faq]] +== CSPM FAQ + +Frequently asked questions about the Cloud Security Posture Management (CSPM) integration and features. + +**How often is my cloud security posture evaluated?** + +Cloud accounts are evaluated when you first deploy the CSPM integration and every 24 hours afterward. + +**Can I onboard multiple accounts at one time?** + +Yes. Follow the onboarding instructions in the getting started guides for AWS, GCP, or Azure. + +**When do newly enrolled cloud accounts appear on the dashboard?** + +After you deploy the CSPM integration, it can take up to 10 minutes for resource fetching, evaluation, and data processing before a newly enrolled account appears on the Cloud Security Posture dashboard. + +**When do unenrolled cloud accounts disappear from the dashboard?** + +Newly unenrolled cloud accounts can take a maximum of 24 hours to disappear from the Cloud Security Posture dashboard. + +[discrete] +[[kspm-faq]] +== KSPM FAQ + +Frequently asked questions about the Kubernetes Security Posture Management (KSPM) integration and features. + +**What versions of Kubernetes are supported?** + +For self-managed/vanilla clusters, Kubernetes version 1.23 is supported. + +**Do benchmark rules support multiple Kubernetes deployment types?** +Yes. There are different sets of benchmark rules for self-managed and third party-managed deployments. Refer to <> for more information about setting up each deployment type. + +**Can I evaluate the security posture of my Amazon EKS clusters?** +Yes. KSPM currently supports the security posture evaluation of Amazon EKS and unmanaged Kubernetes clusters. + +**How often is my cluster’s security posture evaluated?** +Clusters are evaluated when you deploy a KSPM integration, and every four hours after that. + +**When do newly-enrolled clusters appear on the dashboard?** +It can take up to 10 minutes for deployment, resource fetching, evaluation, and data processing to complete before a newly-enrolled cluster appears on the dashboard. + +**When do unenrolled clusters disappear from the dashboard?** +A cluster will disappear as soon as the KSPM integration fetches data while that cluster is not enrolled. The fetch process repeats every four hours, which means a newly unenrolled cluster can take a maximum of four hours to disappear from the dashboard. + +[discrete] +[[security-posture-faq-findings-page]] +== Findings page + +**Are all the findings page current?** +Yes. Only the most recent findings appear on the Findings page. + +**Can I build custom visualizations and dashboards that incorporate findings data?** +Yes. You can use {kib}'s custom visualization capabilities with findings data. To learn more, refer to {kibana-ref}/dashboard.html[Dashboards and visualizations]. + +**Where is Findings data saved?** +You can access findings data using the following index patterns: + +* **Current findings:** `logs-cloud_security_posture.findings_latest-*` +* **Historical findings:** `logs-cloud_security_posture.findings-*` + +[discrete] +[[security-posture-faq-benchmark-rules]] +== Benchmark rules + +**How often are my resources evaluated against benchmark rules?** +Resources are fetched and evaluated against benchmark rules when a security posture management integration is deployed. After that, the CSPM integration evaluates every 24 hours, and the KSPM integration evaluates every four hours. + +**Can I configure an integration's fetch cycle?** +No, the fetch cycle's timing is not configurable. + +**Can I contribute to the CSP ruleset?** +You can't directly edit benchmark rules. The rules are defined https://github.com/elastic/csp-security-policies[in this repository], where you can raise issues with certain rules. They are written in https://www.openpolicyagent.org/docs/latest/policy-language/[Rego]. + +**How can I tell which specific version of the CIS benchmarks is in use?** +Refer to the `rule.benchmark.name` and `rule.benchmark.version` fields for documents in these datastreams: + +* `logs-cloud_security_posture.findings-default` +* `logs-cloud_security_posture.findings_latest-default` diff --git a/docs/serverless/cloud-native-security/security-posture-management.asciidoc b/docs/serverless/cloud-native-security/security-posture-management.asciidoc new file mode 100644 index 0000000000..660c91f7eb --- /dev/null +++ b/docs/serverless/cloud-native-security/security-posture-management.asciidoc @@ -0,0 +1,50 @@ +[[security-posture-management]] += Security posture management overview + +:description: Discovers and evaluates your cloud services and resources against security best practices. +:keywords: serverless, security, overview, cloud security + +preview:[] + +[discrete] +== Overview + +Elastic's <> (CSPM) and <> (KSPM) features help you discover and evaluate the services and resources in your cloud environment — like storage, compute, IAM, and more — against security guidelines defined by the Center for Internet Security (CIS). They help you identify and remediate configuration risks that could undermine the confidentiality, integrity, and availability of your cloud assets, such as publicly exposed storage buckets or overly permissive networking objects. + +The KSPM feature assesses the security of your Kubernetes assets, while the CSPM feature assesses the security of your AWS resources such as storage, compute, IAM, and more. + +[discrete] +[[security-posture-management-get-started]] +== Getting started + +For setup instructions, refer to: + +* <> +* <> + +[discrete] +[[security-posture-use-cases]] +== Use cases + +Using the data generated by these features, you can: + +**Identify and secure misconfigured infrastructure:** + +. Go to the Cloud Security Posture dashboard (**Dashboards → Cloud Security Posture**). +. Click **View all failed findings**, either for an individual resource or a group of resources. +. Click a failed finding to open the Findings flyout. +. Follow the steps under Remediation to fix the misconfiguration. + +**Identify the CIS Sections (security best practice categories) with which your resources are least compliant:** + +. Go to the Cloud Security Posture dashboard (**Dashboards → Cloud Security Posture**). +. Do one of the following: ++ +.. Under Failed findings by CIS section, click the name of a CIS section to view all failed findings from that section. +.. Go to the **Findings** page and filter by the `rule.section` field. For example, search for `rule.section : API Server` to view findings from the API Server category. + +**Identify your least compliant cloud resources** + +. Go to the **Findings** page. +. Click the **Group by** menu near the search box, and select **Resource** to sort resources by their number of failed findings. +. Click a resource ID to view associated findings. diff --git a/docs/serverless/cloud-native-security/session-view.asciidoc b/docs/serverless/cloud-native-security/session-view.asciidoc new file mode 100644 index 0000000000..f5465ca41c --- /dev/null +++ b/docs/serverless/cloud-native-security/session-view.asciidoc @@ -0,0 +1,166 @@ +[[session-view]] += Session View + +:description: Examine Linux process data in context with Session View. +:keywords: serverless, security, overview, how to, cloud security + +preview:[] + +Session View is an investigation tool that allows you to examine Linux process data organized +in a tree-like structure according to the Linux logical event model, with processes organized by parentage and time of execution. +It displays events in a highly readable format that is inspired by the terminal. This makes it a powerful tool for monitoring +and investigating session activity on your Linux infrastructure and understanding user and service behavior. + +Session View has the following features: + +* **Interactive and non-interactive processes:** Processes and services with or without a controlling terminal. +* **User information:** The Linux user that executed each session or process, and any exec user changes. +* **Process and event telemetry:** Process information included in the Linux logical event model. +* **Nested sessions:** Sessions started by processes descended from the entry session. +* **Alerts:** Process, file, and network alerts in the context of the events which caused them. +* **Terminal output:** Terminal output associated with each process in the session. + +[NOTE] +==== +To view Linux session data from your Kubernetes infrastructure, you'll need to set up the <>. +==== + +[discrete] +[[enable-session-view]] +== Enable Session View data + +Session View uses process data collected by the {elastic-defend} integration, +but this data is not always collected by default. To confirm that Session View data is enabled: + +. Go to **Assets** → **Policies**, select a policy and then edit one or more of your {elastic-defend} integration policies. +. Select the **Settings** tab, then scroll down to the Linux event collection section near the bottom. +. Check the box for **Process** events, and turn on the **Collect session data** toggle. +. If you want to include file and network alerts in Session View, check the boxes for **Network** and **File** events. +. If you want to enable terminal output capture, turn on the **Capture terminal output** toggle. + +Session View can only display data that was collected by {elastic-defend} when **Collect session data** was enabled. When this setting is enabled, {elastic-defend} includes additional process context data in captured process, file, and network events. For more information about the additional +fields collected when this setting is enabled, refer to the https://github.com/elastic/ecs/blob/main/rfcs/text/0030-linux-event-model.md[Linux event model RFC]. + +[discrete] +[[open-session-view]] +== Open Session View + +Session View is accessible from the **Hosts**, **Alerts**, and **Timelines** pages, as well as the **Kubernetes** dashboard. +Events and sessions that you can investigate in Session View have a rectangular +**Open Session View** button in the **Actions** column. For example: + +* On the Alerts page, scroll down to view the Alerts table. +Look for alerts that have the **Open Session View** button in the **Actions** column: + +[role="screenshot"] +image::images/session-view/-detections-session-view-action-icon-detail.png[Detail of the Open Session View button] + +* On the Hosts page (**Explore** → **Hosts**), select the **Sessions** or the **Events** tab. +From either of these tabs, click the **Open Session View** button for an event or session. + +[discrete] +[[session-view-ui]] +== Session View UI + +The Session View UI has the following features: + +[role="screenshot"] +image::images/session-view/-detections-session-view-terminal-labeled.png[Detail of Session view with labeled UI elements] + +. The **Close Session** and **Full screen** buttons. +. The search bar. Use it to find and highlight search terms within the current session. +The left and right arrows allow you to navigate through search results. +. The **display settings** button. Click to toggle Timestamps and Verbose mode. +With Verbose mode enabled, Session View shows all processes created in a session, including shell startup, +shell completion, and forks caused by built-in commands. +It defaults to **off** to highlight the data most likely to be user-generated and non-standard. +. The **Detail panel** button. Click it to toggle the Detail panel, which appears below the button +and displays a wide range of additional information about the selected process’s ancestry and host, +and any associated alerts. To select a process in Session View, click on it. +. The startup process. In this example, it shows that the session was a bash session. +It also shows the Linux user "Ubuntu" started the session. +. The **Child processes** button. Click to expand or collapse a process’s children. +You can also expand collapsed alerts and scripts where they appear. +Collapsed processes will automatically expand when their contents match a search. +. The **Alerts** button. Click to show alerts caused by the parent process. In this example, the `(2)` indicates that there are two alerts. Note the red line to the left of the event that caused the alert. Both alerts caused by this event are `process` alerts, as indicated by the gear icon. +. The **Terminal output** button. Hover to see how much output data has been captured from the session. Click to open the terminal output view, which is described in detail below. +. The **Refresh session** button. Click to check for any new data from the current session. + +Session View includes additional badges not pictured above: + +//// +/* +//* The **Script** button allows you to expand or collapse executed scripts: */ +//// + +//// +/* +//[role="screenshot"] */ +//// + +// + +* The alert badge for multiple alerts appears when a single event causes alerts of multiple types (image:images/icons/gear.svg[Settings] for `process` alerts, image:images/icons/document.svg[Document] for `file` alerts, and image:images/icons/globe.svg[Network] for `network` alerts): ++ +[role="screenshot"] +image:images/session-view/-cloud-native-security-session-view-alert-types-badge.png[The alert badge for a command with all three alert types] +* The **Exec user change** badge highlights exec user changes, such as when a user escalates to root: ++ +[role="screenshot"] +image:images/session-view/-detections-session-view-exec-user-change-badge.png[The Exec user change badge] +* The **Output** badge appears next to commands that generated terminal output. Click it to view that command's output in terminal output view. ++ +[role="screenshot"] +image:images/session-view/-detections-session-view-output-badge.png[The Output badge] + +[discrete] +[[session-view-output]] +== Terminal output view UI + +.Requirements +[NOTE] +==== +* Session output can only be collected from Linux OSes with eBPF-enabled kernels versions 5.10.16 or higher. +==== + +In general, terminal output is the text that appears in interactive Linux shell sessions. This generally includes user-entered text (terminal input), which appears as output to facilitate editing commands, as well as the text output of executed programs. In certain cases such as password entry, terminal input is not captured as output. + +From a security perspective, terminal output is important because it offers a means of exfiltrating data. For example, a command like `cat tls-private-key.pem` could output a web server's private key. Thus, terminal output view can improve your understanding of commands executed by users or adversaries, and assist with auditing and compliance. + +To enable terminal output data capture: + +. Go to **Assets** → **Policies**, select a policy and then edit one or more of your {elastic-defend} integration policies. +. On the **Settings** tab, scroll down to the Linux event collection section near the bottom of the page +and select the **Collect session data** and **Capture terminal output** options. + +You can configure several additional settings by clicking **Advanced settings** at the bottom of the page: + +* `linux.advanced.tty_io.max_kilobytes_per_process`: The maximum number of kilobytes of output to record from a single process. Default: 512 KB. Process output exceeding this value will not be recorded. +* `linux.advanced.tty_io.max_kilobytes_per_event`: The maximum number of kilobytes of output to send to {es} as a single event. Default: 512 KB. Additional data is captured as a new event. +* `linux.advanced.tty_io.max_event_interval_seconds`: The maximum interval (in seconds) during which output is batched. Default: 30 seconds. Output will be sent to {es} at this interval (unless it first exceeds the `max_kilobytes_per_event` value, in which case it might be sent sooner). + +[role="screenshot"] +image::images/session-view/-detections-session-view-output-viewer.png[Terminal output view] + +. Search bar. Use to find and highlight search terms within the current session. +The left and right arrows allow you to navigate through search results. +. Right-side scroll bar. Use along with the bottom scroll bar to navigate output data that doesn't fit on a single screen. +. Playback controls and progress bar. Use to advance or rewind the session's commands and output. Click anywhere on the progress bar to jump to that part of the session. The marks on the bar represent processes that generated output. Click them or the **Prev** and **Next** buttons to skip between processes. +. **Fit screen**, **Zoom in**, and **Zoom out** buttons. Use to adjust the text size. + +[TIP] +==== +Use Session view's **Fullscreen** button (located next to the **Close session viewer** button) to better fit output with long lines, such as for graphical programs like `vim`. +==== + +[discrete] +[[terminal-output-limitations]] +=== Terminal output limitations for search and alerting + +You should understand several current limitations before building rules based on terminal output data: + +* Terminal output that appears in the `process.io.text` field includes https://gist.github.com/fnky/458719343aabd01cfb17a3a4f7296797[ANSI codes] that represent, among other things, text color, text weight, and escape sequences. This can prevent EKS queries from matching as expected. Queries of this data will have more success matching single words than more complex strings. +* Queries of this data should include leading and trailing wildcards (for example `process where process.io.text : "*sudo*"`), since output events typically include multiple lines of output. +* The search functionality built into terminal output view is subject to similar limitations. For example, if a user accidentally entered `sdo` instead of `sudo`, then pressed backspace twice to fix the typo, the recorded output would be `sdo\b\budo`. This would appear in the terminal output view as `sudo`, but searching terminal output view for `sudo` would not result in a match. +* Output that seems like it should be continuous may be split into multiple events due to the advanced settings described above, which may prevent a query or search from matching as expected. +* Rules based on output data will identify which output event's `process.io.text` value matched the alert query, without identifying which specific part of that value matched. For example, the rule query `process.io.text: "*test*"` could match a large, multi-line log file due to a single instance of `test`, without identifying where in the file the instance occurred. diff --git a/docs/serverless/cloud-native-security/vuln-management-faq.asciidoc b/docs/serverless/cloud-native-security/vuln-management-faq.asciidoc new file mode 100644 index 0000000000..ad53c2f657 --- /dev/null +++ b/docs/serverless/cloud-native-security/vuln-management-faq.asciidoc @@ -0,0 +1,65 @@ +[[vuln-management-faq]] += Frequently asked questions (FAQ) + +:description: Frequently asked questions about the CNVM integration. +:keywords: security, cloud, reference, manage + +preview:[] + +Frequently asked questions about the Cloud Native Vulnerability Management (CNVM) integration and features. + +**Which security data sources does the CNVM integration use to identify vulnerabilities?** + +The CNVM integration uses various security data sources. The complete list can be found https://github.com/aquasecurity/trivy/blob/v0.35.0/docs/docs/vulnerability/detection/data-source.md[here]. + +**What's the underlying scanner used by CNVM integration?** + +CNVM uses the open source scanner https://github.com/aquasecurity/trivy[Trivy] v0.35. + +**What system architectures are supported?** + +Because of Trivy's limitations, CNVM can only be deployed on ARM-based VMs. However, it can scan hosts regardless of system architecture. + +**How often are the security data sources synchronized?** + +The CNVM integration fetches the latest data sources at the beginning of every scan cycle to ensure up-to-date vulnerability information. + +**What happens if a scan cycle does not complete within 24 hours?** + +If a scan cycle doesn't finish within 24 hours, the ongoing cycle will continue until completion. When it finishes, a new cycle will immediately start. + +**How is the lifecycle of snapshots handled?** + +The CNVM integration manages the lifecycle of snapshots. Snapshots are automatically deleted/removed at the end of each scan cycle. + +**Does CNVM have an impact on the user's cloud expenses?** + +Yes, CNVM creates additional cloud expenses, since scanning involves provisioning a new virtual machine to conduct the scan. + +**Does CNVM also scan the new AWS EC2 instances that it creates?** + +Yes, CNVM scans all AWS EC2 instances in every scan cycle, including any created by the integration. + +**Does CNVM scan AWS EC2 instances with encrypted volumes?** + +Encrypted volumes can be scanned only if they were encrypted using Amazon's default EBS key, and are _not_ running Amazon Linux 2023. + +**Does CNVM prevent multiple installations in a single region?** + +No, CNVM does not currently prevent redundant deployment to the same region. + +**What volume types and file systems does CNVM support?** + +CNVM supports all AWS EBS volume types and works with `ext4` and `xfs` file systems. + +**Does CNVM scan stopped EC2 instances?** + +Yes, CNVM scans all EC2 instances, whether they are running or stopped, to ensure comprehensive vulnerability detection. + +**What AWS permissions does the user require to run the CloudFormation template for CNVM onboarding?** + +To run the CloudFormation template for CNVM onboarding, you need an AWS user account with permissions to perform the following actions: run CloudFormation templates, create IAM Roles and InstanceProfiles, and create EC2 SecurityGroups and Instances. + +**Why do I get an error when I try to run the CloudFormation template?** + +It's possible you're using an unsupported region. Currently the `eu-north-1` and `af-south-1` regions are not supported because they don't provide the required instance types. diff --git a/docs/serverless/cloud-native-security/vuln-management-findings.asciidoc b/docs/serverless/cloud-native-security/vuln-management-findings.asciidoc new file mode 100644 index 0000000000..23c88e842b --- /dev/null +++ b/docs/serverless/cloud-native-security/vuln-management-findings.asciidoc @@ -0,0 +1,91 @@ +[[vuln-management-findings]] += Findings page + +:description: The Findings page displays information about cloud vulnerabilities found in your environment. +:keywords: serverless, security, overview, cloud security + +preview:[] + +The **Vulnerabilities** tab on the Findings page displays the vulnerabilities detected by the <>. + +[role="screenshot"] +image::images/vuln-management-findings/-cloud-native-security-cnvm-findings-page.png[The Vulnerabilities tab of the Findings page] + +[discrete] +[[vuln-management-findings-what-are-cnvm-findings]] +== What are CNVM findings? + +CNVM findings represent security vulnerabilities detected in your cloud. They include metadata such as the CVE identifier, CVSS score, severity, affected package, and fix version if available, as well as information about impacted systems. + +Clicking on a finding provides a detailed description of the vulnerability, and any available remediation information. + +[discrete] +[[vuln-findings-grouping]] +== Group and filter findings + +To help you prioritize remediation efforts, you can organize findings in various ways. + +[discrete] +[[vuln-management-findings-group-findings]] +=== Group findings + +Click **Group vulnerabilities by** to group your data by a field. Select one of the suggested fields or **Custom field** to choose your own. You can select up to three group fields at once. + +* When grouping is turned on, click a group to expand it and examine all sub-groups or findings within that group. +* To turn off grouping, click **Group vulnerabilities by:** and select **None**. + +[NOTE] +==== +Multiple groupings apply to your data in the order you selected them. For example, if you first select **Cloud account**, then select **Resource**, the top-level grouping will be based on **Cloud account**, and its subordinate grouping will be based on **Resource**, as demonstrated in the following screenshot. +==== + +[role="screenshot"] +image::images/vuln-management-findings/-cloud-native-security-cnvm-findings-grouped.png[The Vulnerabilities tab of the Findings page] + +[discrete] +[[vuln-management-findings-filter-findings]] +=== Filter findings + +You can filter the data in two ways: + +* **KQL search bar**: For example, search for `vulnerability.severity : "HIGH"` to view high severity vulnerabilities. +* **In-table value filters**: Hover over a finding to display available inline actions. Use the **Filter In** (plus) and **Filter Out** (minus) buttons. + +[discrete] +[[vuln-management-findings-customize-the-findings-table]] +=== Customize the Findings table + +When grouping is turned off, you can use the toolbar buttons in the upper-left of the Findings table to select which columns appear: + +* **Columns**: Select the left-to-right order in which columns appear. +* **Sort fields**: Sort the table by one or more columns, or turn sorting off. +* **Fields**: Select which fields to display for each finding. Selected fields appear in the table and the **Columns** menu. + +[TIP] +==== +You can also click a column's name to open a menu that allows you to perform multiple actions on the column. +==== + +[discrete] +[[vuln-management-findings-learn-more-about-a-vulnerability]] +== Learn more about a vulnerability + +Click a vulnerability to open the vulnerability details flyout. This flyout includes a link to the related vulnerability database, the vulnerability's publication date, CVSS vector strings, fix versions (if available), and more. + +When you open the vulnerability details flyout, it defaults to the **Overview** tab, which highlights key information. To view every field present in the vulnerability document, select the **Table** or **JSON** tabs. + +[discrete] +[[vuln-findings-remediate]] +== Remediate vulnerabilities + +To remediate a vulnerability and reduce your attack surface, update the affected package if a fix is available. + +[discrete] +[[cnvm-create-rule-from-finding]] +== Generate alerts for failed Findings + +You can create detection rules that detect specific vulnerabilities directly from the Findings page: + +. Click a vulnerability to open the vulnerability details flyout flyout. +. Click **Take action**, then **Create a detection rule**. This automatically creates a detection rule that creates alerts when the associated vulnerability is found. +. To review or customize the new rule, click **View rule**. diff --git a/docs/serverless/cloud-native-security/vuln-management-get-started.asciidoc b/docs/serverless/cloud-native-security/vuln-management-get-started.asciidoc new file mode 100644 index 0000000000..a594a99294 --- /dev/null +++ b/docs/serverless/cloud-native-security/vuln-management-get-started.asciidoc @@ -0,0 +1,77 @@ +[[vuln-management-get-started]] += Get started with CNVM + +:description: Set up cloud native vulnerability management. +:keywords: serverless, security, overview, cloud security + +preview:[] + +This page explains how to set up Cloud Native Vulnerability Management (CNVM). + +.Requirements +[NOTE] +==== +* CNVM only works in the `Default` {kib} space. Installing the CNVM integration on a different {kib} space will not work. +* Requires {agent} version 8.8 or higher. +* CNVM can only be deployed on ARM-based VMs. +* To view vulnerability scan findings, you need the appropriate user role to read the following indices: ++ +** `logs-cloud_security_posture.vulnerabilities-*` +** `logs-cloud_security_posture.vulnerabilities_latest-*` +* You need an AWS user account with permissions to perform the following actions: run CloudFormation templates, create IAM Roles and InstanceProfiles, and create EC2 SecurityGroups and Instances. +==== + +[NOTE] +==== +CNVM currently only supports AWS EC2 Linux workloads. +==== + +[discrete] +[[vuln-management-setup]] +== Set up CNVM for AWS + +To set up the CNVM integration for AWS, install the integration on a new {agent} policy, sign into the AWS account you want to scan, and run the https://docs.aws.amazon.com/cloudformation/index.html[CloudFormation] template. + +[IMPORTANT] +==== +Do not add the integration to an existing {agent} policy. It should always be added to a new policy since it should not run on VMs with existing workloads. For more information, refer to <>. +==== + +[discrete] +[[vuln-management-setup-step-1]] +=== Step 1: Add the CNVM integration + +. In the {security-app}, go to the **Get started** page, then click **Add security integrations**. +. Search for **Cloud Native Vulnerability Management**, then click on the result. +. Click **Add Cloud Native Vulnerability Management**. +. Give your integration a name that matches its purpose or the AWS account region you want to scan for vulnerabilities (for example, `uswest2-aws-account`.) ++ +[role="screenshot"] +image::images/vuln-management-get-started/-dashboards-cnvm-setup-1.png[The CNVM integration setup page] +. Click **Save and continue**. The integration will create a new {agent} policy. +. Click **Add {agent} to your hosts**. + +[discrete] +[[vuln-management-setup-step-2]] +=== Step 2: Sign in to the AWS management console + +. Open a new browser tab and use it to sign into your AWS management console. +. Switch to the cloud region with the workloads that you want to scan for vulnerabilities. + +[IMPORTANT] +==== +The integration will only scan VMs in the region you select. To scan multiple regions, repeat this setup process for each region. +==== + +[discrete] +[[vuln-management-setup-step-3]] +=== Step 3: Run the CloudFormation template + +. Switch back to the tab with Elastic Security. +. Click **Launch CloudFormation**. The CloudFormation page appears. ++ +[role="screenshot"] +image::images/vuln-management-get-started/-dashboards-cnvm-cloudformation.png[The cloud formation template] +. Click **Create stack**. To avoid authentication problems, you can only make configuration changes to the VM InstanceType, which you could make larger to increase scanning speed. +. Wait for the confirmation that {agent} was enrolled. +. Your data will start to appear on the **Vulnerabilities** tab of the <>. diff --git a/docs/serverless/cloud-native-security/vuln-management-overview.asciidoc b/docs/serverless/cloud-native-security/vuln-management-overview.asciidoc new file mode 100644 index 0000000000..947111ebc4 --- /dev/null +++ b/docs/serverless/cloud-native-security/vuln-management-overview.asciidoc @@ -0,0 +1,41 @@ +[[vuln-management-overview]] += Cloud native vulnerability management + +:description: Find and track vulnerabilities in your cloud. +:keywords: serverless, security, overview, cloud security + +preview:[] + +Elastic's Cloud Native Vulnerability Management (CNVM) feature helps you identify known vulnerabilities in your cloud workloads. + +Setup uses infrastructure as code. For instructions, refer to <>. + +[NOTE] +==== +CNVM currently only supports AWS EC2 Linux workloads. +==== + +.Requirements +[NOTE] +==== +* CNVM only works in the `Default` {kib} space. Installing the CNVM integration on a different {kib} space will not work. +* To view vulnerability scan findings, you need the appropriate user role to read the following indices: ++ +** `logs-cloud_security_posture.vulnerabilities-*` +** `logs-cloud_security_posture.vulnerabilities_latest-*` +==== + +[discrete] +[[vuln-management-overview-how-it-works]] +== How CNVM works + +During setup, you will use an infrastructure as code provisioning template to create a new virtual machine (VM) in the cloud region you wish to scan. This VM installs {agent} and the Cloud Native Vulnerability Management (CNVM) integration, and conducts all vulnerability scanning. + +The CNVM integration uses https://github.com/aquasecurity/trivy[Trivy], a comprehensive open-source security scanner, to scan cloud workloads and identify security vulnerabilities. During each scan, the VM running the integration takes a snapshot of all cloud workloads in its region using the snapshot APIs of the cloud service provider, and analyzes them for vulnerabilities using Trivy. Therefore, scanning does not use resources on the VMs being scanned. All resource usage occurs on the VM installed during CNVM setup. + +The scanning process begins immediately upon deployment, then repeats every twenty-four hours. After each scan, the integration sends the discovered vulnerabilities to {es}, where they appear in the **Vulnerabilities** tab of the <>. + +[NOTE] +==== +Environments with more VMs take longer to scan. +==== diff --git a/docs/serverless/dashboards/cloud-posture-dashboard-dash.asciidoc b/docs/serverless/dashboards/cloud-posture-dashboard-dash.asciidoc new file mode 100644 index 0000000000..c2fbc91f62 --- /dev/null +++ b/docs/serverless/dashboards/cloud-posture-dashboard-dash.asciidoc @@ -0,0 +1,53 @@ +[[cloud-posture-dashboard-dash]] += Cloud Security Posture dashboard + +:description: The Cloud Security Posture dashboard summarizes your cloud infrastructure's performance on CIS security benchmarks. +:keywords: serverless, security, overview, cloud security + +++++ +Cloud Security Posture +++++ + +preview:[] + +The Cloud Security Posture dashboard summarizes your cloud infrastructure's overall performance against <> defined by the Center for Internet Security (CIS). To start collecting this data, refer to <> or <>. + +[role="screenshot"] +image::images/cloud-posture-dashboard/-dashboards-cloud-sec-dashboard.png[The cloud Security dashboard] + +The Cloud Security Posture dashboard shows: + +* Configuration risk metrics for all monitored cloud accounts and Kubernetes clusters +* Configuration risk metrics grouped by the applicable benchmark, for example, CIS GCP, CIS Azure, CIS Kubernetes, or CIS EKS +* Configuration risks grouped by CIS section (security guideline category) + +[discrete] +[[cloud-posture-dashboard-UI]] +== Cloud Security Posture dashboard UI + +At the top of the dashboard, you can switch between the Cloud accounts and Kubernetes cluster views. + +The top section of either view summarizes your overall cloud security posture (CSP) by aggregating data from all monitored resources. The summary cards on the left show the number of cloud accounts or clusters evaluated, and the number of resources evaluated. You can click **Enroll more accounts** or **Enroll more clusters** to deploy to additional cloud assets. Click **View all resources** to open the <>. + +The remaining summary cards show your overall compliance score, and your compliance score for each CIS section. Click **View all failed findings** to view all failed findings, or click a CIS section name to view failed findings from only that section on the Findings page. + +Below the summary section, each row shows the CSP for a benchmark that applies to your monitored cloud resources. For example, if you are monitoring GCP and Azure cloud accounts, a row appears for CIS GCP and another appears for CIS Azure. Each row shows the CIS benchmark, the number of cloud accounts or Kubernetes clusters it applies to, its overall compliance score, and its compliance score grouped by CIS section. + +[role="screenshot"] +image::images/cloud-posture-dashboard/-dashboards-cloud-sec-dashboard-individual-row.png[A row representing a single cluster in the Cloud Security Posture dashboard] + +[discrete] +[[cloud-posture-dashboard-faq]] +== FAQ (Frequently Asked Questions) + +.When do newly-enrolled clusters appear on the dashboard? +[%collapsible] +===== +It can take up to 10 minutes for deployment, resource fetching, evaluation, and data processing before a newly-enrolled cluster appears on the dashboard. +===== + +.When do unenrolled clusters disappear from the dashboard? +[%collapsible] +===== +A cluster will disappear as soon as the KSPM integration fetches data while that cluster is not enrolled. The fetch process repeats every four hours, which means a newly unenrolled cluster can take a maximum of four hours to disappear from the dashboard. +===== diff --git a/docs/serverless/dashboards/dashboards-overview.asciidoc b/docs/serverless/dashboards/dashboards-overview.asciidoc new file mode 100644 index 0000000000..4568530413 --- /dev/null +++ b/docs/serverless/dashboards/dashboards-overview.asciidoc @@ -0,0 +1,22 @@ +[[dashboards-overview]] += Dashboards + +:description: Dashboards give you insight into your security environment. +:keywords: security, overview, visualize, monitor, analyze + +preview:[] + +The {security-app}'s default dashboards provide useful visualizations of your security environment. To view them in {elastic-sec}, select **Dashboards** from the navigation menu. From the Dashboards page, you can access the default dashboards, as well as create and access custom dashboards. + +To create a new custom dashboard, click **Create Dashboard**. You can control which custom dashboards appear in the table: + +* Use the text search field to filter by name or description. +* Use the **Tags** menu to filter by tag. +* Click a custom dashboard's tags to toggle filtering for each tag. + +To create a new tag or edit existing tags, open the **Tags** menu and click **Manage tags**. + +[role="screenshot"] +image::images/dashboards-overview/-dashboards-dashboards-landing-page.png[The dashboards landing page] + +Refer to documentation for the other {elastic-sec} dashboards to learn more about them. For more information about creating custom dashboards, refer to {kibana-ref}/create-a-dashboard-of-panels-with-web-server-data.html[Create your first dashboard]. diff --git a/docs/serverless/dashboards/data-quality-dash.asciidoc b/docs/serverless/dashboards/data-quality-dash.asciidoc new file mode 100644 index 0000000000..9cb4bba8d3 --- /dev/null +++ b/docs/serverless/dashboards/data-quality-dash.asciidoc @@ -0,0 +1,112 @@ +[[data-quality-dash]] += Data Quality dashboard + +:description: The Data Quality dashboard summarizes the health of your data ingest pipeline. +:keywords: serverless, security, how-to + +++++ +Data Quality +++++ + +preview:[] + +The Data Quality dashboard shows you whether your data is correctly mapped to the https://www.elastic.co/guide/en/ecs/current/ecs-reference.html[Elastic Common Schema] (ECS). Successful {ref}/mapping.html[mapping] enables you to search, visualize, and interact with your data throughout {elastic-sec}. + +[role="screenshot"] +image::images/data-quality-dash/-dashboards-data-qual-dash.png[The Data Quality dashboard] + +Use the Data Quality dashboard to: + +* Check one or multiple indices for unsuccessful mappings, to help you identify problems (the indices used by {elastic-sec} appear by default). +* View the number of documents stored in each of your indices. +* View detailed information about the fields in checked indices. +* Track unsuccessful mappings by creating a case or Markdown report based on data quality results. + +.Requirements +[NOTE] +==== +To use the Data Quality dashboard, you need the appropriate user role with the following privileges for each index you want to check: + +* `monitor` or `manage` +* `view_index_metadata` or `manage` (required for the {ref}/indices-get-mapping.html[Get mapping API]) +* `read` (required for the {ref}/search-search.html[Search API]) +==== + +[discrete] +[[data-quality-dash-check-indices]] +== Check indices + +When you open the dashboard, data does not appear until you select indices to check. + +* **Check multiple indices**: To check all indices in the current data view, click **Check all** at the top of the dashboard. A progress indicator will appear. + +[IMPORTANT] +==== +To customize which indices are checked when you click **Check all**, {security-guide}/data-views-in-sec.html[change the current data view]. +==== + +* **Check a single index**: To check a single index, click the **Check now** button under **Actions**. Checking a single index is faster than checking all indices. + +[discrete] +[[data-quality-dash-visualize-checked-indices]] +== Visualize checked indices + +The treemap that appears at the top of the dashboard shows the relative document count of your indices. The color of each index's node refers to its status: + +* **Blue:** Not yet checked. +* **Green:** Checked, no incompatible fields found. +* **Red:** Checked, one or more incompatible fields found. + +Click a node in the treemap to expand the corresponding index. + +[discrete] +[[data-quality-dash-learn-more-about-checked-index-fields]] +== Learn more about checked index fields + +After an index is checked, a `Pass` or `Fail` status appears. `Fail` indicates mapping problems in an index. To view index check details, including which fields weren't successfully mapped, click the **Check now** button under **Actions**. + +[role="screenshot"] +image::images/data-quality-dash/-dashboards-data-qual-dash-detail.png[An expanded index with some failed results in the Data Quality dashboard] + +The index check flyout provides more information about the status of fields in that index. Each of its tabs describe fields grouped by mapping status. + +[NOTE] +==== +Fields in the Same family category have the correct search behavior, but might have different storage or performance characteristics (for example, you can index strings to both text and keyword fields). To learn more, refer to {ref}/mapping-types.html[Field data types]. +==== + +[discrete] +[[data-quality-dash-view-historical-data-quality-results]] +== View historical data quality results + +You can review an index's data quality history by clicking **View history** under **Actions**, or by clicking the **History** tab in the details flyout. You can filter the results by time and **Pass** / **Fail** status. Click a historical check to expand it and view more details. + +[role="screenshot"] +image::images/data-quality-dash/history-tab.png[An index's data quality history tab] + +[NOTE] +==== +Recent historical data includes the **Incompatible fields** and **Same family** views. Legacy historical data only includes the **Incompatible fields** view. +==== + +[discrete] +[[data-quality-dash-export-data-quality-results]] +== Export data quality results + +You can share data quality results to help track your team's remediation efforts. First, follow the instructions under <> to generate results, then either: + +**Export results for all indices in the current data view**: + +. At the top of the dashboard, under the **Check all** button, are two buttons that allow you to share results. Exported results include all the data which appears in the dashboard. +. Click **Add to new case** to open a new <>. +. Click **Copy to clipboard** to copy a Markdown report to your clipboard. + +**Export results for one index**: + +. View details for a checked index by clicking the **Check now** button under **Actions**. +. From the **Incompatible fields** tab, select **Add to new case** to open a new <>, or click **Copy to clipboard** to copy a Markdown report to your clipboard. + +[NOTE] +==== +For more information about how to fix mapping problems, refer to {ref}/mapping.html[Mapping]. +==== diff --git a/docs/serverless/dashboards/detection-entity-dashboard.asciidoc b/docs/serverless/dashboards/detection-entity-dashboard.asciidoc new file mode 100644 index 0000000000..5ff50cdb88 --- /dev/null +++ b/docs/serverless/dashboards/detection-entity-dashboard.asciidoc @@ -0,0 +1,99 @@ +[[detection-entity-dashboard]] += Entity Analytics dashboard + +:description: The Entity Analytics dashboard provides a centralized view of emerging insider threats +:keywords: serverless, security, how-to + +++++ +Entity Analytics +++++ + +preview:[] + +The Entity Analytics dashboard provides a centralized view of emerging insider threats - including host risk, user risk, and anomalies from within your network. Use it to triage, investigate, and respond to these emerging threats. + +.Requirements +[NOTE] +==== +To display host and user risk scores, you must <>. +==== + +The dashboard includes the following sections: + +* <> +* <> +* <> +* <> + +[role="screenshot"] +image::images/detection-entity-dashboard/-dashboards-entity-dashboard.png[Entity dashboard] + +[discrete] +[[entity-kpis]] +== Entity KPIs (key performance indicators) + +Displays the total number of critical hosts, critical users, and anomalies. Select a link to jump to the Host risk table, User risk table, or Anomalies table. + +[discrete] +[[entity-host-risk-scores]] +== Host Risk Scores + +Displays host risk score data for your environment, including the total number of hosts, and the five most recently recorded host risk scores, with their associated host names, risk data, and number of detection alerts. Host risk scores are calculated using a weighted sum on a scale of 0 (lowest) to 100 (highest). + +[role="screenshot"] +image::images/detection-entity-dashboard/-dashboards-host-score-data.png[Host risk scores table] + +Interact with the table to filter data, view more details, and take action: + +* Select the **Host risk level** menu to filter the chart by the selected level. +* Click a host name link to open the host details flyout. +* Hover over a host name link to display inline actions: **Add to timeline**, which adds the selected value to Timeline, and **Copy to Clipboard**, which copies the host name value for you to paste later. +* Click **View all** in the upper-right to display all host risk information on the Hosts page. +* Click the number link in the **Alerts** column to view the alerts on the Alerts page. Hover over the number and select **Investigate in timeline** (image:images/icons/timeline.svg[Timeline]) to launch Timeline with a query that includes the associated host name value. + +For more information about host risk scores, refer to <>. + +[discrete] +[[entity-user-risk-scores]] +== User Risk Scores + +Displays user risk score data for your environment, including the total number of users, and the five most recently recorded user risk scores, with their associated user names, risk data, and number of detection alerts. Like host risk scores, user risk scores are calculated using a weighted sum on a scale of 0 (lowest) to 100 (highest). + +[role="screenshot"] +image::images/detection-entity-dashboard/-dashboards-user-score-data.png[User risk table] + +Interact with the table to filter data, view more details, and take action: + +* Select the **User risk level** menu to filter the chart by the selected level. +* Click a user name link to open the user details flyout. +* Hover over a user name link to display inline actions: **Add to timeline**, which adds the selected value to Timeline, and **Copy to Clipboard**, which copies the user name value for you to paste later. +* Click **View all** in the upper-right to display all user risk information on the Users page. +* Click the number link in the **Alerts** column to view the alerts on the Alerts page. Hover over the number and select **Investigate in timeline** (image:images/icons/timeline.svg[Timeline]) to launch Timeline with a query that includes the associated user name value. + +For more information about user risk scores, refer to <>. + +[discrete] +[[entity-anomalies]] +== Anomalies + +Anomaly detection jobs identify suspicious or irregular behavior patterns. The Anomalies table displays the total number of anomalies identified by these prebuilt {ml} jobs (named in the **Anomaly name** column). + +.Requirements +[NOTE] +==== +To display anomaly results, you must {ml-docs}/ml-ad-run-jobs.html[install and run] one or more {security-guide}/prebuilt-ml-jobs.html[prebuilt anomaly detection jobs]. You cannot add custom anomaly detection jobs to the Entity Analytics dashboard. +==== + +[role="screenshot"] +image::images/detection-entity-dashboard/-dashboards-anomalies-table.png[Anomalies table] + +Interact with the table to view more details: + +* Click **View all host anomalies** to go to the Anomalies table on the Hosts page. +* Click **View all user anomalies** to go to the Anomalies table on the Users page. +* Click **View all** to display and manage all machine learning jobs on the Anomaly Detection Jobs page. + +[TIP] +==== +To learn more about {ml}, refer to {ml-docs}/machine-learning-intro.html[What is Elastic machine learning?] +==== diff --git a/docs/serverless/dashboards/detection-response-dashboard.asciidoc b/docs/serverless/dashboards/detection-response-dashboard.asciidoc new file mode 100644 index 0000000000..89e2bde2e5 --- /dev/null +++ b/docs/serverless/dashboards/detection-response-dashboard.asciidoc @@ -0,0 +1,48 @@ +[[detection-response-dashboard]] += Detection & Response dashboard + +:description: The Detection & Response dashboard provides focused visibility into the day-to-day operations of your security environment +:keywords: serverless, security, how-to + +++++ +Detection & Response +++++ + +preview:[] + +The Detection & Response dashboard provides focused visibility into the day-to-day operations of your security environment. It helps security operations managers and analysts quickly monitor recent and high priority detection alerts and cases, and identify the hosts and users associated with alerts. + +[role="screenshot"] +image::images/detection-response-dashboard/-detections-detection-response-dashboard.png[Overview of Detection & Response dashboard] + +Interact with various dashboard elements: + +* Use the date and time picker in the upper-right to specify a time range for displaying information on the dashboard. +* In sections that list alert counts, click a number to view the alerts on the Alerts page. Hover over the number and select **Investigate in timeline** (image:images/icons/timeline.svg[Timeline]) to open the alerts in Timeline. +* Click the name of a detection rule, case, host, or user to open its details page. + +The following sections are included: + +// [width="100%",cols="s,"] + +|=== +| | + +| Alerts +| The total number of detection alerts generated within the time range, organized by status and severity. Select **View alerts** to open the Alerts page. + +| Cases +| The total number of cases created within the time range, organized by status. Select **View cases** to open the Cases page. + +| Open alerts by rule +| The top four detection rules with open alerts, organized by the severity and number of alerts for each rule. Select **View all open alerts** to open the Alerts page. + +| Recently created cases +| The four most recently created cases. Select **View recent cases** to open the Cases page. + +| Hosts by alert severity +| The hosts generating detection alerts within the time range, organized by the severity and number of alerts. Shows up to 100 hosts. + +| Users by alert severity +| The users generating detection alerts within the time range, organized by the severity and number of alerts. Shows up to 100 users. +|=== diff --git a/docs/serverless/dashboards/kubernetes-dashboard-dash.asciidoc b/docs/serverless/dashboards/kubernetes-dashboard-dash.asciidoc new file mode 100644 index 0000000000..a45a578b8e --- /dev/null +++ b/docs/serverless/dashboards/kubernetes-dashboard-dash.asciidoc @@ -0,0 +1,103 @@ +[[kubernetes-dashboard-dash]] += Kubernetes dashboard + +:description: The Kubernetes dashboard provides insight into Linux process data from your Kubernetes clusters. +:keywords: serverless, security, overview, cloud security + +++++ +Kubernetes +++++ + +preview:[] + +The Kubernetes dashboard provides insight into Linux process data from your Kubernetes clusters. It shows sessions in detail and in the context of your monitored infrastructure. + +[role="screenshot"] +image::images/kubernetes-dashboard/-dashboards-kubernetes-dashboard.png[The Kubernetes dashboard, with numbered labels 1 through 3 for major sections] +The numbered sections are described below: + +. The charts at the top of the dashboard provide an overview of your monitored Kubernetes infrastructure. You can hide them by clicking **Hide charts**. +. The tree navigation menu allows you to navigate through your deployments and select the scope of the sessions table to the right. You can select any item in the menu to show its sessions. In Logical view, the menu is organized by Cluster, Namespace, Pod, and Container image. In Infrastructure view, it is organized by Cluster, Node, Pod, and Container image. +. The sessions table displays sessions collected from the selected element of your Kubernetes infrastructure. You can view it in fullscreen by selecting the button in the table's upper right corner. You can sort the table by any of its fields. + +You can filter the data using the KQL search bar and date picker at the top of the page. + +From the sessions table's Actions column, you can take the following investigative actions: + +* View details +* <> +* <> +* <> +* <> + +Session View displays Kubernetes metadata under the **Metadata** tab of the Detail panel: + +[role="screenshot"] +image::images/kubernetes-dashboard/-dashboards-metadata-tab.png[The Detail panel's metadata tab] + +The **Metadata** tab is organized into these expandable sections: + +* **Metadata:** `hostname`, `id`, `ip`, `mac`, `name`, Host OS information +* **Cloud:** `instance.name`, `provider`, `region`, `account.id`, `project.id` +* **Container:** `id`, `name`, `image.name`, `image.tag`, `image.hash.all` +* **Orchestrator:** `resource.ip`, `resource.name`, `resource.type`, `namespace`, `cluster.id`, `cluster.name`, `parent.type` + +[discrete] +[[k8s-dash-setup]] +== Setup + +To get data for this dashboard, set up <> for the clusters you want to display on the dashboard. + +.Requirements +[NOTE] +==== +* Kubernetes node operating systems must have Linux kernels 5.10.16 or higher. +==== + +**Support matrix**: +This feature is currently available on GKE and EKS using Linux hosts and Kubernetes versions that match the following specifications: + +|=== +| | | + +| +| EKS 1.24-1.26 (AL2022) +| GKE 1.24-1.26 (COS) + +| Process event exports +| ✓ +| ✓ + +| Network event exports +| ✗ +| ✗ + +| File event exports +| ✓ +| ✓ + +| File blocking +| ✓ +| ✓ + +| Process blocking +| ✓ +| ✓ + +| Network blocking +| ✗ +| ✗ + +| Drift prevention +| ✓ +| ✓ + +| Mount point awareness +| ✓ +| ✓ +|=== + +[IMPORTANT] +==== +This dashboard uses data from the `logs-*` index pattern, which is included by default in the <>. To collect data from multiple {es} clusters (as in a cross-cluster deployment), update `logs-*` to `*:logs-*`. +==== diff --git a/docs/serverless/dashboards/overview-dashboard.asciidoc b/docs/serverless/dashboards/overview-dashboard.asciidoc new file mode 100644 index 0000000000..418843b6e5 --- /dev/null +++ b/docs/serverless/dashboards/overview-dashboard.asciidoc @@ -0,0 +1,63 @@ +[[overview-dashboard]] += Overview dashboard + +:description: The Overview dashboard provides a high-level snapshot of alerts and events. +:keywords: serverless, security, how-to + +++++ +Overview +++++ + +preview:[] + +The Overview dashboard provides a high-level snapshot of alerts and events. It helps you assess overall system health and find anomalies that may require further investigation. + +[role="screenshot"] +image::images/overview-dashboard/-dashboards-overview-pg.png[Overview dashboard] + +[discrete] +[[overview-dashboard-live-feed]] +== Live feed + +The live feed on the Overview dashboard helps you quickly access recently created cases, favorited Timelines, and the latest {elastic-sec} news. + +[TIP] +==== +The **Security news** section provides the latest {elastic-sec} news to help you stay informed of new developments, learn about {elastic-sec} features, and more. +==== + +[role="screenshot"] +image::images/overview-dashboard/-dashboards-live-feed-ov-page.png[Overview dashboard with live feed section highlighted] + +[discrete] +[[overview-dashboard-histograms]] +== Histograms + +Time-based histograms show the number of detections, alerts, and events that have occurred within the selected time range. To focus on a particular time, click and drag to select a time range, or choose a preset value. The **Stack by** menu lets you select which field is used to organize the data. For example, in the Alert trend histogram, stack by `kibana.alert.rule.name` to display alert counts by rule name within the specified time frame. + +Hover over histograms, graphs, and tables to display an **Inspect** button (image:images/icons/inspect.svg[Inspect]) or options menu (image:images/icons/boxesHorizontal.svg[More actions]). Click to inspect the visualization's {es} queries, add it to a new or existing case, or open it in Lens for customization. + +[discrete] +[[overview-dashboard-host-and-network-events]] +== Host and network events + +View event and host counts grouped by data source, such as **Auditbeat** or **{elastic-defend}**. Expand a category to view specific counts of host or network events from the selected source. + +[role="screenshot"] +image::images/overview-dashboard/-getting-started-events-count.png[Host and network events on the Overview dashboard] + +[discrete] +[[overview-dashboard-threat-intelligence]] +== Threat Intelligence + +The Threat Intelligence view on the Overview dashboard provides streamlined threat intelligence data for threat detection and matching. + +The view shows the total number of ingested threat indicators, enabled threat intelligence sources, and ingested threat indicators per source. To learn more about the ingested indicator data, click **View indicators**. + +[NOTE] +==== +For more information about connecting to threat intelligence sources, visit <>. +==== + +[role="screenshot"] +image::images/overview-dashboard/-getting-started-threat-intelligence-view.png[Threat Intelligence view on the Overview dashboard] diff --git a/docs/serverless/dashboards/rule-monitoring-dashboard.asciidoc b/docs/serverless/dashboards/rule-monitoring-dashboard.asciidoc new file mode 100644 index 0000000000..33e0bce483 --- /dev/null +++ b/docs/serverless/dashboards/rule-monitoring-dashboard.asciidoc @@ -0,0 +1,65 @@ +[[rule-monitoring-dashboard]] += Detection rule monitoring dashboard + +:description: Visualize your detection rules' performance. +:keywords: security, how-to, visualize, monitor + +++++ +Detection rule monitoring +++++ + +preview:[] + +The Detection rule monitoring dashboard provides visualizations to help you monitor the overall health and performance of {elastic-sec}'s detection rules. Consult this dashboard for a high-level view of whether your rules are running successfully and how long they're taking to run, search data, and create alerts. + +[role="screenshot"] +image::images/rule-monitoring-dashboard/-dashboards-rule-monitoring-overview.png[Overview of Detection rule monitoring dashboard] + +.Requirements +[NOTE] +==== +To access this dashboard and its data, you must have the appropriate user role. +==== + +[discrete] +[[rule-monitoring-visualizations]] +== Visualization data and types + +The dashboard presents a variety of information about your detection rules. Visualizations display and calculate data within the time range and filters selected at the top of the dashboard. + +The following visualizations are included: + +* **Rule KPIs (key performance indicators)**: The total number of rules enabled, how many times they collectively ran, and their response statuses. +* **Executions by rule type**: Rule executions over time, broken down by rule type. +* **Executions by status**: Rule executions over time, broken down by status. +* **Total rule execution duration**: How long rules take to run, from start to finish. +* **Rule schedule delay**: The delay between a rule's scheduled start time and when it actually starts running. +* **Search/query duration**: How long rules take to query source indices or data views. +* **Indexing duration**: How long rules take to generate alerts and write them to the `.alerts-security.alerts-*` index. +* **Top 10 rules**: Lists of the overall slowest rules, most delayed rules, and rules with the most **Failed** and **Warning** response statuses. + +[discrete] +[[rule-visualization-actions]] +== Visualization panel actions + +Open a panel's options menu (image:images/icons/boxesHorizontal.svg[More actions]) customize the panel or use its data for further analysis and investigation: + +* **Edit panel settings**: Customize the panel's display settings. Options vary by visualization type. +* **Inspect**: Examine the panel's underlying data and queries. +* **Explore data in Discover**: Open Discover with preloaded filters to display the panel's data. +* **Maximize panel**: Expand the panel. +* **Download as CSV**: Download the panel's data in a CSV file. +* **Copy to dashboard**: Copy the panel to an existing or new dashboard. +* **Add to existing case**: Add the panel to an existing case. +* **Add to new case**: Create a new case and add the panel to it. +* **Create anomaly detection job**: Create a {ml} anomaly detection job using the panel's data. + +[discrete] +[[clone-edit-dashboard]] +== Clone and edit the dashboard + +To make persistent changes to the dashboard, you can clone the dashboard and edit the cloned copy, but your copy will not get updates from Elastic. + +. Click **Edit**, then **Save as**. +. On the **Save dashboard** dialog, enter a new **Title** for your cloned copy. +. Make sure **Save as new dashboard** is selected, then click **Save**. You can now make additional changes and save them to your copy. diff --git a/docs/serverless/dashboards/vuln-management-dashboard-dash.asciidoc b/docs/serverless/dashboards/vuln-management-dashboard-dash.asciidoc new file mode 100644 index 0000000000..232c8b5d6f --- /dev/null +++ b/docs/serverless/dashboards/vuln-management-dashboard-dash.asciidoc @@ -0,0 +1,45 @@ +[[vuln-management-dashboard-dash]] += Cloud Native Vulnerability Management Dashboard + +:description: The CNVM dashboard gives an overview of vulnerabilities detected in your cloud infrastructure. +:keywords: security, cloud, reference, manage + +++++ +Cloud Native Vulnerability Management +++++ + +preview:[] + +The Cloud Native Vulnerability Management (CNVM) dashboard gives you an overview of vulnerabilities detected in your cloud infrastructure. + +[role="screenshot"] +image::images/vuln-management-dashboard-dash/-cloud-native-security-vuln-management-dashboard.png[The CNVM dashboard] + +.Requirements +[NOTE] +==== +* To collect this data, install the <> integration. +==== + +[discrete] +[[CNVM-dashboard-UI-dash]] +== CNVM dashboard UI + +The summary cards at the top of the dashboard display the number of monitored cloud accounts, scanned virtual machines (VMs), and vulnerabilities (grouped by severity). + +The **Trend by severity** bar graph complements the summary cards by displaying the number of vulnerabilities found on your infrastructure over time, sorted by severity. It has a maximum time scale of 30 days. + +.Graph tips +[NOTE] +==== +* Click the severity levels legend on its right to hide/show each severity level. +* To display data from specific cloud accounts, select the account names from the **Accounts** drop-down menu. +==== + +The page also includes three tables: + +* **Top 10 vulnerable resources** shows your VMs with the highest number of vulnerabilities. +* **Top 10 patchable vulnerabilities** shows the most common vulnerabilities in your environment that can be fixed by a software update. +* **Top 10 vulnerabilities** shows the most common vulnerabilities in your environment, with additional details. + +Click **View all vulnerabilities** at the bottom of a table to open the <> page, where you can view additional details. diff --git a/docs/serverless/edr-install-config/agent-tamper-protection.asciidoc b/docs/serverless/edr-install-config/agent-tamper-protection.asciidoc new file mode 100644 index 0000000000..7cfe9020d7 --- /dev/null +++ b/docs/serverless/edr-install-config/agent-tamper-protection.asciidoc @@ -0,0 +1,53 @@ +[[agent-tamper-protection]] += Prevent {agent} uninstallation + +:description: Block unauthorized attempts to uninstall {agent} on hosts. +:keywords: serverless, security, how-to + +preview:[] + +For hosts enrolled in {elastic-defend}, you can prevent unauthorized attempts to uninstall {agent} and {elastic-endpoint} by enabling **Agent tamper protection** on the Agent policy. This offers an additional layer of security by preventing users from bypassing or disabling {elastic-defend}'s endpoint protections. + +When enabled, {agent} and {elastic-endpoint} can only be uninstalled on the host by including an uninstall token in the uninstall CLI command. One unique uninstall token is generated per Agent policy, and you can retrieve uninstall tokens in an Agent policy's settings or in the {fleet} UI. + +.Requirements +[NOTE] +==== +* Agent tamper protection requires the Endpoint Protection Complete https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature]. +* Hosts must be enrolled in the {elastic-defend} integration. +* {agent}s must be version 8.11.0 or later. +* This feature is supported for all operating systems. +==== + +[role="screenshot"] +image::images/agent-tamper-protection/agent-tamper-protection.png[Agent tamper protection setting highlighted on Agent policy settings page] + +[discrete] +[[enable-agent-tamper-protection]] +== Enable Agent tamper protection + +You can enable Agent tamper protection by configuring the {agent} policy. + +. Go to **{fleet}** -> **Agent policies**, then select the Agent policy you want to configure. +. Select the **Settings** tab on the policy details page. +. In the **Agent tamper protection** section, turn on the **Prevent agent tampering** setting. ++ +This makes the **Get uninstall command** link available, which you can follow to get the uninstall token and CLI command if you need to <> on this policy. ++ +[TIP] +==== +You can also access an Agent policy's uninstall tokens on the **Uninstall tokens** tab on the **{fleet}** page. Refer to <> for more information. +==== +. Select **Save changes**. + +[discrete] +[[fleet-uninstall-tokens]] +== Access uninstall tokens + +If you need the uninstall token to remove {agent} from an endpoint, you can find it in several ways: + +* **On the Agent policy** — Go to the Agent policy's **Settings** tab, then click the **Get uninstall command** link. The **Uninstall agent** flyout opens, containing the full uninstall command with the token. +* **On the {fleet} page** — Go to **{fleet}** -> **Uninstall tokens** for a list of the uninstall tokens generated for your Agent policies. You can: ++ +** Click the **Show token** icon in the **Token** column to reveal a specific token. +** Click the **View uninstall command** icon in the **Actions** column to open the **Uninstall agent** flyout, containing the full uninstall command with the token. diff --git a/docs/serverless/edr-install-config/artifact-control.asciidoc b/docs/serverless/edr-install-config/artifact-control.asciidoc new file mode 100644 index 0000000000..b8512152be --- /dev/null +++ b/docs/serverless/edr-install-config/artifact-control.asciidoc @@ -0,0 +1,30 @@ +[[protection-artifact-control]] += Configure updates for protection artifacts + +:description: Configure updates for protection artifacts. +:keywords: serverless, security, how-to, secure, manage + +++++ +Configure protection updates +++++ + +preview:[] + +On the **Protection updates** tab of the {elastic-defend} integration policy, you can configure how {elastic-defend} receives updates from Elastic with the latest threat detections, global exceptions, malware models, rule packages, and other protection artifacts. By default, these artifacts are automatically updated regularly, ensuring your environment is up to date with the latest protections. + +You can disable automatic updates and freeze your protection artifacts to a specific date, allowing you to control when to receive and install the updates. For example, you might want to temporarily disable updates to ensure resource availability during a high-volume period, test updates in a controlled staging environment before rolling out to production, or roll back to a previous version of protections. + +Protection artifacts will expire after 18 months, and you'll no longer be able to select them as a deployed version. If you're already using a specific version when it expires, you'll keep using it until you either select a later non-expired version or re-enable automatic updates. + +[CAUTION] +==== +It is strongly advised to keep automatic updates enabled to ensure the highest level of security for your environment. Proceed with caution if you decide to disable automatic updates. +==== + +To configure the protection artifacts version deployed in your environment: + +. Go to **Manage** → **Policies**, select an {elastic-defend} integration policy, then select the **Protection updates** tab. +. Turn off the **Enable automatic updates** toggle. +. Use the **Version to deploy** date picker to select the date of the protection artifacts you want to use in your environment. +. (Optional) Enter a **Note** to explain the reason for selecting a particular version of protection artifacts. +. Select **Save**. diff --git a/docs/serverless/edr-install-config/configure-endpoint-integration-policy.asciidoc b/docs/serverless/edr-install-config/configure-endpoint-integration-policy.asciidoc new file mode 100644 index 0000000000..a4086ff071 --- /dev/null +++ b/docs/serverless/edr-install-config/configure-endpoint-integration-policy.asciidoc @@ -0,0 +1,286 @@ +[[configure-endpoint-integration-policy]] += Configure an integration policy for {elastic-defend} + +:description: Configure settings on an {elastic-defend} integration policy. +:keywords: serverless, security, how-to + +preview:[] + +After the {agent} is installed with the {elastic-defend} integration, several protections features — including +preventions against malware, ransomware, memory threats, and malicious behavior — are automatically enabled +on protected hosts (most features require the Endpoint Protection Essentials or Endpoint Protection Complete https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature]). If needed, you can update the +integration policy to configure protection settings, event collection, antivirus settings, trusted applications, +event filters, host isolation exceptions, and blocked applications to meet your organization's security needs. + +You can also create multiple {elastic-defend} integration policies to maintain unique configuration profiles. To create an additional {elastic-defend} integration policy, go to **Project settings** → **Integrations**, then follow the steps for <>. + +.Requirements +[NOTE] +==== +You must have the appropriate user role to configure an integration policy. +==== + +//// +/* Commented out because APIs are not exposed in initial serverless release. We can uncommment this and add a link to API docs once APIs are available. + +In addition to configuring an {elastic-defend} policy through the {elastic-sec} UI, you can create and customize an {elastic-defend} policy through the API. + +*/ +//// + +To configure an integration policy: + +. Go to **Assets** → **Endpoints** → **Policies** to view the **Policies** page. +. Select the integration policy you want to configure. The integration policy configuration page appears. +. On the **Policy settings** tab, review and configure the following settings as appropriate: ++ +** <> +** <> +** <> +** <> +** <> +** <> +** <> +** <> +** <> +. Click the **Trusted applications**, **Event filters**, **Host isolation exceptions**, and **Blocklist** tabs to review the endpoint policy artifacts assigned to this integration policy (for more information, refer to <>, <>, <>, and <>). On these tabs, you can: ++ +** Expand and view an artifact — Click the arrow next to its name. +** View an artifact's details — Click the actions menu (image:images/icons/boxesHorizontal.svg[Actions menu]), then select **View full details**. +** Unassign an artifact — Click the actions menu (image:images/icons/boxesHorizontal.svg[Actions menu]), +then select **Remove from policy**. This does not delete the artifact; this just unassigns it from the current policy. +** Assign an existing artifact — Click **Assign _x_ to policy**, +then select an item from the flyout. This view lists any existing artifacts that aren't already assigned to the current policy. ++ +[NOTE] +==== +You can't create a new endpoint policy artifact while configuring an integration policy. +To create a new artifact, go to its main page in the {security-app} (for example, +to create a new trusted application, go to **Assets** → **Endpoints** → **Trusted applications**). +==== +. Click the **Protection updates** tab to configure how {elastic-defend} receives updates from Elastic with the latest threat detections, malware models, and other protection artifacts. Refer to <> for more information. + +[discrete] +[[malware-protection]] +== Malware protection + +{elastic-defend} malware prevention detects and stops malicious attacks by using a <> +that looks for static attributes to determine if a file is malicious or benign. + +By default, malware protection is enabled on Windows, macOS, and Linux hosts. +To disable malware protection, turn off the **Malware protections** toggle. + +.Requirements +[NOTE] +==== +Malware protection requires the Endpoint Protection Essentials https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature]. +==== + +Malware protection levels are: + +* **Detect**: Detects malware on the host and generates an alert. The agent will **not** block malware. +You must pay attention to and analyze any malware alerts that are generated. +* **Prevent** (Default): Detects malware on the host, blocks it from executing, and generates an alert. + +These additional options are available for malware protection: + +* **Blocklist**: Enable or disable the <> for all hosts associated with this {elastic-defend} policy. The blocklist allows you to prevent specified applications from running on hosts, extending the list of processes that {elastic-defend} considers malicious. +* **Scan files upon modification**: By default, {elastic-defend} scans files every time they're modified, which can be resource-intensive on hosts where files are frequently modified, such as servers and developer machines. Turn off this option to only scan files when they're executed. {elastic-defend} will continue to identify malware as it attempts to run, providing a robust level of protection while improving endpoint performance. + +Select **Notify user** to send a push notification in the host operating system when activity is detected or prevented. Notifications are enabled by default for the **Prevent** option. + +[TIP] +==== +Endpoint Protection Complete customers can customize these notifications using the `Elastic Security {action} {filename}` syntax. +==== + +[role="screenshot"] +image::images/configure-endpoint-integration-policy/-getting-started-install-endpoint-malware-protection.png[Detail of malware protection section.] + +[discrete] +[[manage-quarantined-files]] +=== Manage quarantined files + +When **Prevent** is enabled for malware protection, {elastic-defend} will quarantine any malicious file it finds (this includes files defined in the <>). Specifically {elastic-defend} will remove the file from its current location, encrypt it with the encryption key `ELASTIC`, move it to a different folder, and rename it as a GUID string, such as `318e70c2-af9b-4c3a-939d-11410b9a112c`. + +The quarantine folder location varies by operating system: + +* macOS: `/System/Volumes/Data/.equarantine` +* Linux: `.equarantine` at the root of the mount point of the file being quarantined +* Windows - {elastic-defend} versions 8.5 and later: `[DriveLetter:].quarantine`, unless the files are from the `C:` drive. These files are moved to `C:\Program Files\Elastic\Endpoint\state.equarantine`. +* Windows - {elastic-defend} versions 8.4 and earlier: `[DriveLetter:].quarantine`, for any drive + +To restore a quarantined file to its original state and location, <> to the rule that identified the file as malicious. If the exception would've stopped the rule from identifying the file as malicious, {elastic-defend} restores the file. + +You can access a quarantined file by using the `get-file` <> in the response console. To do this, copy the path from the alert's **Quarantined file path** field (`file.Ext.quarantine_path`), which appears under **Highlighted fields** in the alert details flyout. Then paste the value into the `--path` parameter. This action doesn't restore the file to its original location, so you will need to do this manually. + +[NOTE] +==== +Response actions and the response console UI are Endpoint Protection Complete https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project features]. +==== + +[discrete] +[[ransomware-protection]] +== Ransomware protection + +Behavioral ransomware prevention detects and stops ransomware attacks on Windows systems by +analyzing data from low-level system processes. It is effective across an array of widespread +ransomware families — including those targeting the system’s master boot record. + +.Requirements +[NOTE] +==== +Ransomware protection requires the Endpoint Protection Essentials https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature]. +==== + +Ransomware protection levels are: + +* **Detect**: Detects ransomware on the host and generates an alert. {elastic-defend} +will **not** block ransomware. You must pay attention to and analyze any ransomware alerts that are generated. +* **Prevent** (Default): Detects ransomware on the host, blocks it from executing, +and generates an alert. + +When ransomware protection is enabled, canary files placed in targeted locations on your hosts provide an early warning system for potential ransomware activity. When a canary file is modified, Elastic Defend immediately generates a ransomware alert. If **prevent** ransomware is active, {elastic-defend} terminates the process that modified the file. + +Select **Notify user** to send a push notification in the host operating system when activity is detected or prevented. Notifications are enabled by default for the **Prevent** option. + +[TIP] +==== +Endpoint Protection Complete customers can customize these notifications using the `Elastic Security {action} {filename}` syntax. +==== + +[role="screenshot"] +image::images/configure-endpoint-integration-policy/-getting-started-install-endpoint-ransomware-protection.png[Detail of ransomware protection section.] + +[discrete] +[[memory-protection]] +== Memory threat protection + +Memory threat protection detects and stops in-memory threats, such as shellcode injection, +which are used to evade traditional file-based detection techniques. + +.Requirements +[NOTE] +==== +Memory threat protection requires the Endpoint Protection Essentials https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature]. +==== + +Memory threat protection levels are: + +* **Detect**: Detects memory threat activity on the host and generates an alert. +{elastic-defend} will **not** block the in-memory activity. You must pay attention to and analyze any alerts that are generated. +* **Prevent** (Default): Detects memory threat activity on the host, forces the process +or thread to stop, and generates an alert. + +Select **Notify user** to send a push notification in the host operating system when activity is detected or prevented. Notifications are enabled by default for the **Prevent** option. + +[TIP] +==== +Endpoint Protection Complete customers can customize these notifications using the `Elastic Security {action} {rule}` syntax. +==== + +[role="screenshot"] +image::images/configure-endpoint-integration-policy/-getting-started-install-endpoint-memory-protection.png[Detail of memory protection section.] + +[discrete] +[[behavior-protection]] +== Malicious behavior protection + +Malicious behavior protection detects and stops threats by monitoring the behavior +of system processes for suspicious activity. Behavioral signals are much more difficult +for adversaries to evade than traditional file-based detection techniques. + +.Requirements +[NOTE] +==== +Malicious behavior protection requires the Endpoint Protection Essentials https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature]. +==== + +Malicious behavior protection levels are: + +* **Detect**: Detects malicious behavior on the host and generates an alert. +{elastic-defend} will **not** block the malicious behavior. You must pay attention to and analyze any alerts that are generated. +* **Prevent** (Default): Detects malicious behavior on the host, forces the process to stop, +and generates an alert. + +Select whether you want to use **Reputation service** for additional protection. Elastic's reputation service leverages our extensive threat intelligence knowledge to make high confidence real-time prevention decisions. For example, reputation service can detect suspicious downloads of binaries with low or malicious reputation. Endpoints communicate with the reputation service directly at https://cloud.security.elastic.co[https://cloud.security.elastic.co]. + +Select **Notify user** to send a push notification in the host operating system when activity is detected or prevented. Notifications are enabled by default for the **Prevent** option. + +[TIP] +==== +Endpoint Protection Complete customers can customize these notifications using the `Elastic Security {action} {rule}` syntax. +==== + +[role="screenshot"] +image::images/configure-endpoint-integration-policy/-getting-started-install-endpoint-behavior-protection.png[Detail of behavior protection section.] + +[discrete] +[[attack-surface-reduction]] +== Attack surface reduction + +This section helps you reduce vulnerabilities that attackers can target on Windows endpoints. + +.Requirements +[NOTE] +==== +Attack surface reduction requires the Endpoint Protection Essentials https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature]. +==== + +* **Credential hardening**: Prevents attackers from stealing credentials stored in Windows system process memory. Turn on the toggle to remove any overly permissive access rights that aren't required for standard interaction with the Local Security Authority Subsystem Service (LSASS). This feature enforces the principle of least privilege without interfering with benign system activity that is related to LSASS. + +[role="screenshot"] +image::images/configure-endpoint-integration-policy/-getting-started-install-endpoint-attack-surface-reduction.png[Detail of attack surface reduction section.] + +[discrete] +[[event-collection]] +== Event collection + +In the **Settings** section, select which categories of events to collect on each operating system. +Most categories are collected by default, as seen below. + +[role="screenshot"] +image::images/configure-endpoint-integration-policy/-getting-started-install-endpoint-event-collection.png[Detail of event collection section.] + +[discrete] +[[register-as-antivirus]] +== Register {elastic-sec} as antivirus (optional) + +With {elastic-defend} version 7.10 or later on Windows 7 or later, you can +register {elastic-sec} as your hosts' antivirus software by enabling **Register as antivirus**. + +[NOTE] +==== +Windows Server is not supported. Antivirus registration requires Windows Security Center, which is not included in Windows Server operating systems. +==== + +By default, the **Sync with malware protection level** is selected to automatically set antivirus registration to match how you've configured {elastic-defend}'s <>. If malware protection is turned on _and_ set to **Prevent**, antivirus registration will also be enabled; in any other case, antivirus registration will be disabled. + +If you don't want to sync antivirus registration, you can set it manually with **Enabled** or **Disabled**. + +[role="screenshot"] +image::images/configure-endpoint-integration-policy/-getting-started-register-as-antivirus.png[Detail of Register as antivirus option.] + +[discrete] +[[adv-policy-settings]] +== Advanced policy settings (optional) + +Users with unique configuration and security requirements can select **Show advanced settings** +to configure the policy to support advanced use cases. Hover over each setting to view its description. + +[NOTE] +==== +Advanced settings are not recommended for most users. +==== + +This section includes: + +* <> +* <> +* <> + +[discrete] +[[save-policy]] +== Save the general policy settings + +After you have configured the general settings on the **Policy settings** tab, click **Save**. A confirmation message appears. diff --git a/docs/serverless/edr-install-config/defend-feature-privs.asciidoc b/docs/serverless/edr-install-config/defend-feature-privs.asciidoc new file mode 100644 index 0000000000..f5b45bb790 --- /dev/null +++ b/docs/serverless/edr-install-config/defend-feature-privs.asciidoc @@ -0,0 +1,67 @@ +[[endpoint-management-req]] += {elastic-defend} feature privileges + +:description: Manage user roles and privileges to grant access to {elastic-defend} features. +:keywords: security, defend, reference, manage + +preview:[] + +You can create user roles and define privileges to manage feature access in {elastic-sec}. This allows you to use the principle of least privilege while managing access to {elastic-defend}'s features. + +Configure roles and privileges in **Stack Management** → **Custom Roles**. For more details on using this UI, refer to https://www.elastic.co/docs/current/serverless/custom-roles[]. + +[NOTE] +==== +{elastic-defend}'s feature privileges must be assigned to **All Spaces**. You can't assign them to an individual space. +==== + +To grant access, select **All** for the **Security** feature in the **{kib} privileges** configuration UI, then turn on the **Customize sub-feature privileges** switch. For each of the following sub-feature privileges, select the type of access you want to allow: + +* **All**: Users have full access to the feature, which includes performing all available actions and managing configuration. +* **Read**: Users can view the feature, but can't perform any actions or manage configuration (some features don't have this privilege). +* **None**: Users can't access or view the feature. + +|=== +| | + +| **Endpoint List** +| Access the <> page, which lists all hosts running {elastic-defend}, and associated integration details. + +| **Trusted Applications** +| Access the <> page to remediate conflicts with other software, such as antivirus or endpoint security applications + +| **Host Isolation Exceptions** +| Access the <> page to add specific IP addresses that isolated hosts can still communicate with. + +| **Blocklist** +| Access the <> page to prevent specified applications from running on hosts, extending the list of processes that {elastic-defend} considers malicious. + +| **Event Filters** +| Access the <> page to filter out endpoint events that you don't want stored in {es}. + +| **{elastic-defend} Policy Management** +| Access the <> page and {elastic-defend} integration policies to configure protections, event collection, and advanced policy features. + +| **Response Actions History** +| Access the <> for endpoints. + +| **Host Isolation** +| Allow users to <>. + +| **Process Operations** +| Perform host process-related <>, including `processes`, `kill-process`, and `suspend-process`. + +| **File Operations** +| Perform file-related <> in the response console. + +| **Execute Operations** +a| Perform shell commands and script-related <> in the response console. + +[WARNING] +==== +The commands are run on the host using the same user account running the {elastic-defend} integration, which normally has full control over the system. Only grant this feature privilege to {elastic-sec} users who require this level of access. +==== + +| **Scan Operations** +| Perform folder scan <> in the response console. +|=== diff --git a/docs/serverless/edr-install-config/deploy-endpoint-macos-cat-mont.asciidoc b/docs/serverless/edr-install-config/deploy-endpoint-macos-cat-mont.asciidoc new file mode 100644 index 0000000000..b626a83e28 --- /dev/null +++ b/docs/serverless/edr-install-config/deploy-endpoint-macos-cat-mont.asciidoc @@ -0,0 +1,92 @@ +[[install-endpoint-manually]] += Enable access for macOS Monterey + +:description: Configure access for deploying {elastic-defend} on macOS Monterey. +:keywords: security, how-to, secure + +preview:[] + +To properly install and configure {elastic-defend} manually without a Mobile Device Management (MDM) profile, there are additional permissions that must be enabled on the host before {elastic-endpoint}—the installed component that performs {elastic-defend}'s threat monitoring and prevention—is fully functional: + +* <> +* <> +* <> + +[NOTE] +==== +The following permissions that need to be enabled are required after you <>, which includes <>. +==== + +[discrete] +[[system-extension-endpoint]] +== Approve the system extension for {elastic-endpoint} + +For macOS Monterey (12.x), {elastic-endpoint} will attempt to load a system extension during installation. This system extension must be loaded in order to provide insight into system events such as process events, file system events, and network events. + +The following message appears during installation: + +[role="screenshot"] +image::images/deploy-elastic-endpoint/-getting-started-install-endpoint-system-ext-blocked.png[] + +. Click **Open Security Preferences**. +. In the lower-left corner of the **Security & Privacy** pane, click the **Lock button**, then enter your credentials to authenticate. ++ +[role="screenshot"] +image::images/deploy-elastic-endpoint/-getting-started-fda-lock-button.png[] +. Click **Allow** to allow the {elastic-endpoint} system extension to load. ++ +[role="screenshot"] +image::images/deploy-elastic-endpoint/-getting-started-install-endpoint-allow-system-ext.png[] + +[discrete] +[[allow-filter-content]] +== Approve network content filtering for {elastic-endpoint} + +After successfully loading the {elastic-endpoint} system extension, an additional message appears, asking to allow {elastic-endpoint} to filter network content. + +[role="screenshot"] +image::images/deploy-elastic-endpoint/-getting-started-install-endpoint-filter-network-content.png[] + +* Click **Allow** to enable content filtering for the {elastic-endpoint} system extension. Without this approval, {elastic-endpoint} cannot receive network events and, therefore, cannot enable network-related features such as <>. + +[discrete] +[[enable-fda-endpoint]] +== Enable Full Disk Access for {elastic-endpoint} + +{elastic-endpoint} requires Full Disk Access to subscribe to system events via the {elastic-defend} framework and to protect your network from malware and other cybersecurity threats. To enable Full Disk Access on endpoints running macOS Catalina (10.15) and later, you must manually approve {elastic-endpoint}. + +[NOTE] +==== +The following instructions apply only to {elastic-endpoint} version 8.0.0 and later. To see Full Disk Access requirements for the Endgame sensor, refer to Endgame's documentation. +==== + +// Might need to revisit this note and the section. Keep an eye on https://github.com/elastic/staging-serverless-security-docs/issues/124 + +. Open the **System Preferences** application. +. Select **Security and Privacy**. ++ +[role="screenshot"] +image::images/deploy-elastic-endpoint/-getting-started-fda-sec-privacy-pane.png[] +. On the **Security and Privacy** pane, select the **Privacy** tab. +. From the left pane, select **Full Disk Access**. ++ +[role="screenshot"] +image::images/deploy-elastic-endpoint/-getting-started-fda-select-fda.png[Select Full Disk Access] +. In the lower-left corner of the pane, click the **Lock button**, then enter your credentials to authenticate. +. In the **Privacy** tab, confirm that `ElasticEndpoint` AND `co.elastic.systemextension` are selected to properly enable Full Disk Access. ++ +[role="screenshot"] +image::images/deploy-elastic-endpoint/-getting-started-fda-select-endpoint-ext.png[] + +If the endpoint is running {elastic-endpoint} version 7.17.0 or earlier: + +// Might need to revisit this note and the section. Keep an eye on https://github.com/elastic/staging-serverless-security-docs/issues/124 + +. In the lower-left corner of the pane, click the **Lock button**, then enter your credentials to authenticate. +. Click the **+** button to view **Finder**. +. Navigate to `/Library/Elastic/Endpoint`, then select the `elastic-endpoint` file. +. Click **Open**. +. In the **Privacy** tab, confirm that `elastic-endpoint` AND `co.elastic.systemextension` are selected to properly enable Full Disk Access. ++ +[role="screenshot"] +image::images/deploy-elastic-endpoint/-getting-started-fda-fda-7-16.png[] diff --git a/docs/serverless/edr-install-config/deploy-endpoint-macos-ven.asciidoc b/docs/serverless/edr-install-config/deploy-endpoint-macos-ven.asciidoc new file mode 100644 index 0000000000..893c935ca4 --- /dev/null +++ b/docs/serverless/edr-install-config/deploy-endpoint-macos-ven.asciidoc @@ -0,0 +1,100 @@ +[[deploy-elastic-endpoint-ven]] += Enable access for macOS Ventura and higher + +:description: Configure access for deploying {elastic-defend} on macOS Ventura and higher. +:keywords: security, how-to, secure + +preview:[] + +To properly install and configure {elastic-defend} manually without a Mobile Device Management (MDM) profile, there are additional permissions that must be enabled on the host before {elastic-endpoint}—the installed component that performs {elastic-defend}'s threat monitoring and prevention—is fully functional: + +* <> +* <> +* <> + +[NOTE] +==== +The following permissions that need to be enabled are required after you <>, which includes <>. +==== + +[discrete] +[[system-extension-endpoint-ven]] +== Approve the system extension for {elastic-endpoint} + +For macOS Ventura (13.0) and later, {elastic-endpoint} will attempt to load a system extension during installation. This system extension must be loaded in order to provide insight into system events such as process events, file system events, and network events. + +The following message appears during installation: + +[role="screenshot"] +image::images/deploy-elastic-endpoint-ven/-getting-started-install-endpoint-ven-system_extension_blocked_warning_ven.png[] + +. Click **Open System Settings**. +. In the left pane, click **Privacy & Security**. ++ +[role="screenshot"] +image::images/deploy-elastic-endpoint-ven/-getting-started-install-endpoint-ven-privacy_security_ven.png[] +. On the right pane, scroll down to the Security section. Click **Allow** to allow the ElasticEndpoint system extension to load. ++ +[role="screenshot"] +image::images/deploy-elastic-endpoint-ven/-getting-started-install-endpoint-ven-allow_system_extension_ven.png[] +. Enter your username and password and click **Modify Settings** to save your changes. ++ +[role="screenshot"] +image::images/deploy-elastic-endpoint-ven/-getting-started-install-endpoint-ven-enter_login_details_to_confirm_ven.png[] + +[discrete] +[[allow-filter-content-ven]] +== Approve network content filtering for {elastic-endpoint} + +After successfully loading the ElasticEndpoint system extension, an additional message appears, asking to allow {elastic-endpoint} to filter network content. + +[role="screenshot"] +image::images/deploy-elastic-endpoint-ven/-getting-started-install-endpoint-ven-allow_network_filter_ven.png[] + +Click **Allow** to enable content filtering for the ElasticEndpoint system extension. Without this approval, {elastic-endpoint} cannot receive network events and, therefore, cannot enable network-related features such as <>. + +[discrete] +[[enable-fda-endpoint-ven]] +== Enable Full Disk Access for {elastic-endpoint} + +{elastic-endpoint} requires Full Disk Access to subscribe to system events via the {elastic-defend} framework and to protect your network from malware and other cybersecurity threats. Full Disk Access permissions is a privacy feature introduced in macOS Mojave (10.14) that prevents some applications from accessing your data. + +If you have not granted Full Disk Access, the following notification prompt will appear. + +[role="screenshot"] +image::images/deploy-elastic-endpoint-ven/-getting-started-install-endpoint-ven-allow_full_disk_access_notification_ven.png[] + +To enable Full Disk Access, you must manually approve {elastic-endpoint}. + +[NOTE] +==== +The following instructions apply only to {elastic-endpoint} version 8.0.0 and later. To see Full Disk Access requirements for the Endgame sensor, refer to Endgame's documentation. +==== + +. Open the **System Settings** application. +. In the left pane, select **Privacy & Security**. ++ +[role="screenshot"] +image::images/deploy-elastic-endpoint-ven/-getting-started-install-endpoint-ven-privacy_security_ven.png[] +. From the right pane, select **Full Disk Access**. ++ +[role="screenshot"] +image::images/deploy-elastic-endpoint-ven/-getting-started-install-endpoint-ven-select_fda_ven.png[Select Full Disk Access] +. Enable `ElasticEndpoint` and `co.elastic` to properly enable Full Disk Access. ++ +[role="screenshot"] +image::images/deploy-elastic-endpoint-ven/-getting-started-install-endpoint-ven-allow_fda_ven.png[] + +If the endpoint is running {elastic-endpoint} version 7.17.0 or earlier: + +. Click the **+** button to view **Finder**. +. The system may prompt you to enter your username and password if you haven't already. ++ +[role="screenshot"] +image::images/deploy-elastic-endpoint-ven/-getting-started-install-endpoint-ven-enter_login_details_to_confirm_ven.png[] +. Navigate to `/Library/Elastic/Endpoint`, then select the `elastic-endpoint` file. +. Click **Open**. +. In the **Privacy** tab, confirm that `ElasticEndpoint` and `co.elastic.systemextension` are selected to properly enable Full Disk Access. + +[role="screenshot"] +image::images/deploy-elastic-endpoint-ven/-getting-started-install-endpoint-ven-verify_fed_granted_ven.png[Select Full Disk Access] diff --git a/docs/serverless/edr-install-config/deploy-endpoint-reqs.asciidoc b/docs/serverless/edr-install-config/deploy-endpoint-reqs.asciidoc new file mode 100644 index 0000000000..77278662dd --- /dev/null +++ b/docs/serverless/edr-install-config/deploy-endpoint-reqs.asciidoc @@ -0,0 +1,29 @@ +[[elastic-endpoint-deploy-reqs]] += {elastic-defend} requirements + +:description: System requirements for {elastic-defend}. +:keywords: security, other, secure + +preview:[] + +To properly deploy {elastic-defend} without a Mobile Device Management (MDM) profile, you must manually enable additional permissions on the host before {elastic-endpoint}—the installed component that performs {elastic-defend}'s threat monitoring and prevention—is fully functional. For more information, refer to the instructions for your macOS version: + +* <> +* <> + +[discrete] +[[elastic-endpoint-deploy-reqs-minimum-system-requirements]] +== Minimum system requirements + +|=== +| Requirement| Value + +| **CPU** +| Under 2% + +| **Disk space** +| 1 GB + +| **Resident set size (RSS) memory** +| 500 MB +|=== diff --git a/docs/serverless/edr-install-config/deploy-with-mdm.asciidoc b/docs/serverless/edr-install-config/deploy-with-mdm.asciidoc new file mode 100644 index 0000000000..68a717a279 --- /dev/null +++ b/docs/serverless/edr-install-config/deploy-with-mdm.asciidoc @@ -0,0 +1,142 @@ +[[deploy-with-mdm]] += Deploy {elastic-defend} on macOS with mobile device management + +:description: Configure access for deploying {elastic-defend} on macOS with mobile device management. +:keywords: security, how-to, secure + +++++ +Deploy on macOS with MDM +++++ + +preview:[] + +To silently install and deploy {elastic-defend} without the need for user interaction, you need to configure a mobile device management (MDM) profile for {elastic-endpoint}—the installed component that performs {elastic-defend}'s threat monitoring and prevention. This allows you to pre-approve the {elastic-endpoint} system extension and grant Full Disk Access to all the necessary components. + +This page explains how to deploy {elastic-defend} silently using Jamf. + +[discrete] +[[deploy-with-mdm-configure-a-jamf-mdm-profile]] +== Configure a Jamf MDM profile + +In Jamf, create a configuration profile for {elastic-endpoint}. Follow these steps to configure the profile: + +. <>. +. <>. +. <>. +. <>. + +[discrete] +[[deploy-with-mdm-approve-the-system-extension]] +=== Approve the system extension + +. Select the **System Extensions** option to configure the system extension policy for the {elastic-endpoint} configuration profile. +. Make sure that **Allow users to approve system extensions** is selected. +. In the **Allowed Team IDs and System Extensions** section, add the {elastic-endpoint} system extension: ++ +.. (Optional) Enter a **Display Name** for the {elastic-endpoint} system extension. +.. From the **System Extension Types** dropdown, select **Allowed System Extensions**. +.. Under **Team Identifier**, enter `2BT3HPN62Z`. +.. Under **Allowed System Extensions**, enter `co.elastic.systemextension`. +. Save the configuration. + +[role="screenshot"] +image::images/deploy-with-mdm/system-extension-jamf.png[] + +[discrete] +[[deploy-with-mdm-approve-network-content-filtering]] +=== Approve network content filtering + +. Select the **Content Filter** option to configure the Network Extension policy for the {elastic-endpoint} configuration profile. +. Under **Filter Name**, enter `ElasticEndpoint`. +. Under **Identifier**, enter `co.elastic.endpoint`. +. In the **Socket Filter** section, fill in these fields: ++ +.. **Socket Filter Bundle Identifier**: Enter `co.elastic.systemextension` +.. **Socket Filter Designated Requirement**: Enter the following: ++ +[source] +---- +identifier "co.elastic.systemextension" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "2BT3HPN62Z" +---- +. In the **Network Filter** section, fill in these fields: ++ +.. **Network Filter Bundle Identifier**: Enter `co.elastic.systemextension` +.. **Network Filter Designated Requirement**: Enter the following: ++ +[source] +---- +identifier "co.elastic.systemextension" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "2BT3HPN62Z" +---- +. Save the configuration. + +[role="screenshot"] +image::images/deploy-with-mdm/content-filtering-jamf.png[] + +[discrete] +[[deploy-with-mdm-enable-notifications]] +=== Enable notifications + +. Select the **Notifications** option to configure the Notification Center policy for the {elastic-endpoint} configuration profile. +. Under **App Name**, enter `Elastic Security.app`. +. Under **Bundle ID**, enter `co.elastic.alert`. +. In the **Settings** section, include these options with the following settings: ++ +.. **Critical Alerts**: **Enable**. +.. **Notifications**: **Enable**. +.. **Banner alert type**: **Persistent**. +.. **Notifications on Lock Screen**: **Display**. +.. **Notifications in Notification Center**: **Display**. +.. **Badge app icon**: **Display**. +.. **Play sound for notifications**: **Enable**. +. Save the configuration. + +[role="screenshot"] +image::images/deploy-with-mdm/notifications-jamf.png[] + +[discrete] +[[deploy-with-mdm-enable-full-disk-access]] +=== Enable Full Disk Access + +. Select the **Privacy Preferences Policy Control** option to configure the Full Disk Access policy for the {elastic-endpoint} configuration profile. +. Add a new entry with the following details: ++ +.. Under **Identifier**, enter `co.elastic.systemextension`. +.. From the **Identifier Type** dropdown, select **Bundle ID**. +.. Under **Code Requirement**, enter the following: ++ +[source] +---- +identifier "co.elastic.systemextension" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "2BT3HPN62Z" +---- ++ +.. Make sure that **Validate the Static Code Requirement** is selected. +. Add a second entry with the following details: ++ +.. Under **Identifier**, enter `co.elastic.endpoint`. +.. From the **Identifier Type** dropdown, select **Bundle ID**. +.. Under **Code Requirement**, enter the following: ++ +[source] +---- +identifier "co.elastic.endpoint" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "2BT3HPN62Z" +---- ++ +.. Make sure that **Validate the Static Code Requirement** is selected. +. Add a third entry with the following details: ++ +.. Under **Identifier**, enter `co.elastic.elastic-agent`. +.. From the **Identifier Type** dropdown, select **Bundle ID**. +.. Under **Code Requirement**, enter the following: ++ +[source] +---- +identifier "co.elastic.elastic-agent" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "2BT3HPN62Z" +---- ++ +.. Make sure that **Validate the Static Code Requirement** is selected. +. Save the configuration. + +[role="screenshot"] +image::images/deploy-with-mdm/fda-jamf.png[] + +After you complete these steps, generate the mobile configuration profile and install it onto the macOS machines. Once the profile is installed, {elastic-defend} can be deployed without the need for user interaction. diff --git a/docs/serverless/edr-install-config/endpoint-data-volume.asciidoc b/docs/serverless/edr-install-config/endpoint-data-volume.asciidoc new file mode 100644 index 0000000000..22536a926d --- /dev/null +++ b/docs/serverless/edr-install-config/endpoint-data-volume.asciidoc @@ -0,0 +1,20 @@ +[[endpoint-data-volume]] += Configure {elastic-endpoint}'s data volume + +:description: +:keywords: serverless, security, how-to + +++++ +Configure data volume +++++ + +[NOTE] +==== +++++ +
+++++ +**This is a placeholder for future documentation.** +++++ +
+++++ +==== diff --git a/docs/serverless/edr-install-config/endpoint-diagnostic-data.asciidoc b/docs/serverless/edr-install-config/endpoint-diagnostic-data.asciidoc new file mode 100644 index 0000000000..322c61d63c --- /dev/null +++ b/docs/serverless/edr-install-config/endpoint-diagnostic-data.asciidoc @@ -0,0 +1,24 @@ +[[endpoint-diagnostic-data]] += Turn off diagnostic data for {elastic-defend} + +:description: Stop producing diagnostic data for Elastic defend by configuring your integration policy. +:keywords: serverless, security, how-to + +preview:[] + +By default, {elastic-defend} streams diagnostic data to your cluster, which Elastic uses to tune protection features. You can stop producing this diagnostic data by configuring the advanced settings in the {elastic-defend} integration policy. + +[NOTE] +==== +{elastic-sec} also collects usage telemetry, which includes {elastic-defend} diagnostic data. You can modify telemetry preferences in {kibana-ref}/telemetry-settings-kbn.html[Advanced Settings]. +==== + +. Go to **Assets** → **Endpoints** to view the Endpoints list. +. Locate the endpoint for which you want to disable diagnostic data, then click the integration policy in the **Policy** column. +. Scroll down to the bottom of the policy and click **Show advanced settings**. +. Enter `false` for these settings: ++ +** `windows.advanced.diagnostic.enabled` +** `linux.advanced.diagnostic.enabled` +** `mac.advanced.diagnostic.enabled` +. Click **Save**. diff --git a/docs/serverless/edr-install-config/endpoint-protection-intro.asciidoc b/docs/serverless/edr-install-config/endpoint-protection-intro.asciidoc new file mode 100644 index 0000000000..d520257c12 --- /dev/null +++ b/docs/serverless/edr-install-config/endpoint-protection-intro.asciidoc @@ -0,0 +1,9 @@ +[[endpoint-protection-intro]] += Configure endpoint protection with {elastic-defend} + +:description: Start protecting your endpoints with {elastic-defend}. +:keywords: serverless, security, overview + +preview:[] + +This section contains information on installing and configuring {elastic-defend} for endpoint protection. diff --git a/docs/serverless/edr-install-config/install-elastic-defend.asciidoc b/docs/serverless/edr-install-config/install-elastic-defend.asciidoc new file mode 100644 index 0000000000..ab68a882b6 --- /dev/null +++ b/docs/serverless/edr-install-config/install-elastic-defend.asciidoc @@ -0,0 +1,118 @@ +[[install-edr]] += Install the {elastic-defend} integration + +:description: Start protecting your endpoints with {elastic-defend}. +:keywords: serverless, security, how-to + +++++ +Install Elastic Defend +++++ + +preview:[] + +Like other Elastic integrations, {elastic-defend} is integrated into the {agent} using {fleet-guide}/fleet-overview.html[{fleet}]. Upon configuration, the integration allows the {agent} to monitor events on your host and send data to the {security-app}. + +.Requirements +[NOTE] +==== +* {fleet} is required for {elastic-defend}. +* To configure the {elastic-defend} integration on the {agent}, you must have permission to use {fleet}. +* You must have the appropriate user role to configure an integration policy and access the **Endpoints** page. + +// Placeholder statement until we know which specific roles are required. Classic statement below for reference. + +// * You must have the **{elastic-defend} Policy Management: All** privilege to configure an integration policy, and the **Endpoint List** privilege to access the **Endpoints** page. +==== + +[discrete] +[[security-before-you-begin]] +== Before you begin + +If you're using macOS, some versions may require you to grant Full Disk Access to different kernels, system extensions, or files. Refer to <> for more information. + +[NOTE] +==== +{elastic-defend} does not support deployment within an {agent} DaemonSet in Kubernetes. +==== + +[discrete] +[[add-security-integration]] +== Add the {elastic-defend} integration + +. Go to the **Integrations** page, which you can access in several ways: ++ +** The **Add integrations** link at the top of most pages +** **Assets** → **Browse Integrations** +** **Project settings** → **Integrations** ++ +[role="screenshot"] +image::images/install-endpoint/-getting-started-install-endpoint-endpoint-cloud-sec-integrations-page.png[Search result for "{elastic-defend}" on the Integrations page.] +. Search for and select **{elastic-defend}**, then select **Add {elastic-defend}**. The integration configuration page appears. ++ +[NOTE] +==== +If this is the first integration you've installed and the **Ready to add your first integration?** page appears instead, select **Add integration only (skip agent installation)** to proceed. You can <> after setting up the {elastic-defend} integration. +==== ++ +[role="screenshot"] +image:images/install-endpoint/-getting-started-install-endpoint-endpoint-cloud-security-configuration.png[Add {elastic-defend} integration page] +. Configure the {elastic-defend} integration with an **Integration name** and optional **Description**. +. Select the type of environment you want to protect, either **Traditional Endpoints** or **Cloud Workloads**. +. Select a configuration preset. Each preset comes with different default settings for {agent} — you can further customize these later by <>. ++ +|=== +| | + +| **Traditional Endpoint presets** +a| All traditional endpoint presets _except_ **Data Collection** have these preventions enabled by default: malware, ransomware, memory threat, malicious behavior, and credential theft. Each preset collects the following events: + +* **Data Collection:** All events; no preventions +* **Next-Generation Antivirus (NGAV):** Process events; all preventions +* **Essential EDR (Endpoint Detection & Response):** Process, Network, File events; all preventions +* **Complete EDR (Endpoint Detection & Response):** All events; all preventions + +| **Cloud Workloads presets** +a| Both cloud workload presets are intended for monitoring cloud-based Linux hosts. Therefore, <> collection, which enriches process events, is enabled by default. They both have all preventions disabled by default, and collect process, network, and file events. + +* **All events:** Includes data from automated sessions. +* **Interactive only:** Filters out data from non-interactive sessions by creating an <>. +|=== +. Enter a name for the agent policy in **New agent policy name**. If other agent policies already exist, you can click the **Existing hosts** tab and select an existing policy instead. For more details on {agent} configuration settings, refer to {fleet-guide}/agent-policy.html[{agent} policies]. +. When you're ready, click **Save and continue**. +. To complete the integration, select **Add {agent} to your hosts** and continue to the next section to install the {agent} on your hosts. + +[discrete] +[[enroll-security-agent]] +== Configure and enroll the {agent} + +To enable the {elastic-defend} integration, you must enroll agents in the relevant policy using {fleet}. + +[IMPORTANT] +==== +Before you add an {agent}, a {fleet-server} must be running. Refer to {fleet-guide}/add-a-fleet-server.html[Add a {fleet-server}]. + +{elastic-defend} cannot be integrated with an {agent} in standalone mode. +==== + +[discrete] +[[enroll-agent]] +=== Add the {agent} + +. If you're in the process of installing an {agent} integration (such as {elastic-defend}), the **Add agent** UI opens automatically. Otherwise, go to **Assets** → **{fleet}** → **Agents** → **Add agent**. ++ +[role="screenshot"] +image::images/install-endpoint/-getting-started-install-endpoint-endpoint-cloud-sec-add-agent.png[Add agent flyout on the Fleet page.] +. Select an agent policy for the {agent}. You can select an existing policy, or select **Create new agent policy** to create a new one. For more details on {agent} configuration settings, refer to {fleet-guide}/agent-policy.html[{agent} policies]. ++ +The selected agent policy should include the integration you want to install on the hosts covered by the agent policy (in this example, {elastic-defend}). ++ +[role="screenshot"] +image:images/install-endpoint/-getting-started-install-endpoint-endpoint-cloud-sec-add-agent-detail.png[Add agent flyout with {elastic-defend} integration highlighted.] +. Ensure that the **Enroll in {fleet}** option is selected. {elastic-defend} cannot be integrated with {agent} in standalone mode. +. Select the appropriate platform or operating system for the host, then copy the provided commands. +. On the host, open a command-line interface and navigate to the directory where you want to install {agent}. Paste and run the commands from {fleet} to download, extract, enroll, and start {agent}. +. (Optional) Return to the **Add agent** flyout in {fleet}, and observe the **Confirm agent enrollment** and **Confirm incoming data** steps automatically checking the host connection. It may take a few minutes for data to arrive in {es}. +. After you have enrolled the {agent} on your host, you can click **View enrolled agents** to access the list of agents enrolled in {fleet}. Otherwise, select **Close**. ++ +The host will now appear on the **Endpoints** page in the {security-app}. It may take another minute or two for endpoint data to appear in {elastic-sec}. +. For macOS, continue with <> to grant {elastic-endpoint} the required permissions. diff --git a/docs/serverless/edr-install-config/linux-file-monitoring.asciidoc b/docs/serverless/edr-install-config/linux-file-monitoring.asciidoc new file mode 100644 index 0000000000..1a1023a764 --- /dev/null +++ b/docs/serverless/edr-install-config/linux-file-monitoring.asciidoc @@ -0,0 +1,97 @@ +[[linux-file-monitoring]] += Configure Linux file system monitoring + +:description: Configure monitoring for Linux file systems. +:keywords: serverless, security, how-to + +++++ +File system monitoring (Linux) +++++ + +preview:[] + +By default, {elastic-defend} monitors specific Linux file system types that Elastic has tested for compatibility. If your network includes nonstandard, proprietary, or otherwise unrecognized Linux file systems, you can configure the integration policy to extend monitoring and protections to those additional file systems. You can also have {elastic-defend} ignore unrecognized file system types if they don't require monitoring or cause unexpected problems. + +[CAUTION] +==== +Ignoring file systems can create gaps in your security coverage. Use additional security layers for any file systems ignored by {elastic-defend}. +==== + +To monitor or ignore additional file systems, configure the following advanced settings related to **fanotify**, a Linux feature that monitors file system events. Go to **Assets** → **Policies**, click a policy's name, then scroll down and select **Show advanced settings**. + +[NOTE] +==== +Even when configured to monitor all file systems (`ignore_unknown_filesystems` is `false`), {elastic-defend} will still ignore specific file systems that Elastic has internally identified as incompatible. The following settings apply to any _other_ file systems. +==== + +`linux.advanced.fanotify.ignore_unknown_filesystems`:: +Determines whether to ignore unrecognized file systems. Enter one of the following: + +* `true`: (Default) Monitor only Elastic-tested file systems, and ignore all others. You can still monitor or ignore specific file systems with `monitored_filesystems` and `ignored_filesystems`, respectively. +* `false`: Monitor all file systems. You can still ignore specific file systems with `ignored_filesystems`. ++ +[NOTE] +==== +If you don't need to monitor additional file systems, it's recommended to change `ignore_unknown_filesystems` to `true`. +==== + +`linux.advanced.fanotify.monitored_filesystems`:: +Specifies additional file systems to monitor. Enter a comma-separated list of <> as they appear in `/proc/filesystems` (for example: `jfs,ufs,ramfs`). + +[NOTE] +==== +It's recommended to avoid monitoring network-backed file systems. +==== + +This setting isn't recognized if `ignore_unknown_filesystems` is `false`, since that would mean you're already monitoring _all_ file systems. + +Entries in this setting are overridden by entries in `ignored_filesystems`. + +`linux.advanced.fanotify.ignored_filesystems`:: +Specifies additional file systems to ignore. Enter a comma-separated list of <> as they appear in `/proc/filesystems` (for example: `ext4,tmpfs`). + +Entries in this setting override entries in `monitored_filesystems`. + +[discrete] +[[find-file-system-names]] +== Find file system names + +This section provides a few ways to determine the file system names needed for `linux.advanced.fanotify.monitored_filesystems` and `linux.advanced.fanotify.ignored_filesystems`. + +In a typical setup, when you install {agent}, {filebeat} is installed alongside {elastic-endpoint} and will automatically ship {elastic-endpoint} logs to {es}. {elastic-endpoint} will generate a log message about the file that was scanned when an event occurs. + +To find the system file name: + +. From the Hosts page (**Explore** → **Hosts**), search for `message: "Current sync path"` to reveal the file path. +. If you have access to the endpoint, run `findmnt -o FSTYPE -T ` to return the file system. For example: ++ +[source,shell] +---- +\> findmnt -o FSTYPE -T /etc/passwd +FSTYPE +ext4 +---- ++ +This returns the file system name as `ext4`. + +Alternatively, you can also find the file system name by correlating data from two other log messages: + +. Search the logs for `message: "Current fdinfo"` to reveal the `mnt_id` value of the file path. In this example, the `mnt_id` value is `29`: ++ +[source,shell] +---- +pos: 12288 +flags: 02500002 +mnt_id: 29 +ino: 2367737 +---- +. Search the logs for `message: "Current mountinfo"` to reveal the file system that corresponds to the `mnt_id` value you found in the previous step: ++ +[source,shell] +---- + +29 1 8:2 / / rw,relatime shared:1 - ext4 /dev/sda2 rw,errors=remount-ro + +---- ++ +The first number, `29`, is the `mnt_id`, and the first field after the hyphen (`-`) is the file system name, `ext4`. diff --git a/docs/serverless/edr-install-config/self-healing-rollback.asciidoc b/docs/serverless/edr-install-config/self-healing-rollback.asciidoc new file mode 100644 index 0000000000..e25db921d7 --- /dev/null +++ b/docs/serverless/edr-install-config/self-healing-rollback.asciidoc @@ -0,0 +1,29 @@ +[[self-healing-rollback]] += Configure self-healing rollback for Windows endpoints + +:description: Revert file changes on the Windows endpoints. +:keywords: serverless, security, how-to + +++++ +Self-healing rollback (Windows) +++++ + +preview:[] + +{elastic-defend}'s self-healing feature rolls back file changes on Windows endpoints when a prevention alert is generated by enabled protection features. File changes that occurred on the host within five minutes before the prevention alert will revert to their previous state (which may be up to two hours before the alert). + +This can help contain the impact of malicious activity, as {elastic-defend} not only stops the activity but also erases any attack artifacts deployed prior to detection. + +Self-healing rollback requires the Endpoint Protection Complete https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature] and is only supported for Windows endpoints. + +[CAUTION] +==== +This feature can cause permanent data loss since it overwrites recent changes and deletes recently added files on the host. Self-healing rollback targets the changes related to a detected threat, but may also include incidental actions that aren't directly related to the threat. + +Also, rollback is triggered by _every_ {elastic-defend} prevention alert, so you should tune your system to eliminate false positives before enabling this feature. +==== + +. In the {security-app}, go to **Assets** → **Policies**, then select the integration policy you want to configure. +. Scroll down to the bottom of the policy and click **Show advanced settings**. +. Enter `true` for the setting `windows.advanced.alerts.rollback.self_healing.enabled`. +. Click **Save**. diff --git a/docs/serverless/edr-install-config/uninstall-agent.asciidoc b/docs/serverless/edr-install-config/uninstall-agent.asciidoc new file mode 100644 index 0000000000..1581f88967 --- /dev/null +++ b/docs/serverless/edr-install-config/uninstall-agent.asciidoc @@ -0,0 +1,102 @@ +[[uninstall-agent]] += Uninstall {agent} + +:description: Remove {agent} from a host. +:keywords: serverless, security, how-to + +preview:[] + +To uninstall {agent} from a host, run the `uninstall` command from the directory where it's running. Refer to the {fleet-guide}/uninstall-elastic-agent.html[{fleet} and {agent} documentation] for more information. + +If <> is enabled on the Agent policy for the host, you'll need to include the uninstall token in the command, using the `--uninstall-token` flag. You can <> on the Agent policy or at **{fleet}** -> **Uninstall tokens**. + +For example: + +++++ +
+
+ + +
+
+++++ +[source,shell] +---- +sudo elastic-agent uninstall --uninstall-token 12345678901234567890123456789012 +---- + +++++ +
+ +
+++++ + +[discrete] +[[uninstall-endpoint]] +== Uninstall {elastic-endpoint} + +Use these commands to uninstall {elastic-endpoint} from a host **ONLY** if {fleet-guide}/uninstall-elastic-agent.html[uninstalling an {agent}] is unsuccessful. + +++++ +
+
+ + + +
+
+++++ +[source,shell] +---- +cd /tmp +cp /Library/Elastic/Endpoint/elastic-endpoint elastic-endpoint +sudo ./elastic-endpoint uninstall +rm elastic-endpoint +---- + +++++ +
+ + +
+++++ diff --git a/docs/serverless/edr-manage/allowlist-endpoint-3rd-party-av.asciidoc b/docs/serverless/edr-manage/allowlist-endpoint-3rd-party-av.asciidoc new file mode 100644 index 0000000000..e6b70d99de --- /dev/null +++ b/docs/serverless/edr-manage/allowlist-endpoint-3rd-party-av.asciidoc @@ -0,0 +1,78 @@ +[[allowlist-endpoint]] += Allowlist {elastic-endpoint} in third-party antivirus apps + +:description: Add {elastic-endpoint} as a trusted application in third-party antivirus (AV) software. +:keywords: serverless, security, overview + +preview:[] + +[NOTE] +==== +If you use other antivirus (AV) software along with {elastic-defend}, you may need to add the other system as a trusted application in the {security-app}. Refer to <> for more information. +==== + +Third-party antivirus (AV) applications may identify the expected behavior of {elastic-endpoint}—the installed component that performs {elastic-defend}'s threat monitoring and prevention—as a potential threat. Add {elastic-endpoint}'s digital signatures and file paths to your AV software's allowlist to ensure {elastic-endpoint} continues to function as intended. We recommend you allowlist both the file paths and digital signatures, if applicable. + +[NOTE] +==== +Your AV software may refer to allowlisted processes as process exclusions, ignored processes, or trusted processes. It is important to note that file, folder, and path-based exclusions/exceptions are distinct from trusted applications and will not achieve the same result. This page explains how to ignore actions taken by processes, not how to ignore the files that spawned those processes. +==== + +[discrete] +[[allowlist-endpoint-allowlist-elastic-endpoint-on-windows]] +== Allowlist {elastic-endpoint} on Windows + +File paths: + +* ELAM driver: `c:\Windows\system32\drivers\elastic-endpoint-driver.sys` +* Driver: `c:\Windows\system32\drivers\ElasticElam.sys` +* Executable: `c:\Program Files\Elastic\Endpoint\elastic-endpoint.exe` ++ +[NOTE] +==== +The executable runs as `elastic-endpoint.exe`. +==== + +Digital signatures: + +* `Elasticsearch, Inc.` +* `Elasticsearch B.V.` + +For additional information about allowlisting on Windows, refer to https://github.com/elastic/endpoint/blob/main/PerformanceIssues-Windows.md#trusting-elastic-defend-in-other-software[Trusting Elastic Defend in other software]. + +[discrete] +[[allowlist-endpoint-allowlist-elastic-endpoint-on-macos]] +== Allowlist {elastic-endpoint} on macOS + +File paths: + +* System extension (recursive directory structure): `/Applications/ElasticEndpoint.app/` ++ +[NOTE] +==== +The system extension runs as `co.elastic.systemextension`. +==== +* Executable: `/Library/Elastic/Endpoint/elastic-endpoint.app/Contents/MacOS/elastic-endpoint` ++ +[NOTE] +==== +The executable runs as `elastic-endpoint`. +==== + +Digital signatures: + +* Authority/Developer ID Application: `Elasticsearch, Inc (2BT3HPN62Z)` +* Team ID: `2BT3HPN62Z` + +[discrete] +[[allowlist-endpoint-allowlist-elastic-endpoint-on-linux]] +== Allowlist {elastic-endpoint} on Linux + +File path: + +* Executable: `/opt/Elastic/Endpoint/elastic-endpoint` ++ +[NOTE] +==== +The executable runs as `elastic-endpoint`. +==== diff --git a/docs/serverless/edr-manage/blocklist.asciidoc b/docs/serverless/edr-manage/blocklist.asciidoc new file mode 100644 index 0000000000..b7250b86e2 --- /dev/null +++ b/docs/serverless/edr-manage/blocklist.asciidoc @@ -0,0 +1,96 @@ +[[blocklist]] += Blocklist + +:keywords: serverless, security, how-to + +preview:[] + +The blocklist (**Assets** → **Blocklist**) allows you to prevent specified applications from running on hosts, extending the list of processes that {elastic-defend} considers malicious. This helps ensure that known malicious processes aren't accidentally executed by end users. + +The blocklist is not intended to broadly block benign applications for non-security reasons; only use it to block potentially harmful applications. To compare the blocklist with other endpoint artifacts, refer to <>. + +.Requirements +[NOTE] +==== +* In addition to configuring specific entries on the **Blocklist** page, you must also ensure that the blocklist is enabled on the {elastic-defend} integration policy in the <>. This setting is enabled by default. +* You must have the appropriate user role to use this feature. + +// Placeholder statement until we know which specific roles are required. Classic statement below for reference. + +// * You must have the **Blocklist** privilege to access this feature. +==== + +By default, a blocklist entry is recognized globally across all hosts running {elastic-defend}. You can also assign a blocklist entry to specific {elastic-defend} integration policies, which blocks the process only on hosts assigned to that policy. + +. Go to **Assets** → **Blocklist**. +. Click **Add blocklist entry**. The **Add blocklist** flyout appears. +. Fill in these fields in the **Details** section: ++ +.. `Name`: Enter a name to identify the application in the blocklist. +.. `Description`: Enter a description to provide more information on the blocklist entry (optional). +. In the **Conditions** section, enter the following information about the application you want to block: ++ +.. `Select operating system`: Select the appropriate operating system from the drop-down. +.. `Field`: Select a field to identify the application being blocked: ++ +*** `Hash`: The MD5, SHA-1, or SHA-256 hash value of the application's executable. +*** `Path`: The full file path of the application's executable. +*** `Signature`: (Windows only) The name of the application's digital signer. ++ +[TIP] +==== +To find the signer's name for an application, go to **Discover** and query the process name of the application's executable (for example, `process.name : "mctray.exe"` for a McAfee security binary). Then, search the results for the `process.code_signature.subject_name` field, which contains the signer's name (for example, `McAfee, Inc.`). +==== +.. `Operator`: For hash and path conditions, the operator is `is one of` and can't be modified. For signature conditions, choose `is one of` to enter multiple values or `is` for one value. +.. `Value`: Enter the hash value, file path, or signer name. To enter multiple values (such as a list of known malicious hash values), you can enter each value individually or paste a comma-delimited list, then press **Return**. ++ +[NOTE] +==== +Hash values must be valid to add them to the blocklist. +==== +. Select an option in the **Assignment** section to assign the blocklist entry to a specific integration policy: ++ +** `Global`: Assign the blocklist entry to all {elastic-defend} integration policies. +** `Per Policy`: Assign the blocklist entry to one or more specific {elastic-defend} integration policies. Select each policy where you want the blocklist entry to apply. ++ +[NOTE] +==== +You can also select the `Per Policy` option without immediately assigning a policy to the blocklist entry. For example, you could do this to create and review your blocklist configurations before putting them into action with a policy. +==== +. Click **Add blocklist**. The new entry is added to the **Blocklist** page. +. When you're done adding entries to the blocklist, ensure that the blocklist is enabled for the {elastic-defend} integration policies that you just assigned: ++ +.. Go to **Assets** → **Policies**, then click on an integration policy. +.. On the **Policy settings** tab, ensure that the **Malware protections** and **Blocklist** toggles are switched on. Both settings are enabled by default. + +[discrete] +[[manage-blocklist]] +== View and manage the blocklist + +The **Blocklist** page (**Assets** → **Blocklist**) displays all the blocklist entries that have been added to the {security-app}. To refine the list, use the search bar to search by name, description, or field value. + +[role="screenshot"] +image::images/blocklist/-management-admin-blocklist.png[] + +[discrete] +[[edit-blocklist-entry]] +=== Edit a blocklist entry + +You can individually modify each blocklist entry. You can also change the policies that a blocklist entry is assigned to. + +To edit a blocklist entry: + +. Click the actions menu (image:images/icons/boxesHorizontal.svg[Actions menu icon]) for the blocklist entry you want to edit, then select **Edit blocklist**. +. Modify details as needed. +. Click **Save**. + +[discrete] +[[delete-blocklist-entry]] +=== Delete a blocklist entry + +You can delete a blocklist entry, which removes it entirely from all {elastic-defend} policies. This allows end users to access the application that was previously blocked. + +To delete a blocklist entry: + +. Click the actions menu (image:images/icons/boxesHorizontal.svg[Actions menu icon]) for the blocklist entry you want to delete, then select **Delete blocklist**. +. On the dialog that opens, verify that you are removing the correct blocklist entry, then click **Delete**. A confirmation message displays. diff --git a/docs/serverless/edr-manage/endpoint-command-ref.asciidoc b/docs/serverless/edr-manage/endpoint-command-ref.asciidoc new file mode 100644 index 0000000000..05488c5271 --- /dev/null +++ b/docs/serverless/edr-manage/endpoint-command-ref.asciidoc @@ -0,0 +1,378 @@ +[[endpoint-command-ref]] += {elastic-endpoint} command reference + +:description: Manage and troubleshoot {elastic-endpoint} using CLI commands. +:keywords: security, reference, manage + +preview:[] + +This page lists the commands for management and troubleshooting of {elastic-endpoint}, the installed component that performs {elastic-defend}'s threat monitoring and prevention. + +[NOTE] +==== +* {elastic-endpoint} is not added to the `PATH` system variable, so you must prepend the commands with the full OS-dependent path: ++ +** On Windows: `"C:\Program Files\Elastic\Endpoint\elastic-endpoint.exe"` +** On macOS: `/Library/Elastic/Endpoint/elastic-endpoint` +** On Linux: `/opt/Elastic/Endpoint/elastic-endpoint` +* You must run the commands with elevated privileges—using `sudo` to run as the root user on Linux and macOS, or running as Administrator on Windows. +==== + +The following {elastic-endpoint} commands are available: + +* <> +* <> +* <> +* <> +* <> +* <> +* <> +* <> +* <> +* <> +* <> +* <> + +Each of the commands accepts the following logging options: + +* `--log [stdout,stderr,debugview,file]` +* `--log-level [error,info,debug]` + +[discrete] +[[endpoint-command-ref-elastic-endpoint-diagnostics]] +== elastic-endpoint diagnostics + +Gather diagnostics information from {elastic-endpoint}. This command produces an archive that contains: + +* `version.txt`: Version information +* `elastic-endpoint.yaml`: Current policy +* `metrics.json`: Metrics document +* `policy_response.json`: Last policy response +* `system_info.txt`: System information +* `analysis.txt`: Diagnostic analysis report +* `logs` directory: Copy of {elastic-endpoint} log files + +[discrete] +[[endpoint-command-ref-example]] +=== Example + +[source] +---- +elastic-endpoint diagnostics +---- + +[discrete] +[[endpoint-command-ref-elastic-endpoint-help]] +== elastic-endpoint help + +Show help for the available commands. + +[discrete] +[[endpoint-command-ref-example-1]] +=== Example + +[source] +---- +elastic-endpoint help +---- + +[discrete] +[[endpoint-command-ref-elastic-endpoint-inspect]] +== elastic-endpoint inspect + +Show the current {elastic-endpoint} configuration. + +[discrete] +[[endpoint-command-ref-example-2]] +=== Example + +[source] +---- +elastic-endpoint inspect +---- + +[discrete] +[[endpoint-command-ref-elastic-endpoint-install]] +== elastic-endpoint install + +Install {elastic-endpoint} as a system service. + +[NOTE] +==== +We do not recommend installing {elastic-endpoint} using this command. {elastic-endpoint} is managed by {agent} and cannot function as a standalone service. Therefore, there is no separate installation package for {elastic-endpoint}, and it should not be installed independently. +==== + +[discrete] +[[endpoint-command-ref-options-3]] +=== Options + +`--resources `:: +Specify a resources `.zip` file to be used during the installation. This option is required. + +`--upgrade`:: +Upgrade the existing installation. + +[discrete] +[[endpoint-command-ref-example-4]] +=== Example + +[source] +---- +elastic-endpoint install --upgrade --resources endpoint-security-resources.zip +---- + +[discrete] +[[endpoint-command-ref-elastic-endpoint-memorydump]] +== elastic-endpoint memorydump + +Save a memory dump of the {elastic-endpoint} service. + +[discrete] +[[endpoint-command-ref-options-5]] +=== Options + +`--compress`:: +Compress the saved memory dump. + +`--timeout `:: +Specify the memory collection timeout, in seconds; the default is 60 seconds. + +[discrete] +[[endpoint-command-ref-example-6]] +=== Example + +[source] +---- +elastic-endpoint memorydump --timeout 120 +---- + +[discrete] +[[endpoint-command-ref-elastic-endpoint-run]] +== elastic-endpoint run + +Run `elastic-endpoint` as a foreground process if no other instance is already running. + +[discrete] +[[endpoint-command-ref-example-7]] +=== Example + +[source] +---- +elastic-endpoint run +---- + +[discrete] +[[endpoint-command-ref-elastic-endpoint-send]] +== elastic-endpoint send + +Send the requested document to the {stack}. + +[discrete] +[[endpoint-command-ref-subcommands-8]] +=== Subcommands + +`metadata`:: +Send an off-schedule metrics document to the {stack}. + +[discrete] +[[endpoint-command-ref-example-9]] +=== Example + +[source] +---- +elastic-endpoint send metadata +---- + +[discrete] +[[endpoint-command-ref-elastic-endpoint-status]] +== elastic-endpoint status + +Retrieve the current status of the running {elastic-endpoint} service. The command also returns the last known status of {agent}. + +[discrete] +[[endpoint-command-ref-options-10]] +=== Options + +`--output`:: +Control the level of detail and formatting of the information. Valid values are: + +* `human`: Returns limited information when {elastic-endpoint}'s status is `Healthy`. If any policy actions weren't successfully applied, the relevant details are displayed. +* `full`: Always returns the full status information. +* `json`: Always returns the full status information. + +[discrete] +[[endpoint-command-ref-example-11]] +=== Example + +[source] +---- +elastic-endpoint status --output json +---- + +[discrete] +[[endpoint-command-ref-elastic-endpoint-test]] +== elastic-endpoint test + +Perform the requested test. + +[discrete] +[[endpoint-command-ref-subcommands-12]] +=== Subcommands + +`output`:: +Test whether {elastic-endpoint} can connect to remote resources. + +[discrete] +[[endpoint-command-ref-example-13]] +=== Example + +[source] +---- +elastic-endpoint test output +---- + +[discrete] +[[endpoint-command-ref-example-output-14]] +=== Example output + +[source] +---- +Testing output connections + +Using proxy: + +Elasticsearch server: https://example.elastic.co:443 + Status: Success + +Global artifact server: https://artifacts.security.elastic.co + Status: Success + +Fleet server: https://fleet.example.elastic.co:443 + Status: Success +---- + +[discrete] +[[endpoint-command-ref-elastic-endpoint-top]] +== elastic-endpoint top + +Show a breakdown of the executables that triggered {elastic-endpoint} CPU usage within the last interval. This displays which {elastic-endpoint} features are resource-intensive for a particular executable. + +[NOTE] +==== +The meaning and output of this command are similar, but not identical, to the POSIX `top` command. The `elastic-endpoint top` command aggregates multiple processes by executable. The utilization values aren't measured by the OS scheduler but by a wall clock in user mode. The output helps identify outliers causing excessive CPU utilization, allowing you to fine-tune the {elastic-defend} policy and exception lists in your deployment. +==== + +[discrete] +[[endpoint-command-ref-options-15]] +=== Options + +`--interval `:: +Specify the data collection interval, in seconds; the default is 5 seconds. + +`--limit `:: +Specify the number of updates to collect; by default, data is collected until interrupted by **Ctrl+C**. + +`--normalized`:: +Normalize CPU usage values to a total of 100% across all CPUs on multi-CPU systems. + +[discrete] +[[endpoint-command-ref-example-16]] +=== Example + +[source] +---- +elastic-endpoint top --interval 10 --limit 5 +---- + +[discrete] +[[endpoint-command-ref-example-output-17]] +=== Example output + +[source] +---- +| PROCESS | OVERALL | API | BHVR | DIAG BHVR | DNS | FILE | LIB | MEM SCAN | MLWR | NET | PROC | RANSOM | REG | +============================================================================================================================================================= +| MSBuild.exe | 3146.0 | 0.0 | 0.8 | 0.7 | 0.0 | 2330.9 | 0.0 | 226.2 | 586.9 | 0.0 | 0.0 | 0.4 | 0.0 | +| Microsoft.Management.Services.IntuneWindowsAgen... | 30.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.2 | 29.8 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | +| svchost.exe | 27.3 | 0.0 | 0.1 | 0.1 | 0.0 | 0.4 | 0.2 | 0.0 | 26.6 | 0.0 | 0.0 | 0.0 | 0.0 | +| LenovoVantage-(LenovoServiceBridgeAddin).exe | 0.1 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.1 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | +| Lenovo.Modern.ImController.PluginHost.Device.exe | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | +| msedgewebview2.exe | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | +| msedge.exe | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | +| powershell.exe | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | +| WmiPrvSE.exe | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | +| Lenovo.Modern.ImController.PluginHost.Device.exe | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | +| Slack.exe | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | +| uhssvc.exe | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | +| explorer.exe | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | +| taskhostw.exe | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | +| Widgets.exe | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | +| elastic-endpoint.exe | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | +| sppsvc.exe | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | + +Endpoint service (16 CPU): 113.0% out of 1600% + +Collecting data. Press Ctrl-C to cancel +---- + +[discrete] +[[endpoint-command-ref-column-abbreviations]] +==== Column abbreviations + +* `API`: Event Tracing for Windows (ETW) API events +* `AUTH`: Authentication events +* `BHVR`: Malicious behavior protection +* `CRED`: Credential access events +* `DIAG BHVR`: Diagnostic malicious behavior protection +* `DNS`: DNS events +* `FILE`: File events +* `LIB`: Library load events +* `MEM SCAN`: Memory scanning +* `MLWR`: Malware protection +* `NET`: Network events +* `PROC`: Process events +* `PROC INJ`: Process injection +* `RANSOM`: Ransomware protection +* `REG`: Registry events + +[discrete] +[[endpoint-command-ref-elastic-endpoint-uninstall]] +== elastic-endpoint uninstall + +Uninstall {elastic-endpoint}. + +[NOTE] +==== +{elastic-endpoint} is managed by {agent}. To remove {elastic-endpoint} from the target machine permanently, remove the {elastic-defend} integration from the {fleet} policy. The <> command also uninstalls {elastic-endpoint}; therefore, in practice, the `elastic-endpoint uninstall` command is used only to troubleshoot broken installations. +==== + +[discrete] +[[endpoint-command-ref-options-18]] +=== Options + +`--uninstall-token `:: +Provide the uninstall token. The token is required if <> is enabled. + +[discrete] +[[endpoint-command-ref-example-19]] +=== Example + +[source] +---- +elastic-endpoint uninstall --uninstall-token 12345678901234567890123456789012 +---- + +[discrete] +[[endpoint-command-ref-elastic-endpoint-version]] +== elastic-endpoint version + +Show the version of {elastic-endpoint}. + +[discrete] +[[endpoint-command-ref-example-20]] +=== Example + +[source] +---- +elastic-endpoint version +---- diff --git a/docs/serverless/edr-manage/endpoint-event-capture.asciidoc b/docs/serverless/edr-manage/endpoint-event-capture.asciidoc new file mode 100644 index 0000000000..6fa3af2bf8 --- /dev/null +++ b/docs/serverless/edr-manage/endpoint-event-capture.asciidoc @@ -0,0 +1,59 @@ +[[endpoint-event-capture]] += Event capture and {elastic-defend} + +:description: Learn more about how {elastic-defend} collects event data. +:keywords: serverless, security, reference + +preview:[] + +{elastic-defend} collects select data on system activity in order to detect and prevent as many threats as possible, while balancing storage and performance overhead. To that end, {elastic-defend} isn't designed to capture all system events. Some event data that {elastic-defend} generates gets aggregated, truncated, or deduplicated as needed to optimize threat detection and prevention. + +You can supplement {elastic-defend}'s protection capabilities with {integrations-docs}[Elastic integrations] and tools that provide more visibility and historical data. Consult the following sections to expand data collection for specific types of system events. + +[discrete] +[[endpoint-event-capture-network-port-creation-and-deletion]] +== Network port creation and deletion + +{elastic-defend} tracks TCP connections. If a port is created but no traffic flows, no events are generated. + +For complete capture of network port creation and deletion, consider capturing Windows event ID 5158 using the {integrations-docs}/winlog[Custom Windows Event Logs] integration. + +[discrete] +[[endpoint-event-capture-network-inout-connections]] +== Network in/out connections + +{elastic-defend} tracks TCP connections, which don't include network in/out connections. + +For complete network capture, consider deploying {packetbeat} using the {integrations-docs}/network_traffic[Network Packet Capture] integration. + +[discrete] +[[endpoint-event-capture-user-behavior]] +== User behavior + +{elastic-defend} only captures user security events required by its behavioral protection. This doesn't include every user event such as logins and logouts, or every time a user account is created, deleted, or modified. + +For complete capture of all or specific Windows security events, consider the {integrations-docs}/winlog[Custom Windows Event Logs] integration. + +[discrete] +[[endpoint-event-capture-system-service-registration-deletion-and-modification]] +== System service registration, deletion, and modification + +{elastic-defend} only captures system service security events required by its behavioral protection engine. Service creation and modification can also be detected in registry activity, for which {elastic-defend} has internal rules such as https://github.com/elastic/protections-artifacts/blob/6d54ae289b290b1d42a7717569483f6ce907200a/behavior/rules/persistence_registry_or_file_modification_from_suspicious_memory.toml[Registry or File Modification from Suspicious Memory]. + +For complete capture of all or specific Windows security events, consider the {integrations-docs}/winlog[Custom Windows Event Logs] integration. In particular, capture events such as https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4697[Windows event ID 4697]. + +[discrete] +[[endpoint-event-capture-kernel-driver-registration-deletion-and-queries]] +== Kernel driver registration, deletion, and queries + +{elastic-defend} scans every driver as it is loaded, but it doesn't generate an event each time. + +Drivers are registered in the system as system services. You can capture this with Windows event ID 4697 using the {integrations-docs}/winlog[Custom Windows Event Logs] integration. + +Also consider capturing Windows event ID 6 using {winlogbeat}'s {winlogbeat-ref}/winlogbeat-module-sysmon.html[Sysmon module]. + +[discrete] +[[endpoint-event-capture-system-configuration-file-creation-modification-and-deletion]] +== System configuration file creation, modification, and deletion + +{elastic-defend} tracks creation, modification, and deletion of all files on the system. However, as mentioned above, the data might be aggregated, truncated, or deduplicated to provide only what's required for threat detection and prevention. diff --git a/docs/serverless/edr-manage/endpoint-self-protection.asciidoc b/docs/serverless/edr-manage/endpoint-self-protection.asciidoc new file mode 100644 index 0000000000..94883b372e --- /dev/null +++ b/docs/serverless/edr-manage/endpoint-self-protection.asciidoc @@ -0,0 +1,37 @@ +[[endpoint-self-protection]] += {elastic-endpoint} self-protection features + +:description: Learn how {elastic-endpoint} guards itself from tampering and attacks. +:keywords: serverless, security, overview + +preview:[] + +{elastic-endpoint}, the installed component that performs {elastic-defend}'s threat monitoring and prevention, protects itself against users and attackers that may try to interfere with its functionality. Protection features are consistently enhanced to prevent attackers who may attempt to use newer, more sophisticated tactics to interfere with the {elastic-endpoint}. Self-protection is enabled by default when {elastic-endpoint} installs on supported platforms, listed below. + +Self-protection is enabled on the following 64-bit Windows versions: + +* Windows 8.1 +* Windows 10 +* Windows 11 +* Windows Server 2012 R2 +* Windows Server 2016 +* Windows Server 2019 +* Windows Server 2022 + +Self-protection is also enabled on the following macOS versions: + +* macOS 10.15 (Catalina) +* macOS 11 (Big Sur) +* macOS 12 (Monterey) + +[NOTE] +==== +Other Windows and macOS variants (and all Linux distributions) do not have self-protection. +==== + +Self-protection defines the following permissions: + +* Users — even Administrator/root — **cannot** delete {elastic-endpoint} files (located at `c:\Program Files\Elastic\Endpoint` on Windows, and `/Library/Elastic/Endpoint` on macOS). +* Users **cannot** terminate the {elastic-endpoint} program or service. +* Administrator/root users **can** read {elastic-endpoint}'s files. On Windows, the easiest way to read {elastic-endpoint} files is to start an Administrator `cmd.exe` prompt. On macOS, an Administrator can use the `sudo` command. +* Administrator/root users **can** stop the {elastic-agent}'s service. On Windows, run the `sc stop "Elastic Agent"` command. On macOS, run the `sudo launchctl stop elastic-agent` command. diff --git a/docs/serverless/edr-manage/endpoints-page.asciidoc b/docs/serverless/edr-manage/endpoints-page.asciidoc new file mode 100644 index 0000000000..2d3b7c836d --- /dev/null +++ b/docs/serverless/edr-manage/endpoints-page.asciidoc @@ -0,0 +1,140 @@ +[[endpoints-page]] += Endpoints + +:keywords: serverless, security, overview + +preview:[] + +The **Endpoints** page (**Assets** → **Endpoints**) allows administrators to view and manage endpoints that are running the <>. + +.Requirements +[NOTE] +==== +* {fleet} must be enabled for administrative actions to function correctly. +* You must have the appropriate user role to use this feature. + +// Placeholder statement until we know which specific roles are required. Classic statement below for reference. + +// * You must have the **Endpoint List** privilege to access this feature. +==== + +[discrete] +[[endpoints-list-ov]] +== Endpoints list + +The **Endpoints** list displays all hosts running {elastic-defend} and their relevant integration details. Endpoints appear in chronological order, with newly added endpoints at the top. + +[role="screenshot"] +image::images/endpoints-page/-management-admin-endpoints-pg.png[Endpoints page] + +The Endpoints list provides the following data: + +* **Endpoint**: The system hostname. Click the link to display <> in a flyout. +* **Agent Status**: The current status of the {agent}, which is one of the following: ++ +** `Healthy`: The agent is online and communicating with {elastic-sec}. +** `Unenrolling`: The agent is currently unenrolling and will soon be removed from Fleet. Afterward, the endpoint will also uninstall. +** `Unhealthy`: The agent is online but requires attention from an administrator because it's reporting a problem with a process. An unhealthy status could mean an upgrade failed and was rolled back to its previous version, or an integration might be missing prerequisites or additional configuration. Refer to <> for more on resolving an unhealthy agent status. +** `Updating`: The agent is online and is updating the agent policy or binary, or is enrolling or unenrolling. +** `Offline`: The agent is still enrolled but may be on a machine that is shut down or currently does not have internet access. In this state, the agent is no longer communicating with {elastic-sec} at a regular interval. ++ +[NOTE] +==== +{agent} statuses in {fleet} correspond to the agent statuses in the {security-app}. +==== +* **Policy:** The name of the associated integration policy when the agent was installed. Click the link to display the <> page. +* **Policy status:** Indicates whether the integration policy was successfully applied. Click the link to view <> response details in a flyout. +* **OS**: The host's operating system. +* **IP address**: All IP addresses associated with the hostname. +* **Version**: The {agent} version currently running. +* **Last active**: A date and timestamp of the last time the {agent} was active. +* **Actions**: Select the context menu (_..._) to do the following: ++ +** **Isolate host**: <> from your network, blocking communication until the host is released. +** **Respond**: Open the <> to perform response actions directly on the host. +** **View response actions history**: View a <> performed on the host. +** **View host details**: View host details on the **Hosts** page in the {security-app}. +** **View agent policy**: View the agent policy in {fleet}. +** **View agent details**: View {agent} details and activity logs in {fleet}. +** **Reassign agent policy**: Change the {fleet-guide}/agent-policy.html#apply-a-policy[agent policy] assigned to the host in {fleet}. + +[discrete] +[[endpoint-details]] +=== Endpoint details + +Click any link in the **Endpoint** column to display host details in a flyout. You can also use the **Take Action** menu button to perform the same actions as those listed in the Actions context menu, such as isolating the host, viewing host details, and viewing or reassigning the agent policy. + +[role="screenshot"] +image::images/endpoints-page/-management-admin-host-flyout.png[Endpoint details flyout] + +[discrete] +[[response-action-history-tab]] +=== Response actions history + +The endpoint details flyout also includes the **Response actions history** tab, which provides a log of the <> performed on the endpoint, such as isolating a host or terminating a process. You can use the tools at the top to filter the information displayed in this view. Refer to <> for more details. + +[role="screenshot"] +image::images/endpoints-page/-management-admin-response-actions-history-endpoint-details.png[Response actions history with a few past actions] + +[discrete] +[[integration-policy-details]] +=== Integration policy details + +To view the integration policy page, click the link in the **Policy** column. If you are viewing host details, you can also click the **Policy** link on the flyout. + +On this page, you can view and configure endpoint protection and event collection settings. In the upper-right corner are Key Performance Indicators (KPIs) that provide current endpoint status. If you need to update the policy, make changes as appropriate, then click the **Save** button to apply the new changes. + +[NOTE] +==== +Users must have permission to read/write to {fleet} APIs to make changes to the configuration. +==== + +[role="screenshot"] +image::images/endpoints-page/-management-admin-integration-pg.png[Integration page] + +Users who have unique configuration and security requirements can select **Show advanced settings** to configure the policy to support advanced use cases. Hover over each setting to view its description. + +[NOTE] +==== +Advanced settings are not recommended for most users. +==== + +[role="screenshot"] +image::images/endpoints-page/-management-admin-integration-advanced-settings.png[Integration page] + +[discrete] +[[policy-status]] +=== Policy status + +The status of the integration policy appears in the **Policy status** column and displays one of the following: + +* `Success`: The policy was applied successfully. +* `Warning` or `Partially Applied`: The policy is pending application, or the policy was not applied in its entirety. ++ +[NOTE] +==== +In some cases, actions taken on the endpoint may fail during policy application, but these cases are not critical failures - meaning there may be a failure, but the endpoints are still protected. In this case, the policy status will display as "Partially Applied." +==== +* `Failure`: The policy did not apply correctly, and endpoints are not protected. +* `Unknown`: The user interface is waiting for the API response to return, or, in rare cases, the API returned an undefined error or value. + +For more details on what's causing a policy status, click the link in the **Policy status** column and review the details flyout. Expand each section and subsection to display individual responses from the agent. + +[TIP] +==== +If you need help troubleshooting a configuration failure, refer to <> and {fleet-guide}/fleet-troubleshooting.html[{fleet} troubleshooting]. +==== + +[role="screenshot"] +image::images/endpoints-page/-management-admin-config-status.png[Config status details] + +[discrete] +[[endpoints-page-filter-endpoints]] +=== Filter endpoints + +To filter the Endpoints list, use the search bar to enter a query using **{kibana-ref}/kuery-query.html[{kib} Query Language (KQL)]**. To refresh the search results, click **Refresh**. + +[NOTE] +==== +The date and time picker on the right side of the page allows you to set a time interval to automatically refresh the Endpoints list — for example, to check if new endpoints were added or deleted. +==== diff --git a/docs/serverless/edr-manage/event-filters.asciidoc b/docs/serverless/edr-manage/event-filters.asciidoc new file mode 100644 index 0000000000..12a09cfe51 --- /dev/null +++ b/docs/serverless/edr-manage/event-filters.asciidoc @@ -0,0 +1,121 @@ +[[event-filters]] += Event filters + +:keywords: serverless, security, how-to + +preview:[] + +Event filters (**Assets** → **Event filters**) allow you to filter out endpoint events that you don't want stored in {es} — for example, high-volume events. By creating event filters, you can optimize your storage in {es}. + +Event filters do not lower CPU usage on hosts; {elastic-endpoint} still monitors events to detect and prevent possible threats, but without writing event data to {es}. To compare event filters with other endpoint artifacts, refer to <>. + +.Requirements +[NOTE] +==== +You must have the appropriate user role to use this feature. + +// Placeholder statement until we know which specific roles are required. Classic statement below for reference. + +// You must have the **Event Filters** privilege to access this feature. +==== + +[IMPORTANT] +==== +Since an event filter blocks an event from streaming to {es}, be conscious of event filter conditions you set and any existing rule conditions. If there is too much overlap, the rule may run less frequently than specified and, therefore, will not trigger the corresponding alert for that rule. This is the expected behavior of event filters. +==== + +By default, event filters are recognized globally across all hosts running {elastic-defend}. You can also assign an event filter to a specific {elastic-defend} integration policy, which would filter endpoint events from the hosts assigned to that policy. + +Create event filters from the Hosts page or the Event filters page. + +. Do one of the following: ++ +** To create an event filter from the Hosts page: ++ +... Go to **Explore** → **Hosts**. +... Select the **Events** tab to view the Events table. +... Find the event to filter, click the **More actions** menu (image:images/icons/boxesHorizontal.svg[More actions menu icon]), then select **Add Endpoint event filter**. ++ +[TIP] +==== +Since you can only create filters for endpoint events, be sure to filter the Events table to display events generated by the {elastic-endpoint}. +For example, in the KQL search bar, enter the following query to find endpoint network events: `event.dataset : endpoint.events.network`. +==== +** To create an event filter from the Event filters page: ++ +... Go to **Assets** → **Event filters**. +... Click **Add event filter**. The **Add event filter** flyout opens. ++ +[role="screenshot"] +image::images/event-filters/-management-admin-event-filter.png[] +. Fill in these fields in the **Details** section: ++ +.. `Name`: Enter a name for the event filter. +.. `Description`: Enter a filter description (optional). +. In the **Conditions** section, depending which page you're using to create the filter, either modify the pre-populated conditions or add new conditions to define how {elastic-sec} will filter events. Use these settings: ++ +.. `Select operating system`: Select the appropriate operating system. +.. Select which kind of event filter you'd like to create: ++ +*** `Events`: Create a generic event filter that can match any event type. All matching events are excluded. +*** `Process Descendants`: Specify a process, and suppress the activity of its descendant processes. Events from the matched process will be ingested, but events from its descendant processes will be excluded. ++ +This option adds the condition `event.category is process` to narrow the filter to process-type events. You can add more conditions to identify the process whose descendants you want to exclude. +.. `Field`: Select a field to identify the event being filtered. +.. `Operator`: Select an operator to define the condition. Available options are: ++ +*** `is` +*** `is not` +*** `is one of` +*** `is not one of` +*** `matches` | `does not match`: Allows you to use wildcards in `Value`, such as `C:\path*\app.exe`. Available wildcards are `?` (match one character) and `*` (match zero or more characters). ++ +[IMPORTANT] +==== +Using wildcards in file paths can impact performance. To create a more efficient event filter using wildcards, use multiple conditions and make them as specific as possible. For example, adding conditions using `process.name` or `file.name` can help limit the scope of wildcard matching. +==== +.. `Value`: Enter the value associated with the `Field`. To enter multiple values (when using `is one of` or `is not one of`), enter each value, then press **Return**. +. To define multiple conditions, click the `AND` button and configure a new condition. You can also add nested conditions with the `Add nested condition` button. For example, the event filter pictured above excludes events whose `event.category` field is `network`, and whose `process.executable` field is as specified. +. Select an option in the **Assignment** section to assign the event filter to a specific integration policy: ++ +** `Global`: Assign the event filter to all integration policies for {elastic-defend}. +** `Per Policy`: Assign the event filter to one or more specific {elastic-defend} integration policies. Select each policy in which you want the events to be filtered. ++ +[NOTE] +==== +You can also select the `Per Policy` option without immediately assigning a policy to the event filter. For example, you could do this to create and review your event filter configurations before putting them into action with a policy. +==== +. Add a comment if you want to provide more information about the event filter (optional). +. Click **Add event filter**. The new filter is added to the **Event filters** list. + +[discrete] +[[manage-event-filters]] +== View and manage event filters + +The **Event filters** page (**Assets** → **Event filters**) displays all the event filters that have been added to the {security-app}. To refine the list, use the search bar to search by filter name, description, comments, or field value. + +[role="screenshot"] +image::images/event-filters/-management-admin-event-filters-list.png[] + +[discrete] +[[edit-event-filter]] +=== Edit an event filter + +You can individually modify each event filter. You can also change the policies that an event filter is assigned to. + +To edit an event filter: + +. Click the actions menu (image:images/icons/boxesHorizontal.svg[Actions menu icon]) for the event filter you want to edit, then select **Edit event filter**. +. Modify details or conditions as needed. +. Click **Save**. + +[discrete] +[[delete-event-filter]] +=== Delete an event filter + +You can delete an event filter, which removes it entirely from all {elastic-defend} integration policies. + +To delete an event filter: + +. Click the actions menu (image:images/icons/boxesHorizontal.svg[Actions menu icon]) on the event filter you want to delete, then select **Delete event filter**. +. On the dialog that opens, verify that you are removing the correct event filter, then click **Delete**. A confirmation message is displayed. diff --git a/docs/serverless/edr-manage/host-isolation-exceptions.asciidoc b/docs/serverless/edr-manage/host-isolation-exceptions.asciidoc new file mode 100644 index 0000000000..bcfaec6af1 --- /dev/null +++ b/docs/serverless/edr-manage/host-isolation-exceptions.asciidoc @@ -0,0 +1,78 @@ +[[host-isolation-exceptions]] += Host isolation exceptions + +:keywords: serverless, security, how-to + +preview:[] + +You can configure host isolation exceptions (**Assets** → **Host isolation exceptions**) for specific IP addresses that <> are still allowed to communicate with, even when blocked from the rest of your network. Isolated hosts can still send data to {elastic-sec}, so you don't need to set up host isolation exceptions for them. + +Host isolation exceptions support IPv4 addresses, with optional classless inter-domain routing (CIDR) notation. + +.Requirements +[NOTE] +==== +You must have the appropriate user role to use this feature. + +// Placeholder statement until we know which specific roles are required. Classic statement below for reference. + +// You must have the **Host Isolation Exceptions** privilege to access this feature. +==== + +[IMPORTANT] +==== +* Each host isolation exception IP address should be a highly trusted and secure location since you're allowing it to communicate with hosts that have been isolated to prevent a potential threat from spreading. +* If your hosts depend on VPNs for network communication, you should also set up host isolation exceptions for those VPN servers' IP addresses. +==== + +Host isolation requires the Endpoint Protection Complete https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature]. By default, a host isolation exception is recognized globally across all hosts running {elastic-defend}. You can also assign a host isolation exception to a specific {elastic-defend} integration policy, affecting only the hosts assigned to that policy. + +. Go to **Assets** → **Host isolation exceptions**. +. Click **Add Host isolation exception**. +. Fill in these fields in the **Add Host isolation exception** flyout: ++ +.. `Name your host isolation exceptions`: Enter a name to identify the host isolation exception. +.. `Description`: Enter a description to provide more information on the host isolation exception (optional). +.. `Enter IP Address`: Enter the IP address for which you want to allow communication with an isolated host. This must be an IPv4 address, with optional CIDR notation (for example, `0.0.0.0` or `1.0.0.0/24`, respectively). +. Select an option in the **Assignment** section to assign the host isolation exception to a specific integration policy: ++ +** `Global`: Assign the host isolation exception to all integration policies for {elastic-defend}. +** `Per Policy`: Assign the host isolation exception to one or more specific {elastic-defend} integration policies. Select each policy where you want the host isolation exception to apply. ++ +[NOTE] +==== +You can also select the `Per Policy` option without immediately assigning a policy to the host isolation exception. For example, you could do this to create and review your host isolation exception configurations before putting them into action with a policy. +==== +. Click **Add Host isolation exception**. The new exception is added to the **Host isolation exceptions** list. + +[discrete] +[[manage-host-isolation-exceptions]] +== View and manage host isolation exceptions + +The **Host isolation exceptions** page displays all the host isolation exceptions that have been configured for {elastic-sec}. To refine the list, use the search bar to search by name, description, or IP address. + +[role="screenshot"] +image::images/host-isolation-exceptions/-management-admin-host-isolation-exceptions-ui.png[List of host isolation exceptions] + +[discrete] +[[edit-host-isolation-exception]] +=== Edit a host isolation exception + +You can individually modify each host isolation exception and change the policies that a host isolation exception is assigned to. + +To edit a host isolation exception: + +. Click the actions menu (image:images/icons/boxesHorizontal.svg[Actions menu icon]) for the exception you want to edit, then select **Edit Exception**. +. Modify details as needed. +. Click **Save**. The newly modified exception appears at the top of the list. + +[discrete] +[[delete-host-isolation-exception]] +=== Delete a host isolation exception + +You can delete a host isolation exception, which removes it entirely from all {elastic-defend} integration policies. + +To delete a host isolation exception: + +. Click the actions menu (image:images/icons/boxesHorizontal.svg[Actions menu icon]) on the exception you want to delete, then select **Delete Exception**. +. On the dialog that opens, verify that you are removing the correct host isolation exception, then click **Delete**. A confirmation message is displayed. diff --git a/docs/serverless/edr-manage/manage-endpoint-protection.asciidoc b/docs/serverless/edr-manage/manage-endpoint-protection.asciidoc new file mode 100644 index 0000000000..c1e7306ed6 --- /dev/null +++ b/docs/serverless/edr-manage/manage-endpoint-protection.asciidoc @@ -0,0 +1,9 @@ +[[manage-endpoint-protection]] += Manage {elastic-defend} + +:description: Manage endpoint protection artifacts for {elastic-defend}. +:keywords: serverless, security, overview + +preview:[] + +This section provides an overview of the management tools on the **Assets** page that administrators can use to manage endpoints, integration policies, trusted applications, event filters, host isolation exceptions, and blocked applications. diff --git a/docs/serverless/edr-manage/optimize-edr.asciidoc b/docs/serverless/edr-manage/optimize-edr.asciidoc new file mode 100644 index 0000000000..2f67d5e137 --- /dev/null +++ b/docs/serverless/edr-manage/optimize-edr.asciidoc @@ -0,0 +1,40 @@ +[[optimize-edr]] += Optimize {elastic-defend} + +:keywords: serverless, security, how-to + +preview:[] + +If you encounter problems like incompatibilities with other antivirus software, too many false positive alerts, or excessive storage or CPU usage, you can optimize {elastic-defend} to mitigate these issues. + +Endpoint artifacts — such as trusted applications and event filters — and Endpoint exceptions let you modify the behavior and performance of _{elastic-endpoint}_, the component installed on each host that performs {elastic-defend}'s threat monitoring, prevention, and response actions. + +The following table explains the differences between several Endpoint artifacts and exceptions, and how to use them: + +|=== +| | + +| <> +a| **_Prevents {elastic-endpoint} from monitoring a process._** Use to avoid conflicts with other software, usually other antivirus or endpoint security applications. + +* Creates intentional blind spots in your security environment — use sparingly! +* Doesn't monitor the application for threats, nor does it generate alerts, even if it behaves like malware, ransomware, etc. +* Doesn't generate events for the application except process events for visualizations and other internal use by the {stack}. +* Might improve performance, since {elastic-endpoint} monitors fewer processes. +* Might still generate malicious behavior alerts, if the application's process events indicate malicious behavior. To suppress alerts, create <>. + +| <> +a| **_Prevents event documents from being written to {es}._** Use to reduce storage usage in {es}. + +Does NOT lower CPU usage for {elastic-endpoint}. It still monitors event data for possible threats, but without writing event data to {es}. + +| <> +a| **_Prevents known malware from running._** Use to extend {elastic-defend}'s protection against malicious processes. + +NOT intended to broadly block benign applications for non-security reasons. + +| <> +a| **_Prevents {elastic-endpoint} from generating alerts or stopping processes._** Use to reduce false positive alerts, and to keep {elastic-endpoint} from preventing processes you want to allow. + +Might also improve performance: {elastic-endpoint} checks for exceptions _before_ most other processing, and stops monitoring a process if an exception allows it. +|=== diff --git a/docs/serverless/edr-manage/policies-page-ov.asciidoc b/docs/serverless/edr-manage/policies-page-ov.asciidoc new file mode 100644 index 0000000000..8864293412 --- /dev/null +++ b/docs/serverless/edr-manage/policies-page-ov.asciidoc @@ -0,0 +1,23 @@ +[[policies-page]] += Policies + +:keywords: serverless, security, reference + +preview:[] + +The **Policies** page (**Assets** → **Policies**) lists all of the integration policies configured for {elastic-defend}. + +.Requirements +[NOTE] +==== +You must have the appropriate user role to use this feature. + +// Placeholder statement until we know which specific roles are required. Classic statement below for reference. + +// You must have the **{elastic-defend} Policy Management** privilege to access this feature. +==== + +Click on an integration policy's name to configure its settings. For more information on configuring an integration policy, refer to <>. + +[role="screenshot"] +image::images/policies-page-ov/-management-admin-policy-list.png[] diff --git a/docs/serverless/edr-manage/trusted-apps-ov.asciidoc b/docs/serverless/edr-manage/trusted-apps-ov.asciidoc new file mode 100644 index 0000000000..ff26aa561f --- /dev/null +++ b/docs/serverless/edr-manage/trusted-apps-ov.asciidoc @@ -0,0 +1,103 @@ +[[trusted-applications]] += Trusted applications + +:keywords: serverless, security, how-to + +preview:[] + +[NOTE] +==== +If you use {elastic-defend} along with other antivirus (AV) software, you might need to configure the other system to trust {elastic-endpoint}. Refer to <> for more information. +==== + +On the **Trusted applications** page (**Assets** → **Trusted applications**), you can add Windows, macOS, and Linux applications that should be trusted, such as other antivirus or endpoint security applications. Trusted applications are designed to help mitigate performance issues and incompatibilities with other endpoint software installed on your hosts. Trusted applications apply only to hosts running the {elastic-defend} integration. + +.Requirements +[NOTE] +==== +You must have the appropriate user role to use this feature. + +// Placeholder statement until we know which specific roles are required. Classic statement below for reference. + +// You must have the **Trusted Applications** privilege to access this feature. +==== + +Trusted applications create blindspots for {elastic-defend}, because the applications are no longer monitored for threats. One avenue attackers use to exploit these blindspots is by DLL (Dynamic Link Library) side-loading, where they leverage processes signed by trusted vendors — such as antivirus software — to execute their malicious DLLs. Such activity appears to originate from the trusted application's process. + +Trusted applications might still generate alerts in some cases, such as if the application's process events indicate malicious behavior. To reduce false positive alerts, add an <>, which prevents {elastic-defend} from generating alerts. To compare trusted applications with other endpoint artifacts, refer to <>. + +Additionally, trusted applications still generate process events for visualizations and other internal use by the {stack}. To prevent process events from being written to {es}, use an <> to filter out the specific events that you don't want stored in {es}, but be aware that features that depend on these process events may not function correctly. + +By default, a trusted application is recognized globally across all hosts running {elastic-defend}. You can also assign a trusted application to a specific {elastic-defend} integration policy, enabling the application to be trusted by only the hosts assigned to that policy. + +To add a trusted application: + +. Go to **Manage** → **Trusted applications**. +. Click **Add trusted application**. +. Fill in the following fields in the **Add trusted application** flyout: ++ +** `Name your trusted application`: Enter a name for the trusted application. +** `Description`(Optional): Enter a description for the trusted application. +** `Select operating system`: Select the appropriate operating system from the drop-down. +** `Field`: Select a field to identify the trusted application: ++ +*** `Hash`: The MD5, SHA-1, or SHA-256 hash value of the application's executable. +*** `Path`: The full file path of the application's executable. +*** `Signature`: (Windows only) The name of the application's digital signer. ++ +[TIP] +==== +To find the signer's name for an application, go to **Discover** and query the process name of the application's executable (for example, `process.name : "mctray.exe"` for a McAfee security binary). Then, search the results for the `process.code_signature.subject_name` field, which contains the signer's name (for example, `McAfee, Inc.`). +==== +** `Operator`: Select an operator to define the condition: ++ +*** `is`: Must be _exactly_ equal to `Value`; wildcards are not supported. This operation is required for the `Hash` and `Signature` field types. +*** `matches`: Can include wildcards in `Value`, such as `C:\path*\app.exe`. This operator is only available for the `Path` field type. Available wildcards are `?` (match one character) and `*` (match zero or more characters). +** `Value`: Enter the hash value, file path, or signer name. To add an additional value, click **AND**. ++ +[NOTE] +==== +You can only add a single field type value per trusted application. For example, if you try to add two `Path` values, you'll get an error message. Also, an application's hash value must be valid to add it as a trusted application. In addition, to minimize visibility gaps in the {security-app}, be as specific as possible in your entries. For example, combine `Signature` information with a known `Path`. +==== +. Select an option in the **Assignment** section to assign the trusted application to a specific integration policy: ++ +** `Global`: Assign the trusted application to all integration policies for {elastic-defend}. +** `Per Policy`: Assign the trusted application to one or more specific {elastic-defend} integration policies. Select each policy in which you want the application to be trusted. ++ +[NOTE] +==== +You can also select the `Per Policy` option without immediately assigning a policy to the trusted application. For example, you could do this to create and review your trusted application configurations before putting them into action with a policy. +==== +. Click **Add trusted application**. The application is added to the **Trusted applications** list. + +[discrete] +[[trusted-apps-list]] +== View and manage trusted applications + +The **Trusted applications** page (**Assets** → **Trusted applications**) displays all the trusted applications that have been added to the {security-app}. To refine the list, use the search bar to search by name, description, or field value. + +[role="screenshot"] +image::images/trusted-apps-ov/-management-admin-trusted-apps-list.png[] + +[discrete] +[[edit-trusted-app]] +=== Edit a trusted application + +You can individually modify each trusted application. You can also change the policies that a trusted application is assigned to. + +To edit a trusted application: + +. Click the actions menu (_..._) on the trusted application you want to edit, then select **Edit trusted application**. +. Modify details as needed. +. Click **Save**. + +[discrete] +[[delete-trusted-app]] +=== Delete a trusted application + +You can delete a trusted application, which removes it entirely from all {elastic-defend} integration policies. + +To delete a trusted application: + +. Click the actions menu (_..._) on the trusted application you want to delete, then select **Delete trusted application**. +. On the dialog that opens, verify that you are removing the correct application, then click **Delete**. A confirmation message is displayed. diff --git a/docs/serverless/endpoint-response-actions/automated-response-actions.asciidoc b/docs/serverless/endpoint-response-actions/automated-response-actions.asciidoc new file mode 100644 index 0000000000..973d06e3b6 --- /dev/null +++ b/docs/serverless/endpoint-response-actions/automated-response-actions.asciidoc @@ -0,0 +1,41 @@ +[[automated-response-actions]] += Automated response actions + +:description: Automatically respond to events with endpoint response actions triggered by detection rules. +:keywords: serverless, security, defend, how-to, manage + +preview:[] + +Add {elastic-defend}'s <> to detection rules to automatically perform actions on an affected host when an event meets the rule's criteria. Use these actions to support your response to detected threats and suspicious events. + +.Requirements +[NOTE] +==== +* Automated response actions require the Endpoint Protection Complete https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature]. +* Hosts must have {agent} installed with the {elastic-defend} integration. +* Your user role must have the ability to create detection rules and the privilege to perform <> (for example, custom roles require the **Host Isolation** privilege to isolate hosts). +* You can only add automated response actions to <>, <>, <>, and <> type rules. +==== + +To add automated response actions to a new or existing rule: + +. Do one of the following: ++ +** **New rule**: On the last step of rule creation, go to the **Response Actions** section and select **{elastic-defend}**. +** **Existing rule**: Edit the rule's settings, then go to the **Actions** tab. In the tab, select **{elastic-defend}** under the **Response Actions** section. +. Select an option in the **Response action** field: ++ +** **Isolate**: <>, blocking communication with other hosts on the network. +** **Kill process**: Terminate a process on the host. +** **Suspend process**: Temporarily suspend a process on the host. ++ +[IMPORTANT] +==== +Be aware that automatic host isolation can result in unintended consequences, such as disrupting legitimate user activities or blocking critical business processes. +==== +. For process actions, specify how to identify the process you want to terminate or suspend: ++ +** Turn on the toggle to use the alert's **process.pid** value as the identifier. +** To use a different alert field value to identify the process, turn off the toggle and enter the **Custom field name**. +. Enter a comment describing why you’re performing the action on the host (optional). +. To finish adding the response action, click **Create & enable rule** (for a new rule) or **Save changes** (for existing rules). diff --git a/docs/serverless/endpoint-response-actions/host-isolation-ov.asciidoc b/docs/serverless/endpoint-response-actions/host-isolation-ov.asciidoc new file mode 100644 index 0000000000..e07619b6ce --- /dev/null +++ b/docs/serverless/endpoint-response-actions/host-isolation-ov.asciidoc @@ -0,0 +1,166 @@ +[[isolate-host]] += Isolate a host + +:description: Host isolation allows you to cut off a host's network access until you release it. +:keywords: serverless, security, defend, how-to, manage + +preview:[] + +Host isolation allows you to isolate hosts from your network, blocking communication with other hosts on your network until you release the host. Isolating a host is useful for responding to malicious activity or preventing potential attacks, as it prevents lateral movement across other hosts. + +Isolated hosts, however, can still send data to {elastic-sec}. You can also create <> for specific IP addresses that isolated hosts are still allowed to communicate with, even when blocked from the rest of your network. + +.Requirements +[NOTE] +==== +* Host isolation requires the Endpoint Protection Complete https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature]. +* Hosts must have {agent} installed with the {elastic-defend} integration. +* Host isolation is supported for endpoints running Windows, macOS, and these Linux distributions: ++ +** CentOS/RHEL 8 +** Debian 11 +** Ubuntu 18.04, 20.04, and 22.04 +** AWS Linux 2 +* To isolate and release hosts running any operating system, you must have the appropriate user role. +==== + +[role="screenshot"] +image::images/host-isolation-ov/-management-admin-isolated-host.png[Endpoint page highlighting a host that's been isolated] + +You can isolate a host from a detection alert's details flyout, from the Endpoints page, or from the endpoint response console. Once a host is successfully isolated, an `Isolated` status displays next to the `Agent status` field, which you can view on the alert details flyout or Endpoints list table. + +[TIP] +==== +If the request fails, verify that the {agent} and your endpoint are both online before trying again. +==== + +All actions executed on a host are tracked in the host’s response actions history, which you can access from the Endpoints page. Refer to <> for more information. + +[discrete] +[[isolate-a-host]] +== Isolate a host + +.Isolate a host from a detection alert +[%collapsible] +===== +. Open a detection alert: + +* From the Alerts table or Timeline: Click **View details** (image:images/icons/expand.svg[View details]). +* From a case with an attached alert: Click **Show alert details** (**>**). + +. Click **Take action → Isolate host**. +. Enter a comment describing why you’re isolating the host (optional). +. Click **Confirm**. +===== + +.Isolate a host from an endpoint +[%collapsible] +===== +. Go to **Assets → Endpoints**, then either: ++ +** Select the appropriate endpoint in the **Endpoint** column, and click **Take action → Isolate host** in the endpoint details flyout. +** Click the **Actions** menu (_..._) on the appropriate endpoint, then select **Isolate host**. +. Enter a comment describing why you’re isolating the host (optional). +. Click **Confirm**. +===== + +.Isolate a host from the response console +[%collapsible] +===== +[NOTE] +==== +The response console requires the Endpoint Protection Complete https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature]. +==== + +. Open the response console for the host (select the **Respond** button or actions menu option on the host, endpoint, or alert details view). +. Enter the `isolate` command and an optional comment in the input area, for example: ++ +`isolate --comment "Isolate this host"` +. Press **Return**. +===== + +.Automatically isolate a host using a rule's endpoint response action +[%collapsible] +===== +[NOTE] +==== +The host isolation endpoint response action requires the Endpoint Protection Complete https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature]. +==== + +[IMPORTANT] +==== +Be aware that automatic host isolation can result in unintended consequences, such as disrupting legitimate user activities or blocking critical business processes. +==== + +. Add an endpoint response action to a new or existing custom query rule. The endpoint response action will run whenever rule conditions are met: ++ +** **New rule**: On the last step of <> creation, go to the **Response Actions** section and select **{elastic-defend}**. +** **Existing rule**: Edit the rule's settings, then go to the **Actions** tab. In the tab, select **{elastic-defend}** under the **Response Actions** section. +. Click the **Response action** field, then select **Isolate**. +. Enter a comment describing why you’re isolating the host (optional). +. To finish adding the response action, click **Create & enable rule** (for a new rule) or **Save changes** (for existing rules). +===== + +After the host is successfully isolated, an **Isolated** status is added to the endpoint. Active end users receive a notification that the computer has been isolated from the network: + +[role="screenshot"] +image::images/host-isolation-ov/-management-admin-host-isolated-notif.png[Host isolated notification message] + +[discrete] +[[release-a-host]] +== Release a host + +.Release a host from a detection alert +[%collapsible] +===== +. Open a detection alert: + +* From the Alerts table or Timeline: Click **View details** (image:images/icons/expand.svg[View details]). +* From a case with an attached alert: Click **Show alert details** (**>**). + +. From the alert details flyout, click **Take action → Release host**. +. Enter a comment describing why you're releasing the host (optional). +. Click **Confirm**. +===== + +.Release a host from an endpoint +[%collapsible] +===== +. Go to **Assets → Endpoints**, then either: ++ +** Select the appropriate endpoint in the **Endpoint** column, and click **Take action → Release host** in the endpoint details flyout. +** Click the **Actions** menu (_..._) on the appropriate endpoint, then select **Release host**. +. Enter a comment describing why you're releasing the host (optional). +. Click **Confirm**. +===== + +.Release a host from the response console +[%collapsible] +===== +[NOTE] +==== +The response console requires the Endpoint Protection Complete https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature]. +==== + +. Open the response console for the host (select the **Respond** button or actions menu option on the host, endpoint, or alert details view). +. Enter the `release` command and an optional comment in the input area, for example: ++ +`release --comment "Release this host"` +. Press **Return**. +===== + +After the host is successfully released, the **Isolated** status is removed from the endpoint. Active end users receive a notification that the computer has been reconnected to the network: + +[role="screenshot"] +image::images/host-isolation-ov/-management-admin-host-released-notif.png[Host released notification message] + +[discrete] +[[view-host-isolation-details]] +== View host isolation history + +To confirm if a host has been successfully isolated or released, check the response actions history, which logs the response actions performed on a host. + +Go to **Assets** → **Endpoints**, click an endpoint's name, then click the **Response action history** tab. You can filter the information displayed in this view. Refer to <> for more details. + +[role="screenshot"] +image::images/host-isolation-ov/-management-admin-response-actions-history-endpoint-details.png[Response actions history page UI] diff --git a/docs/serverless/endpoint-response-actions/response-actions-config.asciidoc b/docs/serverless/endpoint-response-actions/response-actions-config.asciidoc new file mode 100644 index 0000000000..220a3724dd --- /dev/null +++ b/docs/serverless/endpoint-response-actions/response-actions-config.asciidoc @@ -0,0 +1,159 @@ +[[response-actions-config]] += Configure third-party response actions + +:description: Configure {elastic-sec} to perform response actions on hosts protected by third-party systems. +:keywords: serverless, security, how-to, configure + +preview:[] + +preview::[] + +You can direct third-party endpoint protection systems to perform response actions on enrolled hosts, such as isolating a suspicious endpoint from your network, without leaving the {elastic-sec} UI. This page explains the configuration steps needed to enable response actions for these third-party systems: + +* CrowdStrike +* SentinelOne + +Check out <> to learn which response actions are supported for each system. + +.Prerequisites +[NOTE] +==== +* https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[Project features add-on]: Endpoint Protection Complete +* https://www.elastic.co/docs/current/serverless/general/assign-user-roles[User roles]: **SOC manager** or **Endpoint operations analyst** +* Endpoints must have actively running third-party agents installed. +==== + +Select a tab below for your endpoint security system: + +++++ +
+
+ + +
+
+++++ +//// +/* NOTE TO CONTRIBUTORS: These DocTabs have very similar content. If you change anything + in this tab, apply the change to the other tabs, too. */ +//// + +To configure response actions for CrowdStrike-enrolled hosts: + +. **Enable API access in CrowdStrike.** Create an API client in CrowdStrike to allow access to the system. Refer to CrowdStrike's docs for instructions. ++ +** Give the API client the minimum privilege required to read CrowdStrike data and perform actions on enrolled hosts. Consider creating separate API clients for reading data and performing actions, to limit privileges allowed by each API client. +** Take note of the client ID, client secret, and base URL; you'll need them in later steps when you configure {elastic-sec} components to access CrowdStrike. +. **Install the CrowdStrike integration and {agent}.** Elastic's {integrations-docs}/crowdstrike[CrowdStrike integration] collects and ingests logs into {elastic-sec}. ++ +.. Go to **Project Settings** → **Integrations**, search for and select **CrowdStrike**, then select **Add CrowdStrike**. +.. Configure the integration with an **Integration name** and optional **Description**. +.. Select **Collect CrowdStrike logs via API**, and enter the required **Settings**: ++ +*** **Client ID**: Client ID for the API client used to read CrowdStrike data. +*** **Client Secret**: Client secret allowing you access to CrowdStrike. +*** **URL**: The base URL of the CrowdStrike API. +.. Select the **Falcon Alerts** and **Hosts** sub-options under **Collect CrowdStrike logs via API**. +.. Scroll down and enter a name for the agent policy in **New agent policy name**. If other agent policies already exist, you can click the **Existing hosts** tab and select an existing policy instead. For more details on {agent} configuration settings, refer to {fleet-guide}/agent-policy.html[{agent} policies]. +.. Click **Save and continue**. +.. Select **Add {agent} to your hosts** and continue with the <> to install {agent} on a resource in your network (such as a server or VM). {agent} will act as a bridge collecting data from CrowdStrike and sending it back to {elastic-sec}. +. **Create a CrowdStrike connector.** Elastic's {kibana-ref}/crowdstrike-action-type.html[CrowdStrike connector] enables {elastic-sec} to perform actions on CrowdStrike-enrolled hosts. ++ +[IMPORTANT] +==== +Do not create more than one CrowdStrike connector. +==== ++ +.. Go to **Stack Management** → **Connectors**, then select **Create connector**. +.. Select the **CrowdStrike** connector. +.. Enter the configuration information: ++ +*** **Connector name**: A name to identify the connector. +*** **CrowdStrike API URL**: The base URL of the CrowdStrike API. +*** **CrowdStrike Client ID**: Client ID for the API client used to perform actions in CrowdStrike. +*** **Client Secret**: Client secret allowing you access to CrowdStrike. +.. Click **Save**. +. **Create and enable detection rules to generate {elastic-sec} alerts.** (Optional) Create <> to generate {elastic-sec} alerts based on CrowdStrike events and data. The {integrations-docs}/crowdstrike[CrowdStrike integration docs] list the available ingested logs and fields you can use to build a rule query. ++ +This gives you visibility into CrowdStrike without needing to leave {elastic-sec}. You can perform supported endpoint response actions directly from alerts that a rule creates, by using the **Take action** menu in the alert details flyout. + +++++ +
+ +
+++++ diff --git a/docs/serverless/endpoint-response-actions/response-actions-history.asciidoc b/docs/serverless/endpoint-response-actions/response-actions-history.asciidoc new file mode 100644 index 0000000000..41e004ed30 --- /dev/null +++ b/docs/serverless/endpoint-response-actions/response-actions-history.asciidoc @@ -0,0 +1,41 @@ +[[response-actions-history]] += Response actions history + +:description: The response actions history log keeps a record of actions taken on endpoints. +:keywords: serverless, security, defend, reference, manage + +preview:[] + +{elastic-sec} keeps a log of the <> performed on endpoints, such as isolating a host or terminating a process. The log displays when each command was performed, the host on which the action was performed, the user who requested the action, any comments added to the action, and the action's current status. + +.Requirement +[NOTE] +==== +You must have the appropriate user role to use this feature. + +// Placeholder statement until we know which specific roles are required. Classic statement below for reference. + +// You must have the **Response Actions History** privilege to access this feature. +==== + +To access the response actions history for all endpoints, go to **Assets** → **Response actions history**. You can also access the response actions history for an individual endpoint from these areas: + +* **Endpoints** page: Click an endpoint's name to open the details flyout, then click the **Response actions history** tab. +* **Response console** page: Click the **Response actions history** button. + +All of these contexts contain the same information and features. The following image shows the **Response actions history** page for all endpoints: + +[role="screenshot"] +image::images/response-actions-history/-management-admin-response-actions-history-page.png[Response actions history page UI] + +To filter and expand the information in the response actions history: + +* Enter a user name or comma-separated list of user names in the search field to display actions requested by those users. +* Use the various drop-down menus to filter the actions shown: ++ +** **Hosts**: Show actions performed on specific endpoints. (This menu is only available on the **Response actions history** page for all endpoints.) +** **Actions**: Show specific actions types. +** **Statuses**: Show actions with a specific status. +** **Types**: Show actions based on the endpoint protection agent type {(elastic-defend} or a third-party agent), and how the action was triggered (manually by a user or automatically by a detection rule). +* Use the date and time picker to display actions within a specific time range. +* Click the expand arrow on the right to display more details about an action. diff --git a/docs/serverless/endpoint-response-actions/response-actions.asciidoc b/docs/serverless/endpoint-response-actions/response-actions.asciidoc new file mode 100644 index 0000000000..24125eb065 --- /dev/null +++ b/docs/serverless/endpoint-response-actions/response-actions.asciidoc @@ -0,0 +1,308 @@ +[[response-actions]] += Endpoint response actions + +:description: Perform response actions on endpoints using a terminal-like interface. +:keywords: serverless, security, defend, reference, manage + +preview:[] + +The response console allows you to perform response actions on an endpoint using a terminal-like interface. You can enter action commands and get near-instant feedback on them. Actions are also recorded in the endpoint's <> for reference. + +Response actions are supported on all endpoint platforms (Linux, macOS, and Windows). + +.Requirements +[NOTE] +==== +* Response actions and the response console UI require the Endpoint Protection Complete https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature]. +* Endpoints must have {agent} version 8.4 or higher installed with the {elastic-defend} integration to receive response actions. +* Some response actions require either a https://www.elastic.co/docs/current/serverless/general/assign-user-roles[predefined Security user role] or a https://www.elastic.co/docs/current/serverless/custom-roles[custom role] with a specific feature privilege, indicated below. These are required to perform actions both in the response console and in other areas of the {security-app} (such as isolating a host from a detection alert). +* Users must have the appropriate user role privileges for at least one response action to access the response console. +==== + +[role="screenshot"] +image::images/response-actions/-management-admin-response-console.png[Response console UI] + +Launch the response console from any of the following places in {elastic-sec}: + +* **Endpoints** page → **Actions** menu (image:images/icons/boxesHorizontal.svg[Actions menu icon]) → **Respond** +* Endpoint details flyout → **Take action** → **Respond** +* Alert details flyout → **Take action** → **Respond** +* Host details page → **Respond** + +To perform an action on the endpoint, enter a <> in the input area at the bottom of the console, then press **Return**. Output from the action is displayed in the console. + +If a host is unavailable, pending actions will execute once the host comes online. Pending actions expire after two weeks and can be tracked in the response actions history. + +[NOTE] +==== +Some response actions may take a few seconds to complete. Once you enter a command, you can immediately enter another command while the previous action is running. +==== + +Activity in the response console is persistent, so you can navigate away from the page and any pending actions you've submitted will continue to run. To confirm that an action completed, return to the response console to view the console output or check the <>. + +[IMPORTANT] +==== +Once you submit a response action, you can't cancel it, even if the action is pending for an offline host. +==== + +[discrete] +[[response-action-commands]] +== Response action commands + +The following response action commands are available in the response console. + +[discrete] +[[response-actions-isolate]] +=== `isolate` + +<>, blocking communication with other hosts on the network. + +Predefined role: **Tier 3 analyst**, **SOC manager**, or **Endpoint operations analyst** + +Custom role privilege: **Host isolation** + +Example: `isolate --comment "Isolate host related to detection alerts"` + +[discrete] +[[response-actions-release]] +=== `release` + +Release an isolated host, allowing it to communicate with the network again. + +Predefined role: **Tier 3 analyst**, **SOC manager**, or **Endpoint operations analyst** + +Custom role privilege: **Host isolation** + +Example: `release --comment "Release host, everything looks OK"` + +[discrete] +[[response-actions-status]] +=== `status` + +Show information about the host's status, including: {agent} status and version, the {elastic-defend} integration's policy status, and when the host was last active. + +[discrete] +[[processes]] +=== `processes` + +Show a list of all processes running on the host. This action may take a minute or so to complete. + +Predefined role: **Tier 3 analyst**, **SOC manager**, or **Endpoint operations analyst** + +Custom role privilege: **Process Operations** + +[TIP] +==== +Use this command to get current PID or entity ID values, which are required for other response actions such as `kill-process` and `suspend-process`. + +Entity IDs may be more reliable than PIDs, because entity IDs are unique values on the host, while PID values can be reused by the operating system. +==== + +[NOTE] +==== +Running this command on third-party-protected hosts might return the process list in a different format. Refer to <> for more information. +==== + +[discrete] +[[kill-process]] +=== `kill-process` + +Terminate a process. You must include one of the following parameters to identify the process to terminate: + +* `--pid` : A process ID (PID) representing the process to terminate. +* `--entityId` : An entity ID representing the process to terminate. + +Predefined role: **Tier 3 analyst**, **SOC manager**, or **Endpoint operations analyst** + +Custom role privilege: **Process Operations** + +Example: `kill-process --pid 123 --comment "Terminate suspicious process"` + +[NOTE] +==== +For SentinelOne-enrolled hosts, you must use the parameter `--processName` to identify the process to terminate. `--pid` and `--entityId` are not supported. + +Example: `kill-process --processName cat --comment "Terminate suspicious process"` +==== + +[discrete] +[[response-actions-suspend-process]] +=== `suspend-process` + +Suspend a process. You must include one of the following parameters to identify the process to suspend: + +* `--pid` : A process ID (PID) representing the process to suspend. +* `--entityId` : An entity ID representing the process to suspend. + +Predefined role: **Tier 3 analyst**, **SOC manager**, or **Endpoint operations analyst** + +Custom role privilege: **Process Operations** + +Example: `suspend-process --pid 123 --comment "Suspend suspicious process"` + +[discrete] +[[get-file]] +=== `get-file` + +Retrieve a file from a host. Files are downloaded in a password-protected `.zip` archive to prevent the file from running. Use password `elastic` to open the `.zip` in a safe environment. + +[NOTE] +==== +Files retrieved from third-party-protected hosts require a different password. Refer to <> for your system's password. +==== + +You must include the following parameter to specify the file's location on the host: + +* `--path` : The file's full path (including the file name). + +Predefined role: **Tier 3 analyst**, **SOC manager**, or **Endpoint operations analyst** + +Custom role privilege: **File Operations** + +Example: `get-file --path "/full/path/to/file.txt" --comment "Possible malware"` + +[TIP] +==== +You can use the <> to query a host's operating system and gain insight into its files and directories, then use `get-file` to retrieve specific files. +==== + +[NOTE] +==== +When {elastic-defend} prevents file activity due to <>, the file is quarantined on the host and a malware prevention alert is created. To retrieve this file with `get-file`, copy the path from the alert's **Quarantined file path** field (`file.Ext.quarantine_path`), which appears under **Highlighted fields** in the alert details flyout. Then paste the value into the `--path` parameter. +==== + +[discrete] +[[response-actions-execute]] +=== `execute` + +Run a shell command on the host. The command's output and any errors appear in the response console, up to 2000 characters. The complete output (stdout and stderr) are also saved to a downloadable `.zip` archive (password: `elastic`). Use these parameters: + +* `--command` : (Required) A shell command to run on the host. The command must be supported by `bash` for Linux and macOS hosts, and `cmd.exe` for Windows. ++ +[NOTE] +==== +* Multiple consecutive dashes in the value must be escaped; single dashes do not need to be escaped. For example, to represent a directory named `/opt/directory--name`, use the following: `/opt/directory--name`. +* You can use quotation marks without escaping. For example: +`execute --command "cd "C:\Program Files\directory""` +==== +* `--timeout` : (Optional) How long the host should wait for the command to complete. Use `h` for hours, `m` for minutes, `s` for seconds (for example, `2s` is two seconds). If no timeout is specified, it defaults to four hours. + +Predefined role: **SOC manager** or **Endpoint operations analyst** + +Custom role privilege: **Execute Operations** + +Example: `execute --command "ls -al" --timeout 2s --comment "Get list of all files"` + +[WARNING] +==== +This response action runs commands on the host using the same user account running the {elastic-defend} integration, which normally has full control over the system. Be careful with any commands that could cause irrevocable changes. +==== + +[discrete] +[[response-actions-upload]] +=== `upload` + +Upload a file to the host. The file is saved to the location on the host where {elastic-endpoint} is installed. After you run the command, the full path is returned in the console for reference. Use these parameters: + +* `--file` : (Required) The file to send to the host. As soon as you type this parameter, a popup appears — select it to navigate to the file, or drag and drop the file onto the popup. +* `--overwrite` : (Optional) Overwrite the file on the host if it already exists. + +Predefined role: **Tier 3 analyst**, **SOC manager**, or **Endpoint operations analyst** + +Custom role privilege: **File Operations** + +Example: `upload --file --comment "Upload remediation script"` + +[TIP] +==== +You can follow this with the `execute` response action to upload and run scripts for mitigation or other purposes. +==== + +[NOTE] +==== +The default file size maximum is 25 MB, configurable in `kibana.yml` with the `xpack.securitySolution.maxUploadResponseActionFileBytes` setting. You must enter the value in bytes (the maximum is `104857600` bytes, or 100 MB). +==== + +[discrete] +[[response-actions-scan]] +=== `scan` + +Scan a specific file or directory on the host for malware. This uses the <> (such as **Detect** or **Prevent** options, or enabling the blocklist) as configured in the host's associated {elastic-defend} integration policy. Use these parameters: + +* `--path` : (Required) The absolute path to a file or directory to be scanned. + +Predefined role: **Tier 3 Analyst**, **SOC Manager**, or **Endpoint Operations Analyst** + +Custom role privilege: **Scan Operations** + +Example: `scan --path "/Users/username/Downloads" --comment "Scan Downloads folder for malware"` + +[NOTE] +==== +Scanning can take longer for directories containing a lot of files. +==== + +[discrete] +[[supporting-commands-parameters]] +== Supporting commands and parameters + +[discrete] +[[response-actions-comment]] +=== `--comment` + +Add to a command to include a comment explaining or describing the action. Comments are included in the response actions history. + +[discrete] +[[response-actions-help]] +=== `--help` + +Add to a command to get help for that command. + +Example: `isolate --help` + +[discrete] +[[response-actions-clear]] +=== `clear` + +Clear all output from the response console. + +[discrete] +[[response-actions-help-1]] +=== `help` + +List supported commands in the console output area. + +[TIP] +==== +You can also get a list of commands in the <>, which stays on the screen independently of the output area. +==== + +[discrete] +[[help-panel]] +== Help panel + +Click image:images/icons/help.svg[Help] **Help** in the upper-right to open the **Help** panel, which lists available response action commands and parameters as a reference. + +[NOTE] +==== +This panel displays only the response actions that you have the user role privileges to perform. +==== + +[role="screenshot"] +image::images/response-actions/-management-admin-response-console-help-panel.png[Help panel] + +You can use this panel to build commands with less typing. Click the add icon (image:images/icons/plusInCircle.svg[Add]) to add a command to the input area, enter any additional parameters or a comment, then press **Return** to run the command. + +If the endpoint is running an older version of {agent}, some response actions may not be supported, as indicated by an informational icon and tooltip. {fleet-guide}/upgrade-elastic-agent.html[Upgrade {agent}] on the endpoint to be able to use the latest response actions. + +[role="screenshot"] +image::images/response-actions/-management-admin-response-console-unsupported-command.png[Unsupported response action with tooltip] + +[discrete] +[[actions-log]] +== Response actions history + +Click **Response actions history** to display a log of the response actions performed on the endpoint, such as isolating a host or terminating a process. You can filter the information displayed in this view. Refer to <> for more details. + +[role="screenshot"] +image::images/response-actions/-management-admin-response-actions-history-console.png[Response actions history with a few past actions] diff --git a/docs/serverless/endpoint-response-actions/response-actions.mdx b/docs/serverless/endpoint-response-actions/response-actions.mdx index 04bfda721b..2e2f3545c0 100644 --- a/docs/serverless/endpoint-response-actions/response-actions.mdx +++ b/docs/serverless/endpoint-response-actions/response-actions.mdx @@ -39,7 +39,7 @@ To perform an action on the endpoint, enter a -Some response actions may take a few seconds to complete. Once you enter a command, you can immediately enter another command while the previous action is running. +Some response actions may take a few seconds to complete. Once you enter a command, you can immediately enter another command while the previous action is running. Activity in the response console is persistent, so you can navigate away from the page and any pending actions you've submitted will continue to run. To confirm that an action completed, return to the response console to view the console output or check the response actions history. @@ -55,9 +55,10 @@ Once you submit a response action, you can't cancel it, even if the action is pe The following response action commands are available in the response console. ### `isolate` -Isolate the host, blocking communication with other hosts on the network. +Isolate the host, blocking communication with other hosts on the network. + +Predefined role: **Tier 3 analyst**, **SOC manager**, or **Endpoint operations analyst** -Predefined role: **Tier 3 analyst**, **SOC manager**, or **Endpoint operations analyst**
Custom role privilege: **Host isolation** Example: `isolate --comment "Isolate host related to detection alerts"` @@ -65,19 +66,21 @@ Example: `isolate --comment "Isolate host related to detection alerts"` ### `release` Release an isolated host, allowing it to communicate with the network again. -Predefined role: **Tier 3 analyst**, **SOC manager**, or **Endpoint operations analyst**
+Predefined role: **Tier 3 analyst**, **SOC manager**, or **Endpoint operations analyst** + Custom role privilege: **Host isolation** Example: `release --comment "Release host, everything looks OK"` ### `status` Show information about the host's status, including: ((agent)) status and version, the ((elastic-defend)) integration's policy status, and when the host was last active. - +
### `processes` Show a list of all processes running on the host. This action may take a minute or so to complete. -Predefined role: **Tier 3 analyst**, **SOC manager**, or **Endpoint operations analyst**
+Predefined role: **Tier 3 analyst**, **SOC manager**, or **Endpoint operations analyst** + Custom role privilege: **Process Operations** @@ -100,7 +103,8 @@ Terminate a process. You must include one of the following parameters to identif * `--pid` : A process ID (PID) representing the process to terminate. * `--entityId` : An entity ID representing the process to terminate. -Predefined role: **Tier 3 analyst**, **SOC manager**, or **Endpoint operations analyst**
+Predefined role: **Tier 3 analyst**, **SOC manager**, or **Endpoint operations analyst** + Custom role privilege: **Process Operations** Example: `kill-process --pid 123 --comment "Terminate suspicious process"` @@ -118,7 +122,8 @@ Suspend a process. You must include one of the following parameters to identify * `--pid` : A process ID (PID) representing the process to suspend. * `--entityId` : An entity ID representing the process to suspend. -Predefined role: **Tier 3 analyst**, **SOC manager**, or **Endpoint operations analyst**
+Predefined role: **Tier 3 analyst**, **SOC manager**, or **Endpoint operations analyst** + Custom role privilege: **Process Operations** Example: `suspend-process --pid 123 --comment "Suspend suspicious process"` @@ -136,7 +141,8 @@ You must include the following parameter to specify the file's location on the h * `--path` : The file's full path (including the file name). -Predefined role: **Tier 3 analyst**, **SOC manager**, or **Endpoint operations analyst**
+Predefined role: **Tier 3 analyst**, **SOC manager**, or **Endpoint operations analyst** + Custom role privilege: **File Operations** Example: `get-file --path "/full/path/to/file.txt" --comment "Possible malware"` @@ -147,7 +153,7 @@ You can use the Osq -When ((elastic-defend)) prevents file activity due to malware prevention, the file is quarantined on the host and a malware prevention alert is created. To retrieve this file with `get-file`, copy the path from the alert's **Quarantined file path** field (`file.Ext.quarantine_path`), which appears under **Highlighted fields** in the alert details flyout. Then paste the value into the `--path` parameter. +When ((elastic-defend)) prevents file activity due to malware prevention, the file is quarantined on the host and a malware prevention alert is created. To retrieve this file with `get-file`, copy the path from the alert's **Quarantined file path** field (`file.Ext.quarantine_path`), which appears under **Highlighted fields** in the alert details flyout. Then paste the value into the `--path` parameter. @@ -168,7 +174,8 @@ Run a shell command on the host. The command's output and any errors appear in t * `--timeout` : (Optional) How long the host should wait for the command to complete. Use `h` for hours, `m` for minutes, `s` for seconds (for example, `2s` is two seconds). If no timeout is specified, it defaults to four hours. -Predefined role: **SOC manager** or **Endpoint operations analyst**
+Predefined role: **SOC manager** or **Endpoint operations analyst** + Custom role privilege: **Execute Operations** Example: `execute --command "ls -al" --timeout 2s --comment "Get list of all files"` @@ -184,7 +191,8 @@ Upload a file to the host. The file is saved to the location on the host where ( * `--file` : (Required) The file to send to the host. As soon as you type this parameter, a popup appears — select it to navigate to the file, or drag and drop the file onto the popup. * `--overwrite` : (Optional) Overwrite the file on the host if it already exists. -Predefined role: **Tier 3 analyst**, **SOC manager**, or **Endpoint operations analyst**
+Predefined role: **Tier 3 analyst**, **SOC manager**, or **Endpoint operations analyst** + Custom role privilege: **File Operations** Example: `upload --file --comment "Upload remediation script"` @@ -203,7 +211,8 @@ Scan a specific file or directory on the host for malware. This uses the +Predefined role: **Tier 3 Analyst**, **SOC Manager**, or **Endpoint Operations Analyst** + Custom role privilege: **Scan Operations** Example: `scan --path "/Users/username/Downloads" --comment "Scan Downloads folder for malware"` @@ -242,7 +251,7 @@ You can also get a list of commands in the **Help** in the upper-right to open the **Help** panel, which lists available response action commands and parameters as a reference. +Click **Help** in the upper-right to open the **Help** panel, which lists available response action commands and parameters as a reference. This panel displays only the response actions that you have the user role privileges to perform. diff --git a/docs/serverless/endpoint-response-actions/third-party-actions.asciidoc b/docs/serverless/endpoint-response-actions/third-party-actions.asciidoc new file mode 100644 index 0000000000..d712ac80e3 --- /dev/null +++ b/docs/serverless/endpoint-response-actions/third-party-actions.asciidoc @@ -0,0 +1,79 @@ +[[third-party-actions]] += Third-party response actions + +:description: Respond to threats on hosts enrolled in third-party security systems. +:keywords: serverless, security, defend, reference, manage + +preview:[] + +preview::[] + +You can perform response actions on hosts enrolled in other third-party endpoint protection systems, such as CrowdStrike or SentinelOne. For example, you can direct the other system to isolate a suspicious endpoint from your network, without leaving the {elastic-sec} UI. + +.Requirements +[NOTE] +==== +* Third-party response actions require the Endpoint Protection Complete https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature]. +* Each response action type has its own user role privilege requirements. Find an action's role requirements at <>. +==== + +[discrete] +[[third-party-actions-supported-systems-and-response-actions]] +== Supported systems and response actions + +The following third-party response actions are supported for CrowdStrike and SentinelOne. <> to connect each system with {elastic-sec}. + +++++ +
+
+ + +
+
+++++ +These response actions are supported for CrowdStrike-enrolled hosts: + +* **Isolate and release a host** using any of these methods: ++ +** From a detection alert +** From the response console ++ +Refer to the instructions on <> and <> hosts for more details. + +++++ +
+ +
+++++ diff --git a/docs/serverless/explore/conf-map-ui.asciidoc b/docs/serverless/explore/conf-map-ui.asciidoc new file mode 100644 index 0000000000..3d6b0871c5 --- /dev/null +++ b/docs/serverless/explore/conf-map-ui.asciidoc @@ -0,0 +1,157 @@ +[[conf-map-ui]] += Configure network map data + +:description: Requirements for setting up and using the Network page. +:keywords: serverless, security, how-to, manage + +preview:[] + +Depending on your setup, to display and interact with data on the +**Network** page's map you might need to: + +* <> +* <> +* <> + +[NOTE] +==== +To see source and destination connections lines on the map, you must +configure `source.geo` and `destination.geo` ECS fields for your indices. +==== + +[discrete] +[[prereq-perms]] +== Permissions required + +To view the map, you need the appropriate https://www.elastic.co/docs/current/serverless/general/assign-user-roles[predefined user role] or a https://www.elastic.co/docs/current/serverless/custom-roles[custom role] with at least `Read` privileges for the `Maps` feature. + +[discrete] +[[kibana-index-pattern]] +== Create data views + +To display map data, you must define a +{kibana-ref}/data-views.html[data view] (**Project settings** → **Management** → **Data views**) that includes one or more of the indices specified in the `securitysolution:defaultIndex` field in advanced settings. + +For example, to display data that is stored in indices matching the index pattern `servers-europe-*` on the map, you must use a data view whose index pattern matches `servers-europe-*`, such as `servers-*`. + +[discrete] +[[geoip-data]] +== Add geoIP data + +When the ECS {ecs-ref}/ecs-geo.html[source.geo.location and +destination.geo.location] fields are mapped, network data is displayed on +the map. + +If you use Beats, configure a geoIP processor to add data to the relevant +fields: + +. Define an ingest node pipeline that uses one or more `geoIP` processors to add +location information to events. For example, use the Console in **Dev tools** to create +the following pipeline: ++ +[source,json] +---- +PUT _ingest/pipeline/geoip-info +{ +"description": "Add geoip info", +"processors": [ +{ +"geoip": { +"field": "client.ip", +"target_field": "client.geo", +"ignore_missing": true +} +}, +{ +"geoip": { +"field": "source.ip", +"target_field": "source.geo", +"ignore_missing": true +} +}, +{ +"geoip": { +"field": "destination.ip", +"target_field": "destination.geo", +"ignore_missing": true +} +}, +{ +"geoip": { +"field": "server.ip", +"target_field": "server.geo", +"ignore_missing": true +} +}, +{ +"geoip": { +"field": "host.ip", +"target_field": "host.geo", +"ignore_missing": true +} +} +] +} +---- ++ +// CONSOLE ++ +In this example, the pipeline ID is `geoip-info`. `field` specifies the field +that contains the IP address to use for the geographical lookup, and +`target_field` is the field that will hold the geographical information. +`"ignore_missing": true` configures the pipeline to continue processing when +it encounters an event that doesn't have the specified field. ++ +[TIP] +==== +An example ingest pipeline that uses the GeoLite2-ASN.mmdb database to add +autonomous system number (ASN) fields can be found https://github.com/elastic/examples/blob/master/Security%20Analytics/SIEM-examples/Packetbeat/geoip-info.json[here]. +==== +. In your Beats configuration files, add the pipeline to the `output.elasticsearch` tag: ++ +[source,yml] +---- +output.elasticsearch: +hosts: ["localhost:9200"] +pipeline: geoip-info <1> +---- ++ +<1> The value of this field must be the same as the ingest pipeline name in +<> (`geoip-info` in this example). + +[discrete] +[[private-network]] +== Map your internal network + +If you want to add your network’s internal IP addresses to the map, define geo +location fields under the `processors` tag in the Beats configuration files +on your hosts: + +[source,yml] +---- + processors: + - add_host_metadata: + - add_cloud_metadata: ~ + - add_fields: + when.network.source.ip: <1> + fields: + source.geo.location: + lat: + lon: + target: '' + - add_fields: + when.network.destination.ip: + fields: + destination.geo.location: + lat: + lon: + target: '' +---- + +<1> For the IP address, you can use either `private` or CIDR notation. + +[TIP] +==== +You can also enrich your data with other +{packetbeat-ref}/add-host-metadata.html[host fields]. +==== diff --git a/docs/serverless/explore/conf-map-ui.mdx b/docs/serverless/explore/conf-map-ui.mdx index 0fa1b1d945..7a2e56200a 100644 --- a/docs/serverless/explore/conf-map-ui.mdx +++ b/docs/serverless/explore/conf-map-ui.mdx @@ -1,7 +1,7 @@ --- slug: /serverless/security/conf-map-ui title: Configure network map data -description: Requirements for setting up and using the Network page. +description: Requirements for setting up and using the Network page. tags: [ 'serverless', 'security', 'how-to','manage' ] status: in review --- @@ -12,9 +12,9 @@ status: in review Depending on your setup, to display and interact with data on the **Network** page's map you might need to: -* Create data views -* Add geographical IP data to events -* Map your internal network +* Create data views +* Add geographical IP data to events +* Map your internal network To see source and destination connections lines on the map, you must @@ -31,7 +31,7 @@ To view the map, you need the appropriate >. + +To learn how to modify, create, or delete another {data-source} refer to {kibana-ref}/data-views.html[{data-sources-cap}]. + +You can also temporarily modify the active {data-source} from the **{data-source-cap}** menu by clicking **Advanced options**, then adding or removing index patterns. + +[role="screenshot"] +image::images/data-views-in-sec/-getting-started-dataview-filter-example.gif[video showing how to filter the active data view] + +This only allows you to add index patterns that match indices that currently contain data (other index patterns are unavailable). Note that any changes made are saved in the current browser window and won't persist if you open a new tab. + +[NOTE] +==== +You cannot update the data view for the Alerts page. This includes referencing a cross-cluster search (CCS) data view or any other data view. The Alerts page always shows data from `.alerts-security.alerts-default`. +==== + +[discrete] +[[default-data-view-security]] +== The default {data-source} + +The default {data-source} is defined by the `securitySolution:defaultIndex` setting, which you can modify in your project's advanced settings. To learn more about this setting, including its default value, refer to <>). + +The first time a user visits {elastic-sec}, the default {data-source} generates and becomes active. + +// TO-DO: in the first sentence of the following note, link to the Serverless page that explains spaces. + +[NOTE] +==== +Your space must have **Data View Management** feature visibility setting enabled for the default {data-source} to generate and become active in your space. +==== + +If you delete the active {data-source} when there are no other defined {data-sources}, the default {data-source} will regenerate and become active upon refreshing any {elastic-sec} page. diff --git a/docs/serverless/explore/explore-your-data.asciidoc b/docs/serverless/explore/explore-your-data.asciidoc new file mode 100644 index 0000000000..0a8c69c81f --- /dev/null +++ b/docs/serverless/explore/explore-your-data.asciidoc @@ -0,0 +1,15 @@ +[[security-explore-your-data]] += Explore your data + +:keywords: serverless, security, overview + +preview:[] + +This section contains the following pages: + +* <> +* <> +* <> +* <> +* <> +* <> diff --git a/docs/serverless/explore/hosts-overview.asciidoc b/docs/serverless/explore/hosts-overview.asciidoc new file mode 100644 index 0000000000..af39fe6724 --- /dev/null +++ b/docs/serverless/explore/hosts-overview.asciidoc @@ -0,0 +1,133 @@ +[[hosts-overview]] += Hosts page + +:description: Explore the Hosts page to analyze hosts and related security events. +:keywords: serverless, security, how-to, analyze + +preview:[] + +The Hosts page provides a comprehensive overview of all hosts and host-related security events. Key performance indicator (KPI) charts, data tables, and interactive widgets let you view specific data, drill down for deeper insights, and interact with Timeline for further investigation. + +[role="screenshot"] +image::images/hosts-overview/-management-hosts-hosts-ov-pg.png[Hosts page] + +The Hosts page has the following sections: + +[discrete] +[[host-KPI-charts]] +== Host KPI (key performance indicator) charts + +KPI charts show metrics for hosts and unique IPs within the time range specified in the date picker. This data is visualized using linear or bar graphs. + +[TIP] +==== +Hover inside a KPI chart to display the actions menu (image:images/icons/boxesHorizontal.svg[Actions menu icon]), where you can perform these actions: inspect, open in Lens, and add to a new or existing case. +==== + +[discrete] +[[host-data-tables]] +== Data tables + +Beneath the KPI charts are data tables, categorized by individual tabs, which are useful for viewing and investigating specific types of data. Select the relevant tab to view the following data: + +* **Events**: All host events. To display alerts received from external monitoring tools, scroll down to the Events table and select **Show only external alerts** on the right. +* **All hosts**: High-level host details. +* **Uncommon processes**: Uncommon processes running on hosts. +* **Anomalies**: Anomalies discovered by machine learning jobs. +* **Host risk**: The latest recorded host risk score for each host, and its host risk classification. This feature requires the Security Analytics Complete https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature] and must be enabled to display the data. To learn more, refer to our <>. +* **Sessions**: Linux process events that you can open in <>, an investigation tool that allows you to examine Linux process data at a hierarchal level. + +The tables within the **Events** and **Sessions** tabs include inline actions and several customization options. To learn more about what you can do with the data in these tables, refer to <>. + +[role="screenshot"] +image::images/hosts-overview/-getting-started-users-events-table.png[Events table] + +[discrete] +[[host-details-page]] +== Host details page + +A host's details page displays all relevant information for the selected host. To view a host's details page, click its **Host name** link in the **All hosts** table. + +The host details page includes the following sections: + +* **Asset Criticality**: If the `securitySolution:enableAssetCriticality` <> is on, this section displays the host's current <>. +* **Summary**: Details such as the host ID, when the host was first and last seen, the associated IP addresses, and associated operating system. If the entity risk score feature is enabled, this section also displays host risk score data. +* **Alert metrics**: The total number of alerts by severity, rule, and status (`Open`, `Acknowledged`, or `Closed`). +* **Data tables**: The same data tables as on the main Hosts page, except with values for the selected host instead of all hosts. + +[role="screenshot"] +image::images/hosts-overview/-management-hosts-hosts-detail-pg.png[Host's details page] + +[discrete] +[[hosts-overview-host-details-flyout]] +== Host details flyout + +In addition to the host details page, relevant host information is also available in the host details flyout throughout the {elastic-sec} app. You can access this flyout from the following places: + +* The Alerts page, by clicking on a host name in the Alerts table +* The Entity Analytics dashboard, by clicking on a host name in the Host Risk Scores table +* The **Events** tab on the Users and user details pages, by clicking on a host name in the Events table +* The **User risk** tab on the user details page, by clicking on a host name in the Top risk score contributors table +* The **Events** tab on the Hosts and host details pages, by clicking on a host name in the Events table +* The **Host risk** tab on the host details page, by clicking on a host name in the Top risk score contributors table + +The host details flyout includes the following sections: + +* <>, which displays host risk data and inputs. +* <>, which allows you to view and assign asset criticality. +* <>, which displays host details. + +[role="screenshot"] +image::images/hosts-overview/-host-details-flyout.png[Host details flyout] + +[discrete] +[[hosts-overview-host-risk-summary]] +=== Host risk summary + +.Requirements +[NOTE] +==== +The **Host risk summary** section is only available if the <>. +==== + +The **Host risk summary** section contains a risk summary visualization and table. + +The risk summary visualization shows the host risk score and host risk level. Hover over the visualization to display the **Options** menu (image:images/icons/boxesHorizontal.svg[Options menu]). Use this menu to inspect the visualization's queries, add it to a new or existing case, save it to your Visualize Library, or open it in Lens for customization. + +The risk summary table shows the category, score, and number of risk inputs that determine the host risk score. Hover over the table to display the **Inspect** button (image:images/icons/inspect.svg[Inspect]), which allows you to inspect the table's queries. + +To expand the **Host risk summary** section, click **View risk contributions**. The left panel displays additional details about the host's risk inputs: + +* The asset criticality level and contribution score from the latest risk scoring calculation. +* The top 10 alerts that contributed to the latest risk scoring calculation, and each alert's contribution score. + +If more than 10 alerts contributed to the risk scoring calculation, the remaining alerts' aggregate contribution score is displayed below the **Alerts** table. + +[role="screenshot"] +image::images/hosts-overview/-host-risk-inputs.png[Host risk inputs] + +[discrete] +[[hosts-overview-asset-criticality]] +=== Asset Criticality + +.Requirements +[NOTE] +==== +The **Asset Criticality** section is only available if the `securitySolution:enableAssetCriticality` <> is on. +==== + +The **Asset Criticality** section displays the selected host's <>. Asset criticality contributes to the overall <>. The criticality level defines how impactful the host is when calculating the risk score. + +[role="screenshot"] +image::images/hosts-overview/-host-asset-criticality.png[Asset criticality] + +Click **Assign** to assign a criticality level to the selected host, or **Change** to change the currently assigned criticality level. + +[discrete] +[[hosts-overview-observed-data]] +=== Observed data + +This section displays details such as the host ID, when the host was first and last seen, the associated IP addresses and operating system, and the relevant Endpoint integration policy information. + +[role="screenshot"] +image::images/hosts-overview/-host-observed-data.png[Host observed data] diff --git a/docs/serverless/explore/network-page-overview.asciidoc b/docs/serverless/explore/network-page-overview.asciidoc new file mode 100644 index 0000000000..8f6d5e1e2a --- /dev/null +++ b/docs/serverless/explore/network-page-overview.asciidoc @@ -0,0 +1,85 @@ +[[network-page-overview]] += Network page + +:description: Analyze key network activity metrics on an interactive map, and use network event tables for deeper insights. +:keywords: serverless, security, how-to, analyze + +preview:[] + +The Network page provides key network activity metrics in an interactive map, and network event tables that enable interaction with Timeline. You can drag and drop items of interest from the Network view to Timeline for further investigation. + +[role="screenshot"] +image::images/network-page-overview/-getting-started-network-ui.png[] + +[discrete] +[[map-ui]] +== Map + +The map provides an interactive visual overview of your network traffic. Hover over source and destination points to show more information, such as host names and IP addresses. + +[NOTE] +==== +To access the interactive map, you must have the appropriate user role. To learn more about map setup, refer to <>. +==== + +There are several ways to drill down: + +* Click a point, hover over the host name or destination IP, then use the filter icon to add a field to the filter bar. +* Drag a field from the map to Timeline. +* Click a host name to go to the Hosts page. +* Click an IP address to open its details page. + +You can start an investigation using the map, and the map refreshes to show related data when you run a query or update the time range. + +[TIP] +==== +To add and remove layers, click on the **Options** menu (**...**) in the top right corner of the map. +==== + +[discrete] +[[map-widgets-tables]] +== Widgets and data tables + +Interactive widgets let you drill down for deeper insights: + +* Network events +* DNS queries +* Unique flow IDs +* TLS handshakes +* Unique private IPs + +There are also tabs for viewing and investigating specific types of data: + +* **Events**: All network events. To display alerts received from external monitoring tools, scroll down to the events table and select **Show only external alerts** on the right. + +The Events table includes inline actions and several customization options. To learn more about what you can do with the data in these tables, refer to <>. + +* **Flows**: Source and destination IP addresses and countries. +* **DNS**: DNS network queries. +* **HTTP**: Received HTTP requests (HTTP requests for applications using +{apm-app-ref}/apm-getting-started.html[Elastic APM] are monitored by default). +* **TLS**: Handshake details. +* **Anomalies**: Anomalies discovered by <>. + +[discrete] +[[ip-details-page]] +== IP details page + +An IP's details page shows related network information for the selected IP address. + +To view an IP's details page, click its IP address link from the Source IPs or Destination IPs table. + +The IP's details page includes the following sections: + +* **Summary**: General details such as the location, when the IP address was first and last seen, the associated host ID and host name, and links to external sites for verifying the IP address's reputation. ++ +[NOTE] +==== +By default, the external sites are https://talosintelligence.com/[Talos] and +https://www.virustotal.com/[VirusTotal]. Refer to <> to learn how to configure IP reputation links. +==== +* **Alert metrics**: The total number of alerts by severity, rule, and status (`Open`, `Acknowledged`, or `Closed`). +* **Data tables**: The same data tables as on the main Network page, except with values for the selected IP address instead of all IP addresses. + +[role="screenshot"] +image::images/network-page-overview/-getting-started-IP-detail-pg.png[IP details page] diff --git a/docs/serverless/explore/runtime-fields.asciidoc b/docs/serverless/explore/runtime-fields.asciidoc new file mode 100644 index 0000000000..4a3a602b07 --- /dev/null +++ b/docs/serverless/explore/runtime-fields.asciidoc @@ -0,0 +1,60 @@ +[[runtime-fields]] += Create runtime fields in {elastic-sec} + +:description: Create, edit, or delete runtime fields in {elastic-sec}. +:keywords: serverless, security, how-to, manage + +++++ +Create runtime fields +++++ + +preview:[] + +Runtime fields are fields that you can add to documents after you've ingested your data. For example, you could combine two fields and treat them as one, or perform calculations on existing data and use the result as a separate field. Runtime fields are evaluated when a query is run. + +You can create a runtime field and add it to your detection alerts or events from any page that lists alerts or events in a data grid table, such as **Alerts**, **Timelines**, **Hosts**, and **Users**. Once created, the new field is added to the current <> and becomes available to all {elastic-sec} alerts and events in the data view. + +[NOTE] +==== +Runtime fields can impact performance because they're evaluated each time a query runs. Refer to {ref}/runtime.html[Runtime fields] for more information. +==== + +To create a runtime field: + +. Go to a page that lists alerts or events (for example, **Alerts** or **Timelines** → **_Name of Timeline_**). +. Do one of the following: ++ +** In the Alerts table, click the **Fields** toolbar button in the table's upper-left. From the **Fields** browser, click **Create field**. The **Create field** flyout opens. ++ +[role="screenshot"] +image::images/runtime-fields/-reference-fields-browser.png[Fields browser] ++ +** In Timeline, go to the bottom of the sidebar, then click **Add a field**. The **Create field** flyout opens. ++ +[role="screenshot"] +image::images/runtime-fields/-reference-create-runtime-fields-timeline.png[Create runtime fields button in Timeline] +. Enter a **Name** for the new field. +. Select a **Type** for the field's data type. +. Turn on the **Set value** toggle and enter a {ref}/modules-scripting-painless.html[Painless script] to define the field's value. The script must match the selected **Type**. For more on adding fields and Painless scripting examples, refer to {kibana-ref}/managing-data-views.html#runtime-fields[Explore your data with runtime fields]. +. Use the **Preview** to help you build the script so it returns the expected field value. +. Configure other field settings as needed. ++ +[NOTE] +==== +Some runtime field settings, such as custom labels and display formats, might display differently in some areas of the {elastic-sec} UI. +==== +. Click **Save**. The new field appears as a new column in the data grid. + +[discrete] +[[manage-runtime-fields]] +== Manage runtime fields + +You can edit or delete existing runtime fields from the **Alerts**, **Timelines**, **Hosts**, and **Users** pages. + +. Click the **Fields** button to open the **Fields** browser, then search for the runtime field you want. ++ +[TIP] +==== +Click the **Runtime** column header twice to reorder the fields table with all runtime fields at the top. +==== +. In the **Actions** column, select an option to edit or delete the runtime field. diff --git a/docs/serverless/explore/siem-field-reference.asciidoc b/docs/serverless/explore/siem-field-reference.asciidoc new file mode 100644 index 0000000000..0c3b2d645d --- /dev/null +++ b/docs/serverless/explore/siem-field-reference.asciidoc @@ -0,0 +1,267 @@ +[[siem-field-reference]] += {elastic-sec} ECS field reference + +:description: Learn which ECS fields are used by {elastic-sec} to display various data. +:keywords: serverless, security, reference, manage + +preview:[] + +This section lists {ecs-ref}[Elastic Common Schema] (ECS) fields used by {elastic-sec} to provide an optimal SIEM and security analytics experience to users. These fields are used to display data, provide rule previews, enable detection by prebuilt detection rules, provide context during rule triage and investigation, escalate to cases, and more. + +[IMPORTANT] +==== +We recommend you use {agent} integrations or {beats} to ship your data to {elastic-sec}. {agent} integrations and Beat modules (for example, {filebeat-ref}/filebeat-modules.html[{filebeat} modules]) are ECS-compliant, which means data they ship to {elastic-sec} will automatically populate the relevant ECS fields. +If you plan to use a custom implementation to map your data to ECS fields (see {ecs-ref}/ecs-converting.html[how to map data to ECS]), ensure the <> are populated. Ideally, all relevant ECS fields should be populated as well. +==== + +For detailed information about which ECS fields can appear in documents generated by {elastic-endpoint}, refer to the https://github.com/elastic/endpoint-package/tree/main/custom_documentation/doc/endpoint[Endpoint event documentation]. + +[discrete] +[[siem-always-required-fields]] +== Always required fields + +{elastic-sec} requires all event and threat intelligence data to be normalized to ECS. For proper operation, all data must contain the following ECS fields: + +* `@timestamp` +* `ecs.version` +* `event.kind` +* `event.category` +* `event.type` + +[discrete] +[[siem-required-process-event-fields]] +== Fields required for process events + +{elastic-sec} relies on these fields to analyze and display process data: + +* `process.name` +* `process.pid` + +[discrete] +[[siem-host-fields]] +== Fields required for host events + +{elastic-sec} relies on these fields to analyze and display host data: + +* `host.name` +* `host.id` + +{elastic-sec} may use these fields to display additional host data: + +* `cloud.instance.id` +* `cloud.machine.type` +* `cloud.provider` +* `cloud.region` +* `host.architecture` +* `host.ip` +* `host.mac` +* `host.os.family` +* `host.os.name` +* `host.os.platform` +* `host.os.version` + +[discrete] +[[siem-field-reference-authentication-fields]] +==== Authentication fields + +{elastic-sec} relies on these fields and values to analyze and display host authentication data: + +* `event.category:authentication` +* `event.outcome:success` or `event.outcome:failure` + +{elastic-sec} may also use this field to display additional host authentication data: + +* `user.name` + +[discrete] +[[siem-field-reference-uncommon-process-fields]] +==== Uncommon process fields + +{elastic-sec} relies on this field to analyze and display host uncommon process data: + +* `process.name` + +{elastic-sec} may also use these fields to display uncommon process data: + +* `agent.type` +* `event.action` +* `event.code` +* `event.dataset` +* `event.module` +* `process.args` +* `user.id` +* `user.name` + +[discrete] +[[siem-required-network-fields]] +== Fields required for network events + +{elastic-sec} relies on these fields to analyze and display network data: + +* `destination.geo.location` (required for display of <>) +* `destination.ip` +* `source.geo.location` (required to display map data) +* `source.ip` + +{elastic-sec} may also use these fields to analyze and display network data: + +* `destination.as.number` +* `destination.as.organization.name` +* `destination.bytes` +* `destination.domain` +* `destination.geo.country_iso_code` +* `source.as.number` +* `source.as.organization.name` +* `source.bytes` +* `source.domain` +* `source.geo.country_iso_code` + +[discrete] +[[siem-field-reference-dns-query-fields]] +==== DNS query fields + +{elastic-sec} relies on these fields to analyze and display DNS data: + +* `dns.question.name` +* `dns.question.registered_domain` + +{elastic-sec} may also use this field to display DNS data: + +* `dns.question.type` ++ +[NOTE] +==== +If you want to be able to filter out PTR records, make sure relevant +events have `dns.question.type` fields with values of `PTR`. +==== + +[discrete] +[[siem-field-reference-http-request-fields]] +==== HTTP request fields + +{elastic-sec} relies on these fields to analyze and display HTTP request data: + +* `http.request.method` +* `http.response.status_code` +* `url.domain` +* `url.path` + +[discrete] +[[siem-field-reference-tls-fields]] +==== TLS fields + +{elastic-sec} relies on this field to analyze and display TLS data: + +* `tls.server.hash.sha1` + +{elastic-sec} may also use these fields to analyze and display TLS data: + +* `tls.server.issuer` +* `tls.server.ja3s` +* `tls.server.not_after` +* `tls.server.subject` + +[discrete] +[[siem-field-reference-fields-required-for-events-and-external-alerts]] +== Fields required for events and external alerts + +{elastic-sec} relies on this field to analyze and display event and external alert data: + +* `event.kind` ++ +[NOTE] +==== +For external alerts, the `event.kind` field's value must be `alert`. +==== + +{elastic-sec} may also use these fields to analyze and display event and external alert data: + +* `destination.bytes` +* `destination.geo.city_name` +* `destination.geo.continent_name` +* `destination.geo.country_iso_code` +* `destination.geo.country_name` +* `destination.geo.region_iso_code` +* `destination.geo.region_name` +* `destination.ip` +* `destination.packets` +* `destination.port` +* `dns.question.name` +* `dns.question.type` +* `dns.resolved_ip` +* `dns.response_code` +* `event.action` +* `event.code` +* `event.created` +* `event.dataset` +* `event.duration` +* `event.end` +* `event.hash` +* `event.id` +* `event.module` +* `event.original` +* `event.outcome` +* `event.provider` +* `event.risk_score_norm` +* `event.risk_score` +* `event.severity` +* `event.start` +* `event.timezone` +* `file.ctime` +* `file.device` +* `file.extension` +* `file.gid` +* `file.group` +* `file.inode` +* `file.mode` +* `file.mtime` +* `file.name` +* `file.owner` +* `file.path` +* `file.size` +* `file.target_path` +* `file.type` +* `file.uid` +* `host.id` +* `host.ip` +* `http.request.body.bytes` +* `http.request.body.content` +* `http.request.method` +* `http.request.referrer` +* `http.response.body.bytes` +* `http.response.body.content` +* `http.response.status_code` +* `http.version` +* `message` +* `network.bytes` +* `network.community_id` +* `network.direction` +* `network.packets` +* `network.protocol` +* `network.transport` +* `pe.original_file_name` +* `process.args` +* `process.executable` +* `process.hash.md5` +* `process.hash.sha1` +* `process.hash.sha256` +* `process.name` +* `process.parent.executable` +* `process.parent.name` +* `process.pid` +* `process.ppid` +* `process.title` +* `process.working_directory` +* `rule.reference` +* `source.bytes` +* `source.geo.city_name` +* `source.geo.continent_name` +* `source.geo.country_iso_code` +* `source.geo.country_name` +* `source.geo.region_iso_code` +* `source.geo.region_name` +* `source.ip` +* `source.packets` +* `source.port` +* `user.domain` +* `user.name` diff --git a/docs/serverless/explore/users-page.asciidoc b/docs/serverless/explore/users-page.asciidoc new file mode 100644 index 0000000000..3e3b2cb2a5 --- /dev/null +++ b/docs/serverless/explore/users-page.asciidoc @@ -0,0 +1,128 @@ +[[users-page]] += Users page + +:description: Analyze authentication and user behavior within your environment. +:keywords: serverless, security, how-to, analyze + +preview:[] + +The Users page provides a comprehensive overview of user data to help you understand authentication and user behavior within your environment. Key performance indicator (KPI) charts, data tables, and interactive widgets let you view specific data and drill down for deeper insights. + +[role="screenshot"] +image::images/users-page/-getting-started-users-users-page.png[User's page] + +The Users page has the following sections: + +[discrete] +[[users-page-user-kpi-key-performance-indicator-charts]] +== User KPI (key performance indicator) charts + +KPI charts show the total number of users and successful and failed user authentications within the time range specified in the date picker. Data in the KPI charts is visualized through linear and bar graphs. + +[TIP] +==== +Hover inside a KPI chart to display the actions menu (image:images/icons/boxesHorizontal.svg[Actions menu icon]), where you can perform these actions: inspect, open in Lens, and add to a new or existing case. +==== + +[discrete] +[[users-page-data-tables]] +== Data tables + +Beneath the KPI charts are data tables, which are useful for viewing and investigating specific types of data. Select the relevant tab to view the following details: + +* **Events**: Ingested events that contain the `user.name` field. You can stack by the `event.action`, `event.dataset`, or `event.module` field. To display alerts received from external monitoring tools, scroll down to the Events table and select **Show only external alerts** on the right. +* **All users**: A chronological list of unique user names, when they were last active, and the associated domains. +* **Authentications**: A chronological list of user authentication events and associated details, such as the number of successes and failures, and the host name of the last successful destination. +* **Anomalies**: Unusual activity discovered by machine learning jobs that contain user data. +* **User risk**: The latest recorded user risk score for each user, and its user risk classification. This feature requires the Security Analytics Complete https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature] and must be enabled to display the data. To learn more, refer to our <>. + +The Events table includes inline actions and several customization options. To learn more about what you can do with the data in these tables, refer to <>. + +[discrete] +[[users-page-user-details-page]] +== User details page + +A user's details page displays all relevant information for the selected user. To view a user's details page, click its **User name** link from the **All users** table. + +The user details page includes the following sections: + +* **Asset Criticality**: If the `securitySolution:enableAssetCriticality` <> is on, this section displays the user's current <>. +* **Summary**: Details such as the user ID, when the user was first and last seen, the associated IP address(es), and operating system. If the entity risk score feature is enabled, this section also displays user risk score data. +* **Alert metrics**: The total number of alerts by severity, rule, and status (`Open`, `Acknowledged`, or `Closed`). +* **Data tables**: The same data tables as on the main Users page, except with values for the selected user instead of for all users. + +image::images/users-page/-getting-started-users-user-details-pg.png[User details page] + +[discrete] +[[users-page-user-details-flyout]] +== User details flyout + +In addition to the user details page, relevant user information is also available in the user details flyout throughout the {elastic-sec} app. You can access this flyout from the following places: + +* The Alerts page, by clicking on a user name in the Alerts table +* The Entity Analytics dashboard, by clicking on a user name in the User Risk Scores table +* The **Events** tab on the Users and user details pages, by clicking on a user name in the Events table +* The **User risk** tab on the user details page, by clicking on a user name in the Top risk score contributors table +* The **Events** tab on the Hosts and host details pages, by clicking on a user name in the Events table +* The **Host risk** tab on the host details page, by clicking on a user name in the Top risk score contributors table + +The user details flyout includes the following sections: + +* <>, which displays user risk data and inputs. +* <>, which allows you to view and assign asset criticality. +* <>, which displays user details. + +[role="screenshot"] +image::images/users-page/-user-details-flyout.png[User details flyout] + +[discrete] +[[users-page-user-risk-summary]] +=== User risk summary + +.Requirement +[NOTE] +==== +The **User risk summary** section is only available if the <>. +==== + +The **User risk summary** section contains a risk summary visualization and table. + +The risk summary visualization shows the user risk score and user risk level. Hover over the visualization to display the **Options** menu (image:images/icons/boxesHorizontal.svg[Options menu]). Use this menu to inspect the visualization's queries, add it to a new or existing case, save it to your Visualize Library, or open it in Lens for customization. + +The risk summary table shows the category, score, and number of risk inputs that determine the user risk score. Hover over the table to display the **Inspect** button (image:images/icons/inspect.svg[Inspect]), which allows you to inspect the table's queries. + +To expand the **User risk summary** section, click **View risk contributions**. The left panel displays additional details about the user's risk inputs: + +* The asset criticality level and contribution score from the latest risk scoring calculation. +* The top 10 alerts that contributed to the latest risk scoring calculation, and each alert's contribution score. + +If more than 10 alerts contributed to the risk scoring calculation, the remaining alerts' aggregate contribution score is displayed below the **Alerts** table. + +[role="screenshot"] +image::images/users-page/-user-risk-inputs.png[User risk inputs] + +[discrete] +[[users-page-asset-criticality]] +=== Asset Criticality + +.Requirement +[NOTE] +==== +The **Asset Criticality** section is only available if the `securitySolution:enableAssetCriticality` <> is on. +==== + +The **Asset Criticality** section displays the selected user's <>. Asset criticality contributes to the overall <>. The criticality level defines how impactful the user is when calculating the risk score. + +[role="screenshot"] +image::images/users-page/-user-asset-criticality.png[Asset criticality] + +Click **Assign** to assign a criticality level to the selected user, or **Change** to change the currently assigned criticality level. + +[discrete] +[[users-page-observed-data]] +=== Observed data + +This section displays details such as the user ID, when the user was first and last seen, and the associated IP addresses and operating system. + +[role="screenshot"] +image::images/users-page/-user-observed-data.png[User observed data] diff --git a/docs/serverless/images/icons/addDataApp.svg b/docs/serverless/images/icons/addDataApp.svg new file mode 100644 index 0000000000..124eef8b47 --- /dev/null +++ b/docs/serverless/images/icons/addDataApp.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/addFilter.svg b/docs/serverless/images/icons/addFilter.svg new file mode 100644 index 0000000000..5da375f4ec --- /dev/null +++ b/docs/serverless/images/icons/addFilter.svg @@ -0,0 +1 @@ + diff --git a/docs/serverless/images/icons/ai-assistant-bw.svg b/docs/serverless/images/icons/ai-assistant-bw.svg new file mode 100644 index 0000000000..06896113e4 --- /dev/null +++ b/docs/serverless/images/icons/ai-assistant-bw.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/ai-assistant.svg b/docs/serverless/images/icons/ai-assistant.svg new file mode 100644 index 0000000000..ac51eccb68 --- /dev/null +++ b/docs/serverless/images/icons/ai-assistant.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/apmTrace.svg b/docs/serverless/images/icons/apmTrace.svg new file mode 100644 index 0000000000..800b8e51a4 --- /dev/null +++ b/docs/serverless/images/icons/apmTrace.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/apps.svg b/docs/serverless/images/icons/apps.svg new file mode 100644 index 0000000000..ad6f7baf1f --- /dev/null +++ b/docs/serverless/images/icons/apps.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/arrowDown.svg b/docs/serverless/images/icons/arrowDown.svg new file mode 100644 index 0000000000..9022cdedc2 --- /dev/null +++ b/docs/serverless/images/icons/arrowDown.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/arrowLeft.svg b/docs/serverless/images/icons/arrowLeft.svg new file mode 100644 index 0000000000..d5956d01bb --- /dev/null +++ b/docs/serverless/images/icons/arrowLeft.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/arrowRight.svg b/docs/serverless/images/icons/arrowRight.svg new file mode 100644 index 0000000000..b2d76bddc2 --- /dev/null +++ b/docs/serverless/images/icons/arrowRight.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/beaker.svg b/docs/serverless/images/icons/beaker.svg new file mode 100644 index 0000000000..05eb97809c --- /dev/null +++ b/docs/serverless/images/icons/beaker.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/bell.svg b/docs/serverless/images/icons/bell.svg new file mode 100644 index 0000000000..61f2d5493a --- /dev/null +++ b/docs/serverless/images/icons/bell.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/boxesHorizontal.svg b/docs/serverless/images/icons/boxesHorizontal.svg new file mode 100644 index 0000000000..d845a6b9db --- /dev/null +++ b/docs/serverless/images/icons/boxesHorizontal.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/boxesVertical.svg b/docs/serverless/images/icons/boxesVertical.svg new file mode 100644 index 0000000000..aed10b0d8e --- /dev/null +++ b/docs/serverless/images/icons/boxesVertical.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/calendar.svg b/docs/serverless/images/icons/calendar.svg new file mode 100644 index 0000000000..ed311de10c --- /dev/null +++ b/docs/serverless/images/icons/calendar.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/casesApp.svg b/docs/serverless/images/icons/casesApp.svg new file mode 100644 index 0000000000..bbb2c459a5 --- /dev/null +++ b/docs/serverless/images/icons/casesApp.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/check.svg b/docs/serverless/images/icons/check.svg new file mode 100644 index 0000000000..1145dd301d --- /dev/null +++ b/docs/serverless/images/icons/check.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/controlsVertical.svg b/docs/serverless/images/icons/controlsVertical.svg new file mode 100644 index 0000000000..c7851102ba --- /dev/null +++ b/docs/serverless/images/icons/controlsVertical.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/copyClipboard.svg b/docs/serverless/images/icons/copyClipboard.svg new file mode 100644 index 0000000000..d21fa159a5 --- /dev/null +++ b/docs/serverless/images/icons/copyClipboard.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/cross.svg b/docs/serverless/images/icons/cross.svg new file mode 100644 index 0000000000..82df3e03d3 --- /dev/null +++ b/docs/serverless/images/icons/cross.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/discoverApp.svg b/docs/serverless/images/icons/discoverApp.svg new file mode 100644 index 0000000000..33041ae01c --- /dev/null +++ b/docs/serverless/images/icons/discoverApp.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/discuss.svg b/docs/serverless/images/icons/discuss.svg new file mode 100644 index 0000000000..f6345463ba --- /dev/null +++ b/docs/serverless/images/icons/discuss.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/document.svg b/docs/serverless/images/icons/document.svg new file mode 100644 index 0000000000..570b21dcb0 --- /dev/null +++ b/docs/serverless/images/icons/document.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/documentation.svg b/docs/serverless/images/icons/documentation.svg new file mode 100644 index 0000000000..b519c72f03 --- /dev/null +++ b/docs/serverless/images/icons/documentation.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/editorComment.svg b/docs/serverless/images/icons/editorComment.svg new file mode 100644 index 0000000000..3cf20f691d --- /dev/null +++ b/docs/serverless/images/icons/editorComment.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/error.svg b/docs/serverless/images/icons/error.svg new file mode 100644 index 0000000000..963c833e42 --- /dev/null +++ b/docs/serverless/images/icons/error.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/expand.svg b/docs/serverless/images/icons/expand.svg new file mode 100644 index 0000000000..66b1327a34 --- /dev/null +++ b/docs/serverless/images/icons/expand.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/exportAction.svg b/docs/serverless/images/icons/exportAction.svg new file mode 100644 index 0000000000..53a87fda0e --- /dev/null +++ b/docs/serverless/images/icons/exportAction.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/eye.svg b/docs/serverless/images/icons/eye.svg new file mode 100644 index 0000000000..0e576f21d5 --- /dev/null +++ b/docs/serverless/images/icons/eye.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/filter.svg b/docs/serverless/images/icons/filter.svg new file mode 100644 index 0000000000..efebf84ede --- /dev/null +++ b/docs/serverless/images/icons/filter.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/filterInCircle.svg b/docs/serverless/images/icons/filterInCircle.svg new file mode 100644 index 0000000000..ef3b61fd8f --- /dev/null +++ b/docs/serverless/images/icons/filterInCircle.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/gear.svg b/docs/serverless/images/icons/gear.svg new file mode 100644 index 0000000000..51d6cb021b --- /dev/null +++ b/docs/serverless/images/icons/gear.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/globe.svg b/docs/serverless/images/icons/globe.svg new file mode 100644 index 0000000000..ee2739ea6f --- /dev/null +++ b/docs/serverless/images/icons/globe.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/grabHorizontal.svg b/docs/serverless/images/icons/grabHorizontal.svg new file mode 100644 index 0000000000..7e824b4607 --- /dev/null +++ b/docs/serverless/images/icons/grabHorizontal.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/help.svg b/docs/serverless/images/icons/help.svg new file mode 100644 index 0000000000..ad01598e47 --- /dev/null +++ b/docs/serverless/images/icons/help.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/iInCircle.svg b/docs/serverless/images/icons/iInCircle.svg new file mode 100644 index 0000000000..33429341f3 --- /dev/null +++ b/docs/serverless/images/icons/iInCircle.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/importAction.svg b/docs/serverless/images/icons/importAction.svg new file mode 100644 index 0000000000..341653e6b1 --- /dev/null +++ b/docs/serverless/images/icons/importAction.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/indexClose.svg b/docs/serverless/images/icons/indexClose.svg new file mode 100644 index 0000000000..cb4d8f2cd2 --- /dev/null +++ b/docs/serverless/images/icons/indexClose.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/indexOpen.svg b/docs/serverless/images/icons/indexOpen.svg new file mode 100644 index 0000000000..09e9d7284b --- /dev/null +++ b/docs/serverless/images/icons/indexOpen.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/inspect.svg b/docs/serverless/images/icons/inspect.svg new file mode 100644 index 0000000000..43374b4aa4 --- /dev/null +++ b/docs/serverless/images/icons/inspect.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/lensApp.svg b/docs/serverless/images/icons/lensApp.svg new file mode 100644 index 0000000000..59af79275b --- /dev/null +++ b/docs/serverless/images/icons/lensApp.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/list.svg b/docs/serverless/images/icons/list.svg new file mode 100644 index 0000000000..52e8e7acd1 --- /dev/null +++ b/docs/serverless/images/icons/list.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/listAdd.svg b/docs/serverless/images/icons/listAdd.svg new file mode 100644 index 0000000000..b59e25bcc4 --- /dev/null +++ b/docs/serverless/images/icons/listAdd.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/menuLeft.svg b/docs/serverless/images/icons/menuLeft.svg new file mode 100644 index 0000000000..40d511e5af --- /dev/null +++ b/docs/serverless/images/icons/menuLeft.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/menuRight.svg b/docs/serverless/images/icons/menuRight.svg new file mode 100644 index 0000000000..1a772128d7 --- /dev/null +++ b/docs/serverless/images/icons/menuRight.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/merge.svg b/docs/serverless/images/icons/merge.svg new file mode 100644 index 0000000000..478d340599 --- /dev/null +++ b/docs/serverless/images/icons/merge.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/minus.svg b/docs/serverless/images/icons/minus.svg new file mode 100644 index 0000000000..763922a916 --- /dev/null +++ b/docs/serverless/images/icons/minus.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/minusInCircle.svg b/docs/serverless/images/icons/minusInCircle.svg new file mode 100644 index 0000000000..3851640918 --- /dev/null +++ b/docs/serverless/images/icons/minusInCircle.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/pagesSelect.svg b/docs/serverless/images/icons/pagesSelect.svg new file mode 100644 index 0000000000..6238881210 --- /dev/null +++ b/docs/serverless/images/icons/pagesSelect.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/pencil.svg b/docs/serverless/images/icons/pencil.svg new file mode 100644 index 0000000000..cb16b5d2f0 --- /dev/null +++ b/docs/serverless/images/icons/pencil.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/plusInCircle.svg b/docs/serverless/images/icons/plusInCircle.svg new file mode 100644 index 0000000000..2a655e0396 --- /dev/null +++ b/docs/serverless/images/icons/plusInCircle.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/plusInCircleFilled.svg b/docs/serverless/images/icons/plusInCircleFilled.svg new file mode 100644 index 0000000000..c2052e4c5f --- /dev/null +++ b/docs/serverless/images/icons/plusInCircleFilled.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/popout.svg b/docs/serverless/images/icons/popout.svg new file mode 100644 index 0000000000..875bf6662d --- /dev/null +++ b/docs/serverless/images/icons/popout.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/questionInCircle.svg b/docs/serverless/images/icons/questionInCircle.svg new file mode 100644 index 0000000000..b715f289ad --- /dev/null +++ b/docs/serverless/images/icons/questionInCircle.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/refresh.svg b/docs/serverless/images/icons/refresh.svg new file mode 100644 index 0000000000..58662be4af --- /dev/null +++ b/docs/serverless/images/icons/refresh.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/save.svg b/docs/serverless/images/icons/save.svg new file mode 100644 index 0000000000..d84f9df2d0 --- /dev/null +++ b/docs/serverless/images/icons/save.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/share.svg b/docs/serverless/images/icons/share.svg new file mode 100644 index 0000000000..c4b52ea594 --- /dev/null +++ b/docs/serverless/images/icons/share.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/sortDown.svg b/docs/serverless/images/icons/sortDown.svg new file mode 100644 index 0000000000..7efa30e917 --- /dev/null +++ b/docs/serverless/images/icons/sortDown.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/sortUp.svg b/docs/serverless/images/icons/sortUp.svg new file mode 100644 index 0000000000..c5d0f004ad --- /dev/null +++ b/docs/serverless/images/icons/sortUp.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/spaces.svg b/docs/serverless/images/icons/spaces.svg new file mode 100644 index 0000000000..745922858b --- /dev/null +++ b/docs/serverless/images/icons/spaces.svg @@ -0,0 +1,6 @@ + + + + + + \ No newline at end of file diff --git a/docs/serverless/images/icons/starEmpty.svg b/docs/serverless/images/icons/starEmpty.svg new file mode 100644 index 0000000000..177c197697 --- /dev/null +++ b/docs/serverless/images/icons/starEmpty.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/tableDensityCompact.svg b/docs/serverless/images/icons/tableDensityCompact.svg new file mode 100644 index 0000000000..9eabb5fe83 --- /dev/null +++ b/docs/serverless/images/icons/tableDensityCompact.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/timeline.svg b/docs/serverless/images/icons/timeline.svg new file mode 100644 index 0000000000..12257170f2 --- /dev/null +++ b/docs/serverless/images/icons/timeline.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/trash.svg b/docs/serverless/images/icons/trash.svg new file mode 100644 index 0000000000..5f3d6de047 --- /dev/null +++ b/docs/serverless/images/icons/trash.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/images/icons/warning.svg b/docs/serverless/images/icons/warning.svg new file mode 100644 index 0000000000..642f726c74 --- /dev/null +++ b/docs/serverless/images/icons/warning.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/serverless/index.asciidoc b/docs/serverless/index.asciidoc new file mode 100644 index 0000000000..c0e5f67d08 --- /dev/null +++ b/docs/serverless/index.asciidoc @@ -0,0 +1,189 @@ +:doctype: book + +include::{docs-root}/shared/versions/stack/{source_branch}.asciidoc[] +include::{docs-root}/shared/attributes.asciidoc[] + += Elastic Security + +include::./security-overview.asciidoc[leveloffset=+1] + +include::./billing.asciidoc[leveloffset=+1] + +include::./projects-create/create-project.asciidoc[leveloffset=+1] + +include::./sec-requirements.asciidoc[leveloffset=+1] + +include::./security-ui.asciidoc[leveloffset=+1] + +include::./AI-for-security/ai-for-security-landing-pg.asciidoc[leveloffset=+1] +include::./AI-for-security/ai-assistant.asciidoc[leveloffset=+2] +include::./AI-for-security/attack-discovery.asciidoc[leveloffset=+2] +include::./AI-for-security/llm-connector-guides.asciidoc[leveloffset=+2] +include::./AI-for-security/llm-performance-matrix.asciidoc[leveloffset=+3] +include::./AI-for-security/connect-to-azure-openai.asciidoc[leveloffset=+3] +include::./AI-for-security/connect-to-bedrock.asciidoc[leveloffset=+3] +include::./AI-for-security/connect-to-openai.asciidoc[leveloffset=+3] +include::./AI-for-security/connect-to-vertex.asciidoc[leveloffset=+3] +include::./AI-for-security/connect-to-byo-llm.asciidoc[leveloffset=+3] +include::./AI-for-security/ai-use-cases.asciidoc[leveloffset=+2] +include::./AI-for-security/usecase-attack-disc-ai-assistant-incident-reporting.asciidoc[leveloffset=+3] +include::./AI-for-security/ai-assistant-alert-triage.asciidoc[leveloffset=+3] +include::./AI-for-security/ai-assistant-esql-queries.asciidoc[leveloffset=+3] + +include::./ingest/ingest-data.asciidoc[leveloffset=+1] +include::./ingest/threat-intelligence.asciidoc[leveloffset=+2] +include::./ingest/auto-import.asciidoc[leveloffset=+2] + +include::./edr-install-config/endpoint-protection-intro.asciidoc[leveloffset=+1] +include::./edr-install-config/deploy-endpoint-reqs.asciidoc[leveloffset=+2] +include::./edr-install-config/install-elastic-defend.asciidoc[leveloffset=+2] +include::./edr-install-config/deploy-endpoint-macos-cat-mont.asciidoc[leveloffset=+3] +include::./edr-install-config/deploy-endpoint-macos-ven.asciidoc[leveloffset=+3] +include::./edr-install-config/deploy-with-mdm.asciidoc[leveloffset=+3] +include::./edr-install-config/agent-tamper-protection.asciidoc[leveloffset=+3] +include::./edr-install-config/defend-feature-privs.asciidoc[leveloffset=+2] +include::./edr-install-config/configure-endpoint-integration-policy.asciidoc[leveloffset=+2] +include::./edr-install-config/artifact-control.asciidoc[leveloffset=+3] +include::./edr-install-config/endpoint-diagnostic-data.asciidoc[leveloffset=+3] +include::./edr-install-config/self-healing-rollback.asciidoc[leveloffset=+3] +include::./edr-install-config/linux-file-monitoring.asciidoc[leveloffset=+3] +include::./edr-install-config/endpoint-data-volume.asciidoc[leveloffset=+3] +include::./edr-install-config/uninstall-agent.asciidoc[leveloffset=+2] + +include::./edr-manage/manage-endpoint-protection.asciidoc[leveloffset=+1] +include::./edr-manage/endpoints-page.asciidoc[leveloffset=+2] +include::./edr-manage/policies-page-ov.asciidoc[leveloffset=+2] +include::./edr-manage/trusted-apps-ov.asciidoc[leveloffset=+2] +include::./edr-manage/event-filters.asciidoc[leveloffset=+2] +include::./edr-manage/host-isolation-exceptions.asciidoc[leveloffset=+2] +include::./edr-manage/blocklist.asciidoc[leveloffset=+2] +include::./edr-manage/optimize-edr.asciidoc[leveloffset=+2] +include::./edr-manage/endpoint-event-capture.asciidoc[leveloffset=+2] +include::./edr-manage/allowlist-endpoint-3rd-party-av.asciidoc[leveloffset=+2] +include::./edr-manage/endpoint-self-protection.asciidoc[leveloffset=+2] +include::./edr-manage/endpoint-command-ref.asciidoc[leveloffset=+2] + +include::./endpoint-response-actions/response-actions.asciidoc[leveloffset=+1] +include::./endpoint-response-actions/automated-response-actions.asciidoc[leveloffset=+2] +include::./endpoint-response-actions/host-isolation-ov.asciidoc[leveloffset=+2] +include::./endpoint-response-actions/response-actions-history.asciidoc[leveloffset=+2] +include::./endpoint-response-actions/third-party-actions.asciidoc[leveloffset=+2] +include::./endpoint-response-actions/response-actions-config.asciidoc[leveloffset=+2] + +include::./cloud-native-security/cloud-native-security-overview.asciidoc[leveloffset=+1] +include::./cloud-native-security/security-posture-management.asciidoc[leveloffset=+2] +include::./cloud-native-security/enable-cloudsec.asciidoc[leveloffset=+2] +include::./cloud-native-security/cspm.asciidoc[leveloffset=+2] +include::./cloud-native-security/cspm-get-started.asciidoc[leveloffset=+3] +include::./cloud-native-security/cspm-get-started-gcp.asciidoc[leveloffset=+3] +include::./cloud-native-security/cspm-get-started-azure.asciidoc[leveloffset=+3] +include::./cloud-native-security/cspm-findings-page.asciidoc[leveloffset=+3] +include::./cloud-native-security/benchmark-rules.asciidoc[leveloffset=+3] +include::./dashboards/cloud-posture-dashboard-dash.asciidoc[leveloffset=+3] +include::./cloud-native-security/cspm-security-posture-faq.asciidoc[leveloffset=+3] +include::./cloud-native-security/kspm.asciidoc[leveloffset=+2] +include::./cloud-native-security/get-started-with-kspm.asciidoc[leveloffset=+3] +// include::./cloud-native-security/cspm-findings-page.asciidoc[leveloffset=+3] +// include::./cloud-native-security/benchmark-rules.asciidoc[leveloffset=+3] +// include::./dashboards/cloud-posture-dashboard-dash.asciidoc[leveloffset=+3] +include::./cloud-native-security/security-posture-faq.asciidoc[leveloffset=+3] +include::./cloud-native-security/vuln-management-overview.asciidoc[leveloffset=+2] +include::./cloud-native-security/vuln-management-get-started.asciidoc[leveloffset=+3] +include::./cloud-native-security/vuln-management-findings.asciidoc[leveloffset=+3] +// include::./dashboards/vuln-management-dashboard-dash.asciidoc[leveloffset=+3] +include::./cloud-native-security/vuln-management-faq.asciidoc[leveloffset=+3] +include::./cloud-native-security/d4c-overview.asciidoc[leveloffset=+2] +include::./cloud-native-security/d4c-get-started.asciidoc[leveloffset=+3] +include::./cloud-native-security/d4c-policy-guide.asciidoc[leveloffset=+3] +// include::./dashboards/kubernetes-dashboard-dash.asciidoc[leveloffset=+3] +include::./cloud-native-security/cloud-workload-protection.asciidoc[leveloffset=+2] +include::./cloud-native-security/environment-variable-capture.asciidoc[leveloffset=+3] + +include::./explore/explore-your-data.asciidoc[leveloffset=+1] +include::./explore/hosts-overview.asciidoc[leveloffset=+2] +include::./explore/network-page-overview.asciidoc[leveloffset=+2] +include::./explore/conf-map-ui.asciidoc[leveloffset=+3] +include::./explore/users-page.asciidoc[leveloffset=+2] +include::./explore/data-views-in-sec.asciidoc[leveloffset=+2] +include::./explore/runtime-fields.asciidoc[leveloffset=+2] +include::./explore/siem-field-reference.asciidoc[leveloffset=+2] + +include::./dashboards/dashboards-overview.asciidoc[leveloffset=+1] +include::./dashboards/overview-dashboard.asciidoc[leveloffset=+2] +include::./dashboards/detection-response-dashboard.asciidoc[leveloffset=+2] +include::./dashboards/kubernetes-dashboard-dash.asciidoc[leveloffset=+2] +// include::./dashboards/cloud-posture-dashboard-dash.asciidoc[leveloffset=+2] +include::./dashboards/detection-entity-dashboard.asciidoc[leveloffset=+2] +include::./dashboards/data-quality-dash.asciidoc[leveloffset=+2] +include::./dashboards/vuln-management-dashboard-dash.asciidoc[leveloffset=+2] +include::./dashboards/rule-monitoring-dashboard.asciidoc[leveloffset=+2] + +include::./rules/detection-engine-overview.asciidoc[leveloffset=+1] +include::./rules/detections-permissions-section.asciidoc[leveloffset=+2] + +include::./rules/about-rules.asciidoc[leveloffset=+1] +include::./rules/rules-ui-create.asciidoc[leveloffset=+2] +include::./rules/interactive-investigation-guides.asciidoc[leveloffset=+3] +include::./rules/building-block-rule.asciidoc[leveloffset=+3] +include::./rules/prebuilt-rules/prebuilt-rules-management.asciidoc[leveloffset=+2] +include::./rules/rules-ui-management.asciidoc[leveloffset=+2] +include::./rules/alerts-ui-monitor.asciidoc[leveloffset=+2] +include::./rules/detections-ui-exceptions.asciidoc[leveloffset=+2] +include::./rules/value-lists-exceptions.asciidoc[leveloffset=+3] +include::./rules/add-exceptions.asciidoc[leveloffset=+3] +include::./rules/shared-exception-lists.asciidoc[leveloffset=+3] +include::./rules/rules-coverage.asciidoc[leveloffset=+2] +include::./rules/tuning-detection-signals.asciidoc[leveloffset=+2] +include::./rules/prebuilt-rules/prebuilt-rules.asciidoc[leveloffset=+2] + +include::./alerts/alerts-ui-manage.asciidoc[leveloffset=+1] +include::./alerts/visualize-alerts.asciidoc[leveloffset=+2] +include::./alerts/view-alert-details.asciidoc[leveloffset=+2] +include::./alerts/signals-to-cases.asciidoc[leveloffset=+2] +include::./alerts/alert-suppression.asciidoc[leveloffset=+2] +include::./alerts/reduce-notifications-alerts.asciidoc[leveloffset=+2] +include::./alerts/query-alert-indices.asciidoc[leveloffset=+2] +include::./alerts/alert-schema.asciidoc[leveloffset=+2] + +include::./advanced-entity-analytics/advanced-entity-analytics-overview.asciidoc[leveloffset=+1] +include::./advanced-entity-analytics/entity-risk-scoring.asciidoc[leveloffset=+2] +include::./advanced-entity-analytics/ers-req.asciidoc[leveloffset=+3] +include::./advanced-entity-analytics/asset-criticality.asciidoc[leveloffset=+3] +include::./advanced-entity-analytics/turn-on-risk-engine.asciidoc[leveloffset=+3] +include::./advanced-entity-analytics/analyze-risk-score-data.asciidoc[leveloffset=+3] +include::./advanced-entity-analytics/advanced-behavioral-detections.asciidoc[leveloffset=+2] +include::./advanced-entity-analytics/ml-requirements.asciidoc[leveloffset=+3] +include::./advanced-entity-analytics/machine-learning.asciidoc[leveloffset=+3] +include::./advanced-entity-analytics/tuning-anomaly-results.asciidoc[leveloffset=+3] +include::./advanced-entity-analytics/behavioral-detection-use-cases.asciidoc[leveloffset=+3] +include::./advanced-entity-analytics/prebuilt-ml-jobs.asciidoc[leveloffset=+3] + +include::./investigate/investigate-events.asciidoc[leveloffset=+1] +include::./investigate/timelines-ui.asciidoc[leveloffset=+2] +include::./investigate/timeline-templates-ui.asciidoc[leveloffset=+3] +include::./investigate/timeline-object-schema.asciidoc[leveloffset=+3] +include::./alerts/visual-event-analyzer.asciidoc[leveloffset=+2] +include::./cloud-native-security/session-view.asciidoc[leveloffset=+2] +include::./osquery/use-osquery.asciidoc[leveloffset=+2] +include::./osquery/osquery-response-action.asciidoc[leveloffset=+3] +include::./osquery/invest-guide-run-osquery.asciidoc[leveloffset=+3] +include::./osquery/alerts-run-osquery.asciidoc[leveloffset=+3] +include::./osquery/view-osquery-results.asciidoc[leveloffset=+3] +include::./osquery/osquery-placeholder-fields.asciidoc[leveloffset=+3] +include::./investigate/indicators-of-compromise.asciidoc[leveloffset=+2] +include::./investigate/cases-overview.asciidoc[leveloffset=+2] +include::./investigate/case-permissions.asciidoc[leveloffset=+3] +include::./investigate/cases-open-manage.asciidoc[leveloffset=+3] +include::./investigate/cases-settings.asciidoc[leveloffset=+3] + +include::./assets/asset-management.asciidoc[leveloffset=+1] + +include::./settings/manage-settings.asciidoc[leveloffset=+1] +include::./settings/project-settings.asciidoc[leveloffset=+2] +include::./settings/advanced-settings.asciidoc[leveloffset=+2] + +include::./troubleshooting/troubleshooting-intro.asciidoc[leveloffset=+1] +include::./troubleshooting/ts-detection-rules.asciidoc[leveloffset=+2] +include::./troubleshooting/troubleshoot-endpoints.asciidoc[leveloffset=+2] + +include::./technical-preview-limitations.asciidoc[leveloffset=+1] diff --git a/docs/serverless/ingest/auto-import.asciidoc b/docs/serverless/ingest/auto-import.asciidoc new file mode 100644 index 0000000000..8a51cd8b08 --- /dev/null +++ b/docs/serverless/ingest/auto-import.asciidoc @@ -0,0 +1,89 @@ +[[automatic-import]] += Automatic Import + +:description: Use Automatic Import to quickly normalize and ingest third-party data. +:keywords: serverless, security, how-to + +preview:[] + +.Technical preview +[IMPORTANT] +==== +This feature is in technical preview. It may change in the future, and you should exercise caution when using it in production environments. Elastic will work to fix any issues, but features in technical preview are not subject to the support SLA of GA features. +==== + +Automatic Import helps you quickly parse, ingest, and create https://www.elastic.co/elasticsearch/common-schema[ECS mappings] for data from sources that don't yet have prebuilt Elastic integrations. This can accelerate your migration to {elastic-sec}, and help you quickly add new data sources to an existing SIEM solution in {elastic-sec}. Automatic Import uses a large language model (LLM) with specialized instructions to quickly analyze your source data and create a custom integration. + +While Elastic has 400+ {integrations-docs}[prebuilt data integrations], Automatic Import helps you extend data coverage to other security-relevant technologies and applications. Elastic integrations (including those created by Automatic Import) normalize data to https://www.elastic.co/guide/en/ecs/current/ecs-reference.html[the Elastic Common Schema (ECS)], which creates uniformity across dashboards, search, alerts, machine learning, and more. + +[TIP] +==== +Click https://elastic.navattic.com/automatic-import[here] to access an interactive demo that shows the feature in action, before setting it up yourself. +==== + +.Requirements +[NOTE] +==== +* A working <>. Automatic Import currently works with all variants of Claude 3. Other models are not supported in this technical preview, but will be supported in future versions. +* A https://www.elastic.co/pricing/serverless-security[Security Analytics Complete] subscription. +* A sample of the data you want to import, in JSON or NDJSON format. +==== + +[IMPORTANT] +==== +Using Automatic Import allows users to create new third-party data integrations through the use of third-party generative AI models (“GAI models”). Any third-party GAI models that you choose to use are owned and operated by their respective providers. Elastic does not own or control these third-party GAI models, nor does it influence their design, training, or data-handling practices. Using third-party GAI models with Elastic solutions, and using your data with third-party GAI models is at your discretion. Elastic bears no responsibility or liability for the content, operation, or use of these third-party GAI models, nor for any potential loss or damage arising from their use. Users are advised to exercise caution when using GAI models with personal, sensitive, or confidential information, as data submitted may be used to train the models or for other purposes. Elastic recommends familiarizing yourself with the development practices and terms of use of any third-party GAI models before use. + +You are responsible for ensuring that your use of Automatic Import complies with the terms and conditions of any third-party platform you connect with. +==== + +[discrete] +[[automatic-import-create-a-new-custom-integration]] +== Create a new custom integration + +. In {elastic-sec}, click **Add integrations**. +. Under **Can't find an integration?** click **Create new integration**. ++ +[role="screenshot"] +image:images/auto-import-create-new-integration-button.png[The Integrations page with the Create new integration button highlighted] +. Click **Create integration**. +. Select an <>. +. Define how your new integration will appear on the Integrations page by providing a **Title**, **Description**, and **Logo**. Click **Next**. +. Define your integration's package name, which will prefix the imported event fields. +. Define your **Data stream title**, **Data stream description**, and **Data stream name**. These fields appear on the integration's configuration page to help identify the data stream it writes to. +. Select your https://www.elastic.co/guide/en/beats/filebeat/current/configuration-filebeat-options.html[**Data collection method**]. This determines how your new integration will ingest the data (for example, from an S3 bucket, an HTTP endpoint, or a file stream). +. Upload a sample of your data in JSON or NDJSON format. Make sure to include all the types of events that you want the new integration to handle. + +.Best practices for sample data +[NOTE] +==== +* The file extension (`.JSON` or `.NDJSON`) must match the file format. +* Only the first 10 events in the sample are analyzed. In this technical preview, additional data is truncated. +* Ensure each JSON or NDJSON object represents an event, and avoid deeply nested object structures. +* The more variety in your sample, the more accurate the pipeline will be (for example, include 10 unique log entries instead of the same type of entry 10 times). +* Ideally, each field name should describe what the field does. +==== + +. Click **Analyze logs**, then wait for processing to complete. This may take several minutes. +. After processing is complete, the pipeline's field mappings appear, including ECS and custom fields. ++ +[role="screenshot"] +image:images/auto-import-review-integration-page.png[The Automatic Import Review page showing proposed field mappings] +. (Optional) After reviewing the proposed pipeline, you can fine-tune it by clicking **Edit pipeline**. Refer to the https://www.elastic.co/guide/en/security/current/siem-field-reference.html[{elastic-sec} ECS reference] to learn more about formatting field mappings. When you're satisfied with your changes, click **Save**. ++ +[role="screenshot"] +image:images/auto-import-edit-pipeline.gif[A gif showing the user clicking the edit pipeline button and viewing the ingest pipeline flyout] +. Click **Add to Elastic**. After the **Success** message appears, your new integration will be available on the Integrations page. ++ +[role="screenshot"] +image:images/auto-import-success-message.png[The Automatic Import success message] +. Click **Add to an agent** to deploy your new integration and start collecting data, or click **View integration** to view detailed information about your new integration. + +[NOTE] +==== +Once you've added an integration, you can't edit any details other than the ingest pipeline, which you can edit by going to **Project Settings → Stack Management → Ingest Pipelines**. +==== + +[TIP] +==== +You can use the <> to check the health of your data ingest pipelines and field mappings. +==== diff --git a/docs/serverless/ingest/ingest-data.asciidoc b/docs/serverless/ingest/ingest-data.asciidoc new file mode 100644 index 0000000000..a10e5af015 --- /dev/null +++ b/docs/serverless/ingest/ingest-data.asciidoc @@ -0,0 +1,134 @@ +[[ingest-data]] += Ingest data to Elastic Security + +:description: Learn how to add your own data to {elastic-sec}. +:keywords: serverless, security, how-to + +++++ +Ingest data +++++ + +preview:[] + +To ingest data, you can use: + +* The {fleet-guide}/fleet-overview.html[{agent}] with the **{elastic-defend}** integration, which protects +your hosts and sends logs, metrics, and endpoint security data to {elastic-sec}. See <>. +* The {agent} with other integrations, which are available in the {fleet-guide}/fleet-overview.html#package-registry-intro[Elastic Package Registry (EPR)]. To install an integration that works with {elastic-sec}, select **Add integrations** in the toolbar on most pages. On the **Integrations** page, select the **Security** category filter, then select an integration to view the installation instructions. For more information on integrations, refer to {integrations-docs}[{integrations}]. +* **{beats}** shippers installed for each system you want to monitor. +* The {agent} to send data from Splunk to {elastic-sec}. See {observability-guide}/splunk-get-started.html[Get started with data from Splunk]. +* Third-party collectors configured to ship ECS-compliant data. <> provides a list of ECS fields used in {elastic-sec}. + +[IMPORTANT] +==== +If you use a third-party collector to ship data to {elastic-sec}, you must +map its fields to the {ecs-ref}[Elastic Common Schema (ECS)]. Additionally, +you must add its index to the {elastic-sec} indices (update the **`securitySolution:defaultIndex`** <>). + +{elastic-sec} uses the {ecs-ref}/ecs-host.html[`host.name`] ECS field as the +primary key for identifying hosts. +==== + +The {agent} with the +https://www.elastic.co/products/endpoint-security[{elastic-defend} integration] +ships these data sources: + +* Process - Linux, macOS, Windows +* Network - Linux, macOS, Windows +* File - Linux, macOS, Windows +* DNS - Windows +* Registry - Windows +* DLL and Driver Load - Windows +* Security - Windows + +[discrete] +[[install-beats]] +== Install {beats} shippers + +To add hosts and populate {elastic-sec} with network security events, you need to install and +configure Beats on the hosts from which you want to ingest security events: + +* https://www.elastic.co/products/beats/filebeat[{filebeat}] for forwarding and +centralizing logs and files +* https://www.elastic.co/products/beats/auditbeat[{auditbeat}] for collecting security events +* https://www.elastic.co/products/beats/winlogbeat[{winlogbeat}] for centralizing +Windows event logs +* https://www.elastic.co/products/beats/packetbeat[{packetbeat}] for analyzing +network activity + +You can install {beats} using the UI guide or directly from the command line. + +[discrete] +[[ingest-data-install-beats-using-the-ui-guide]] +=== Install {beats} using the UI guide + +When you add integrations that use {beats}, you're guided through the {beats} installation process. To begin, go to the **Integrations** page (select **Add integrations** in the toolbar on most pages), and then follow the links for the types of data you want to collect. + +[TIP] +==== +On the Integrations page, you can select the **Beats only** filter to only view integrations using Beats. +==== + +[discrete] +[[ingest-data-download-and-install-beats-from-the-command-line]] +=== Download and install {beats} from the command line + +To install {beats}, see these installation guides: + +* {filebeat-ref}/filebeat-installation-configuration.html[{filebeat} quick start] +* {auditbeat-ref}/auditbeat-installation-configuration.html[{auditbeat} quick start] +* {winlogbeat-ref}/winlogbeat-installation-configuration.html[{winlogbeat} quick start] +* {packetbeat-ref}/packetbeat-installation-configuration.html[{packetbeat} quick start] + +[discrete] +[[enable-beat-modules]] +=== Enable modules and configuration options + +No matter how you installed {beats}, you need to enable modules in {auditbeat} +and {filebeat} to populate {elastic-sec} with data. + +[TIP] +==== +For a full list of security-related beat modules, +https://www.elastic.co/integrations?solution=security[click here]. +==== + +To populate **Hosts** data, enable these modules: + +* {auditbeat-ref}/auditbeat-module-system.html[Auditbeat system module - Linux, macOS, +Windows]: ++ +** packages +** processes +** logins +** sockets +** users and groups +* {auditbeat-ref}/auditbeat-module-auditd.html[Auditbeat auditd module - Linux kernel audit events] +* {auditbeat-ref}/auditbeat-module-file_integrity.html[Auditbeat file integrity +module - Linux, macOS, Windows] +* {filebeat-ref}/filebeat-module-system.html[Filebeat system module - Linux +system logs] +* {filebeat-ref}/filebeat-module-santa.html[Filebeat Santa module - macOS +security events] +* {winlogbeat-ref}/_winlogbeat_overview.html[Winlogbeat - Windows event logs] + +To populate **Network** data, enable Packetbeat protocols and Filebeat modules: + +* {packetbeat-ref}/packetbeat-overview.html[{packetbeat}] ++ +** {packetbeat-ref}/packetbeat-dns-options.html[DNS] +** {packetbeat-ref}/configuration-tls.html[TLS] +** {packetbeat-ref}/configuration-protocols.html[Other supported protocols] +* {filebeat-ref}/filebeat-overview.html[{filebeat}] ++ +** {filebeat-ref}/filebeat-module-zeek.html[Zeek NMS module] +** {filebeat-ref}/filebeat-module-suricata.html[Suricata IDS module] +** {filebeat-ref}/filebeat-module-iptables.html[Iptables/Ubiquiti module] +** {filebeat-ref}/filebeat-module-coredns.html[CoreDNS module] +** {filebeat-ref}/filebeat-module-envoyproxy.html[Envoy proxy module (Kubernetes)] +** {filebeat-ref}/filebeat-module-panw.html[Palo Alto Networks firewall module] +** {filebeat-ref}/filebeat-module-cisco.html[Cisco ASA firewall module] +** {filebeat-ref}/filebeat-module-aws.html[AWS module] +** {filebeat-ref}/filebeat-module-cef.html[CEF module] +** {filebeat-ref}/filebeat-module-googlecloud.html[Google Cloud module] +** {filebeat-ref}/filebeat-module-netflow.html[NetFlow module] diff --git a/docs/serverless/ingest/threat-intelligence.asciidoc b/docs/serverless/ingest/threat-intelligence.asciidoc new file mode 100644 index 0000000000..73c5840a9a --- /dev/null +++ b/docs/serverless/ingest/threat-intelligence.asciidoc @@ -0,0 +1,74 @@ +[[threat-intelligence]] += Enable threat intelligence integrations + +:description: Use threat indicators to detect known threats and malicious activity. +:keywords: serverless, security, how-to + +preview:[] + +The Threat Intelligence view provides a streamlined way to collect threat intelligence data that you can use for threat detection and matching. Threat intelligence data consists of <> ingested from third-party threat intelligence sources. + +Threat indicators describe potential threats, unusual behavior, or malicious activity on a network or in an environment. They are commonly used in indicator match rules to detect and match known threats. When an indicator match rule generates an alert, it includes information about the matched threat indicator. + +[NOTE] +==== +To learn more about alerts with threat intelligence, visit <>. +==== + +Refer to the following sections to learn how to connect to threat intelligence sources using an <>, the <>, or a <>. + +[role="screenshot"] +image::images/es-threat-intel-integrations/-getting-started-threat-intelligence-view.png[The Threat Intelligence view on the Overview dashboard] + +There are a few scenarios when data won't display in the Threat Intelligence view: + +* If you've chosen a time range that doesn't contain threat indicator event data, you are prompted to choose a different range. Use the date and time picker in the {security-app} to select a new range to analyze. +* If the {agent} or {filebeat} agent hasn't ingested Threat Intel module data yet, the threat indicator event counts won't load. You can wait for data to be ingested or reach out to your administrator for help resolving this. + +[discrete] +[[agent-ti-integration]] +== Add an {agent} integration + +. Install a {fleet-guide}/install-fleet-managed-elastic-agent.html[{fleet}-managed {agent}] on the hosts you want to monitor. +. In the Threat Intelligence view, click **Enable sources** to view the Integrations page. Scroll down and select **Elastic Agent only** to filter by {agent} integrations. ++ +[TIP] +==== +If you know the name of {agent} integration you want to install, you can search for it directly. Alternatively, choose the **Threat Intelligence** category to display a list of available {integrations-docs}/threat-intelligence-intro[threat intelligence integrations]. +==== +. Select an {agent} integration, then complete the installation steps. +. Return to the Threat Intelligence view on the Overview dashboard. If indicator data isn't displaying, refresh the page or refer to these <>. + +[discrete] +[[ti-mod-integration]] +== Add a {filebeat} Threat Intel module integration + +. Set up the {filebeat-ref}/filebeat-installation-configuration.html[{filebeat} agent] and enable the Threat Intel module. ++ +[NOTE] +==== +For more information about enabling available threat intelligence filesets, refer to {filebeat-ref}/filebeat-module-threatintel.html[Threat Intel module]. +==== +. Update the `securitySolution:defaultThreatIndex` <> by adding the appropriate index pattern name after the default {fleet} threat intelligence index pattern (`logs-ti*`): ++ +.. If you're _only_ using {filebeat} version 8.x, add the appropriate {filebeat} threat intelligence index pattern. For example, `logs-ti*`, `filebeat-8*`. +.. If you're using a previous version of Filebeat _and_ a current one, differentiate between the threat intelligence indices by using unique index pattern names. For example, if you’re using {filebeat} version 7.0.0 and 8.0.0, update the setting to `logs-ti*`,`filebeat-7*`,`filebeat-8*`. +. Return to the Threat Intelligence view on the Overview dashboard. Refresh the page if indicator data isn't displaying. + +[discrete] +[[custom-ti-integration]] +== Add a custom integration + +. Set up a way to <> into your system. +. Update the `securitySolution:defaultThreatIndex` <> by adding the appropriate index pattern name after the default {fleet} threat intelligence index pattern (`logs-ti*`), for example, `logs-ti*`,`custom-ti-index*`. ++ +[NOTE] +==== +Threat intelligence indices aren’t required to be ECS compatible. However, we strongly recommend compatibility if you’d like your alerts to be enriched with relevant threat indicator information. You can find a list of ECS-compliant threat intelligence fields at {ecs-ref}/ecs-threat.html[Threat Fields]. +==== +. Return to the Threat Intelligence view on the Overview dashboard (**Dashboards** → **Overview**). Refresh the page if indicator data isn't displaying. ++ +[NOTE] +==== +The Threat Intelligence view searches for a `threat.feed.name` field value to define the source name in the **Name** column. If a custom source doesn't have the `threat.feed.name` field or hasn't defined a `threat.feed.name` field value, it's considered unnamed and labeled as **Other**. Dashboards aren't created for unnamed sources unless the `threat.feed.dashboard_id` field is defined. +==== diff --git a/docs/serverless/ingest/threat-intelligence.mdx b/docs/serverless/ingest/threat-intelligence.mdx index 8bc9710f2b..c04e6644b5 100644 --- a/docs/serverless/ingest/threat-intelligence.mdx +++ b/docs/serverless/ingest/threat-intelligence.mdx @@ -17,7 +17,7 @@ Threat indicators describe potential threats, unusual behavior, or malicious act To learn more about alerts with threat intelligence, visit View alert details. -Refer to the following sections to learn how to connect to threat intelligence sources using an ((agent)) integration, the Threat Intel module, or a custom integration. +Refer to the following sections to learn how to connect to threat intelligence sources using an ((agent)) integration, the Threat Intel module, or a custom integration. diff --git a/docs/serverless/investigate/case-permissions.asciidoc b/docs/serverless/investigate/case-permissions.asciidoc new file mode 100644 index 0000000000..d1e0f9a297 --- /dev/null +++ b/docs/serverless/investigate/case-permissions.asciidoc @@ -0,0 +1,58 @@ +[[cases-requirements]] += Cases requirements + +:description: Requirements for using and managing cases. +:keywords: serverless, security, reference, manage + +preview:[] + +To access cases, you need either the appropriate https://www.elastic.co/docs/current/serverless/general/assign-user-roles[predefined Security user role] or a https://www.elastic.co/docs/current/serverless/custom-roles[custom role] with the right privileges. + +You can create custom roles and define feature privileges at different levels to manage feature access in {kib}. {kib} privileges grant access to features within a specified {kib} space, and you can grant full or partial access. For more information, refer to https://www.elastic.co/docs/current/serverless/custom-roles[]. + +[NOTE] +==== +To send cases to external systems, you need the Security Analytics Complete https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature]. +==== + +[IMPORTANT] +==== +Certain feature tiers and roles might be required to manage case attachments. For example, to add alerts to cases, you must have a role that allows <>. +==== + +To grant access to cases in a custom role, set the privileges for the **Cases** and **{connectors-feature}** features as follows: + +|=== +| Action | {kib} Privileges + +| Give full access to manage cases and settings +a| * **All** for the **Cases** feature under **Security** +* **All** for the **{connectors-feature}** feature under **Management** + +[NOTE] +==== +Roles without **All** privileges for the **{connectors-feature}** feature cannot create, add, delete, or modify case connectors. + +By default, **All** for the **Cases** feature allows you to delete cases, delete alerts and comments from cases, and edit case settings. You can customize the sub-feature privileges to limit feature access. +==== + +| Give assignee access to cases +a| **All** for the **Cases** feature under **Security** + +[NOTE] +==== +Before a user can be assigned to a case, they must log into {kib} at least +once, which creates a user profile. +==== + +| Give view-only access for cases +a| **Read** for the **Security** feature and **All** for the **Cases** feature + +[NOTE] +==== +You can customize the sub-feature privileges to allow access to deleting cases, deleting alerts and comments from cases, and viewing or editing case settings. +==== + +| Revoke all access to cases +| **None** for the **Cases** feature under **Security** +|=== diff --git a/docs/serverless/investigate/cases-open-manage.asciidoc b/docs/serverless/investigate/cases-open-manage.asciidoc new file mode 100644 index 0000000000..d0eafeb4be --- /dev/null +++ b/docs/serverless/investigate/cases-open-manage.asciidoc @@ -0,0 +1,290 @@ +[[cases-open-manage]] += Create and manage cases + +:description: Create a case in {elastic-sec}, and add files and visualizations. +:keywords: serverless, security, how-to, analyze, manage + +preview:[] + +You can create and manage cases using the UI or the {security-guide}/cases-api-overview.html[Cases API]. + +// Link to classic docs until serverless API docs are available. + +[discrete] +[[cases-ui-open]] +== Open a new case + +Open a new case to keep track of security issues and share their details with +colleagues. + +. Go to **Cases**, then click **Create case**. If no cases exist, the Cases table will be empty and you'll be prompted to create one by clicking the **Create case** button inside the table. +. (Optional) If you defined <>, select one to use its default field values. preview:[] +. Give the case a name, assign a severity level, and provide a description. You can use +https://www.markdownguide.org/cheat-sheet[Markdown] syntax in the case description. ++ +[NOTE] +==== +If you do not assign your case a severity level, it will be assigned **Low** by default. +==== ++ +[TIP] +==== +You can insert a Timeline link in the case description by clicking the Timeline icon (image:images/icons/timeline.svg[Timeline]). +==== +. Optionally, add a category, assignees and relevant tags. You can add users only if they meet the necessary <>. +. If you defined <>, they appear in the **Additional fields** section. +. Choose if you want alert statuses to sync with the case's status after they are added to the case. This option is enabled by default, but you can turn it off after creating the case. +. From **External incident management**, select a <>. If you've previously added one, that connector displays as the default selection. Otherwise, the default setting is `No connector selected`. +. Click **Create case**. ++ +[NOTE] +==== +If you've selected a connector for the case, the case is automatically pushed to the third-party system it's connected to. +==== + +[role="screenshot"] +image::images/cases-open-manage/-cases-cases-ui-open.png[Shows an open case] + +// NOTE: This is an autogenerated screenshot. Do not edit it directly. + +//// +/* +This functionality does not exist yet in serverless. +To be updated: references to Kibana, ESS. Once this section is added back in, edit the frontmatter description back to: Create a case in {elastic-sec}, configure email notifications, and add files and visualizations. + +## Add email notifications + +You can configure email notifications that occur when users are assigned to cases. + +For hosted {kib} on {ess}: + +1. Add the email addresses to the monitoring email allowlist. Follow the steps in + [Send alerts by email]{(cloud}/ec-watcher.html#ec-watcher-allowlist). + + You do not need to take any more steps to configure an email connector or update + {kib} user settings, since the preconfigured Elastic-Cloud-SMTP connector is + used by default. + +For self-managed {kib}: + +1. Create a preconfigured email connector. + + + At this time, email notifications support only [preconfigured email connectors]{(kibana-ref}/pre-configured-connectors.html), + which are defined in the `kibana.yml` file. + + +1. Set the `notifications.connectors.default.email` {kib} setting to the name of + your email connector. + +1. If you want the email notifications to contain links back to the case, you + must configure the [server.publicBaseUrl]{(kibana-ref}/settings.html#server-publicBaseUrl) setting. + +When you subsequently add assignees to cases, they receive an email. + +
*/ +//// + +[discrete] +[[cases-open-manage-manage-existing-cases]] +== Manage existing cases + +From the Cases page, you can search existing cases and filter them by attributes such as assignees, categories, severity, status, and tags. You can also select multiple cases and use bulk actions to delete cases or change their attributes. General case metrics, including how long it takes to close cases, are provided above the table. + +[role="screenshot"] +image::images/cases-open-manage/-cases-cases-home-page.png[Case UI Home] + +// NOTE: This is an autogenerated screenshot. Do not edit it directly. + +To explore a case, click on its name. You can then: + +* <> +* <> ++ +[TIP] +==== +Comments can contain Markdown. For syntax help, click the Markdown icon (image:images/cases-open-manage/-detections-markdown-icon.png[Click markdown icon,17,17]) in the bottom right of the comment. +==== +* Examine <> and <> attached to the case +* <> +* <> +* Modify the case's description, assignees, category, severity, status, and tags. +* Manage connectors and send updates to external systems (if you've added a connector to the case) +* <> +* Refresh the case to retrieve the latest updates + +[discrete] +[[cases-summary]] +=== Review the case summary + +Click on an existing case to access its summary. The case summary, located under the case title, contains metrics that summarize alert information and response times. These metrics update when you attach additional unique alerts to the case, add connectors, or modify the case's status: + +* **Total alerts**: Total number of unique alerts attached to the case +* **Associated users**: Total number of unique users that are represented in the attached alerts +* **Associated hosts**: Total number of unique hosts that are represented in the attached alerts +* **Total connectors**: Total number of connectors that have been added to the case +* **Case created**: Date and time that the case was created +* **Open duration**: Time elapsed since the case was created +* **In progress duration**: How long the case has been in the `In progress` state +* **Duration from creation to close**: Time elapsed from when the case was created to when it was closed + +[role="screenshot"] +image::images/cases-open-manage/-cases-cases-summary.png[Shows you a summary of the case] + +[discrete] +[[cases-manage-comments]] +=== Manage case comments + +To edit, delete, or quote a comment, select the appropriate option from the **More actions** menu (image:images/icons/boxesHorizontal.svg[More actions]). + +[role="screenshot"] +image::images/cases-open-manage/-cases-cases-manage-comments.png[Shows you a summary of the case] + +[discrete] +[[cases-examine-alerts]] +=== Examine alerts attached to a case + +To explore the alerts attached to a case, click the **Alerts** tab. In the table, alerts are organized from oldest to newest. To <>, click the **View details** button. + +[role="screenshot"] +image::images/cases-open-manage/-cases-cases-alert-tab.png[Shows you the Alerts tab] + +[NOTE] +==== +Each case can have a maximum of 1,000 alerts. +==== + +[discrete] +[[cases-add-files]] +=== Add files + +To upload files to a case, click the **Files** tab: + +[role="screenshot"] +image::images/cases-open-manage/-cases-cases-files.png[A list of files attached to a case] + +// NOTE: This is an autogenerated screenshot. Do not edit it directly. + +You can add images and text, CSV, JSON, PDF, or ZIP files. +For the complete list, check https://github.com/elastic/kibana/blob/main/x-pack/plugins/cases/common/constants/mime_types.ts[mime_types.ts]. + +[NOTE] +==== +There is a 10 MiB size limit for images. For all other MIME types, the limit is 100 MiB. +==== + +To download or delete the file, or copy the file hash to your clipboard, open the **Actions** menu (**…**). +The available hash functions are MD5, SHA-1, and SHA-256. + +When you add a file, a comment is added to the case activity log. +To view an image, click its name in the activity or file list. + +[discrete] +[[cases-lens-visualization]] +=== Add a Lens visualization + +beta::[] + +Add a Lens visualization to your case to portray event and alert data through charts and graphs. + +[role="screenshot"] +image::images/cases-open-manage/-cases-add-vis-to-case.gif[Shows how to add a visualization to a case] + +To add a Lens visualization to a comment within your case: + +. Click the **Visualization** button. The **Add visualization** dialog appears. +. Select an existing visualization from your Visualize Library or create a new visualization. ++ +[IMPORTANT] +==== +Set an absolute time range for your visualization. This ensures your visualization doesn't change over time after you save it to your case, and provides important context for others managing the case. +==== +. Save the visualization to your Visualize Library by clicking the **Save to library** button (optional). ++ +.. Enter a title and description for the visualization. +.. Choose if you want to keep the **Update panel on Security** activated. This option is activated by default and automatically adds the visualization to your Visualize Library. +. After you've finished creating your visualization, click **Save and return** to go back to your case. +. Click **Preview** to show how the visualization will appear in the case comment. +. Click **Add Comment** to add the visualization to your case. + +Alternatively, while viewing a <> you can open a panel's menu then click **More actions** (image:images/icons/boxesHorizontal.svg[More actions]​) → **Add to existing case** or **More actions** (image:images/icons/boxesHorizontal.svg[More actions]​) → **Add to new case**. + +After a visualization has been added to a case, you can modify or interact with it by clicking the **Open Visualization** option in the case's comment menu. + +[role="screenshot"] +image::images/cases-open-manage/-cases-cases-open-vis.png[Shows where the Open Visualization option is] + +[discrete] +[[cases-copy-case-uuid]] +=== Copy the case UUID + +Each case has a universally unique identifier (UUID) that you can copy and share. To copy a case's UUID to a clipboard, go to the Cases page and select **Actions** → **Copy Case ID** for the case you want to share. Alternatively, go to a case's details page, then from the **More actions** menu (image:images/icons/boxesHorizontal.svg[More actions]), select **Copy Case ID**. + +[role="screenshot"] +image::images/cases-open-manage/-cases-cases-copy-case-id.png[Copy Case ID option in More actions menu 40%] + +[discrete] +[[cases-export-import]] +== Export and import cases + +Cases can be <> and <> as saved objects using the Saved Objects <> UI. + +[IMPORTANT] +==== +Before importing Lens visualizations, Timelines, or alerts, ensure their data is present. Without it, they won't work after being imported. +==== + +[discrete] +[[cases-export]] +=== Export a case + +Use the **Export** option to move cases between different {elastic-sec} instances. When you export a case, the following data is exported to a newline-delimited JSON (`.ndjson`) file: + +* Case details +* User actions +* Text string comments +* Case alerts +* Lens visualizations (exported as JSON blobs). + +[NOTE] +==== +The following attachments are _not_ exported: + +* **Case files**: Case files are not exported. However, they are accessible in **Project settings** → **Management** → **Files** to download and re-add. +* **Alerts**: Alerts attached to cases are not exported. You must re-add them after importing cases. +==== + +To export a case: + +. Go to **Project settings** → **Management** → **Saved objects**. +. Search for the case by choosing a saved object type or entering the case title in the search bar. +. Select one or more cases, then click the **Export** button. +. Click **Export**. A confirmation message that your file is downloading displays. ++ +[TIP] +==== +Keep the **Include related objects** option enabled to ensure connectors are exported too. +==== + +[role="screenshot"] +image::images/cases-open-manage/-cases-cases-export-button.png[Shows the export saved objects workflow] + +[discrete] +[[cases-import]] +=== Import a case + +To import a case: + +. Go to **Project settings** → **Management** → **Saved objects**. +. Click **Import**. +. Select the NDJSON file containing the exported case and configure the import options. +. Click **Import**. +. Review the import log and click **Done**. ++ +[IMPORTANT] +==== +Be mindful of the following: + +* If the imported case had connectors attached to it, you'll be prompted to re-authenticate the connectors. To do so, click **Go to connectors** on the **Import saved objects** flyout and complete the necessary steps. Alternatively, open the main menu, then go to **Project settings** → **Management** → **{connectors-ui}** to access connectors. +* If the imported case had attached alerts, verify that the alerts' source documents exist in the environment. Case features that interact with alerts (such as the Alert details flyout and rule details page) rely on the alerts' source documents to function. +==== diff --git a/docs/serverless/investigate/cases-overview.asciidoc b/docs/serverless/investigate/cases-overview.asciidoc new file mode 100644 index 0000000000..e48ced8c8f --- /dev/null +++ b/docs/serverless/investigate/cases-overview.asciidoc @@ -0,0 +1,25 @@ +[[cases-overview]] += Cases + +:description: Cases enable you to track investigation details about security issues. +:keywords: security, overview, analyze + +preview:[] + +Collect and share information about security issues by opening a case in {elastic-sec}. Cases allow you to track key investigation details, collect alerts in a central location, and more. The {elastic-sec} UI provides several ways to create and manage cases. Alternatively, you can use the {security-guide}/cases-api-overview.html[Cases API] to perform the same tasks. + +// Link to classic docs until serverless API docs are available. + +You can also send cases to these external systems by <>: + +* {sn-itsm} +* {sn-sir} +* {jira} (including Jira Service Desk) +* {ibm-r} +* {swimlane} +* {webhook-cm} + +[role="screenshot"] +image::images/cases-open-manage/-cases-cases-home-page.png[Case UI Home] + +// NOTE: This is an autogenerated screenshot. Do not edit it directly. diff --git a/docs/serverless/investigate/cases-settings.asciidoc b/docs/serverless/investigate/cases-settings.asciidoc new file mode 100644 index 0000000000..048f3b36b7 --- /dev/null +++ b/docs/serverless/investigate/cases-settings.asciidoc @@ -0,0 +1,126 @@ +[[cases-settings]] += Configure case settings + +:description: Change the default behavior of {security} cases by adding connectors, custom fields, templates, and closure options. +:keywords: serverless, security, how-to, configure + +preview:[] + +To access case settings in a {security} project, go to **Cases** → **Settings**. + +[role="screenshot"] +image::images/cases-settings/security-cases-settings.png[Shows the case settings page] + +// NOTE: This is an autogenerated screenshot. Do not edit it directly. + +[discrete] +[[cases-settings-case-closures]] +== Case closures + +If you close cases in your external incident management system, the cases will remain open in {elastic-sec} until you close them manually. + +To close cases when they are sent to an external system, select **Automatically close Security cases when pushing new incident to external system**. + +[discrete] +[[cases-settings-external-incident-management-systems]] +== External incident management systems + +You can push {elastic-sec} cases to these third-party systems: + +* {sn-itsm} +* {sn-sir} +* {jira} (including Jira Service Desk) +* {ibm-r} +* {swimlane} +* {hive} +* {webhook-cm} + +To push cases, you need to create a connector, which stores the information required to interact with an external system. After you have created a connector, you can set {elastic-sec} cases to automatically close when they are sent to external systems. + +.Requirements +[NOTE] +==== +To create connectors and send cases to external systems, you need the Security Analytics Complete https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature] and the appropriate user role. For more information, refer to <>. +==== + +To create a new connector + +. From the **Incident management system** list, select **Add new connector**. +. Select the system to send cases to: **{sn}**, **{jira}**, **{ibm-r}**, **{swimlane}**, **{hive}**, or **{webhook-cm}**. +. Enter your required settings. For connector configuration details, refer to: ++ +** {kibana-ref}/servicenow-action-type.html[{sn-itsm} connector] +** {kibana-ref}/servicenow-sir-action-type.html[{sn-sir} connector] +** {kibana-ref}/jira-action-type.html[{jira} connector] +** {kibana-ref}/resilient-action-type.html[{ibm-r} connector] +** {kibana-ref}/swimlane-action-type.html[{swimlane} connector] +** {kibana-ref}/thehive-action-type.html[{hive} connector] +** {kibana-ref}/cases-webhook-action-type.html[{webhook-cm} connector] + +To change the settings of an existing connector: + +. Select the required connector from the incident management system list. +. Click **Update **. +. In the **Edit connector** flyout, modify the connector fields as required, then click **Save & close** to save your changes. + +To change the default connector used to send cases to external systems, select the required connector from the incident management system list. + +[discrete] +[[cases-settings-mapped-case-fields]] +=== Mapped case fields + +When you export an {elastic-sec} case to an external system, case fields are mapped to existing fields in the external system. +For example, the case title is mapped to the short description in {sn} and the summary in {jira} incidents. +Case tags are mapped to labels in {jira}. +Case comments are mapped to work notes in {sn}. + +When you use a {webhook-cm} connector, case fields can be mapped to custom or existing fields. + +When you push updates to external systems, mapped fields are either overwritten or appended, depending on the field and the connector. + +Retrieving data from external systems is not supported. + +[discrete] +[[cases-settings-custom-fields]] +== Custom fields + +You can add optional and required fields for customized case collaboration. + +. In the **Custom fields** section, click **Add field**. +[role="screenshot"] +image::images/cases-settings/security-cases-custom-fields.png[Add a custom field] ++ +// NOTE: This is an autogenerated screenshot. Do not edit it directly. +. You must provide a field label and type (text or toggle). +You can optionally designate it as a required field and provide a default value. + +When you create a custom field, it's added to all new and existing cases. +In existing cases, new custom text fields initially have null values. + +You can subsequently remove or edit custom fields on the **Settings** page. + +[discrete] +[[cases-settings-templates]] +== Templates + +preview::[] + +You can make the case creation process faster and more consistent by adding templates. +A template defines values for one or all of the case fields (such as severity, tags, description, and title) as well as any custom fields. + +To create a template: + +. In the **Templates** section, click **Add template**. ++ +[role="screenshot"] +image::images/cases-settings/security-cases-templates.png[Add a case template] ++ +// NOTE: This is an autogenerated screenshot. Do not edit it directly. +. You must provide a template name and case severity. You can optionally add template tags and a description, values for each case field, and a case connector. + +When users create cases, they can optionally select a template and use its field values or override them. + +[NOTE] +==== +If you update or delete templates, existing cases are unaffected. +==== diff --git a/docs/serverless/investigate/indicators-of-compromise.asciidoc b/docs/serverless/investigate/indicators-of-compromise.asciidoc new file mode 100644 index 0000000000..5da53b2bf8 --- /dev/null +++ b/docs/serverless/investigate/indicators-of-compromise.asciidoc @@ -0,0 +1,181 @@ +[[indicators-of-compromise]] += Indicators of compromise + +:description: Set up the Indicators page to detect, analyze, and respond to threats. +:keywords: serverless, security, how-to, analyze, manage + +preview:[] + +The Indicators page collects data from enabled threat intelligence feeds and provides a centralized view of indicators, also known as indicators of compromise (IoCs). This topic helps you set up the Indicators page and explains how to work with IoCs. + +.Requirements +[NOTE] +==== +* The Indicators page requires the Security Analytics Complete https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature]. +* You must have _one_ of the following installed on the hosts you want to monitor: ++ +** **{agent}** - Install a {fleet-guide}/install-fleet-managed-elastic-agent.html[{fleet}-managed {agent}] and ensure the agent's status is `Healthy`. Refer to {fleet-guide}/fleet-troubleshooting.html[{fleet} Troubleshooting] if it isn't. +** **{filebeat}** - Install {filebeat-ref}/filebeat-installation-configuration.html[{filebeat}]. +==== + +[role="screenshot"] +image::images/indicators-of-compromise/-cases-indicators-table.png[Shows the Indicators page] + +[discrete] +[[ti-indicators]] +== Threat intelligence and indicators + +Threat intelligence is a research function that analyzes current and emerging threats and recommends appropriate actions to strengthen a company's security posture. Threat intelligence requires proactivity to be useful, such as gathering, analyzing, and investigating various threat and vulnerability data sources. + +An indicator, also referred to as an IoC, is a piece of information associated with a known threat or reported vulnerability. There are many types of indicators, including URLs, files, domains, email addresses, and more. Within SOC teams, threat intelligence analysts use indicators to detect, assess, and respond to threats. + +[discrete] +[[setup-indicators-page]] +== Set up the Indicators page + +Install a threat intelligence integration to add indicators to the Indicators page. + +. From the {security-app} main menu, select one of the following: ++ +** **Intelligence** → **Indicators** → **Add Integrations**. +** **Project settings** → **Integrations**. +. In the search bar, search for `Threat Intelligence` to get a list of threat intelligence integrations. +. Select a threat intelligence integration, then complete the integration's guided installation. ++ +[NOTE] +==== +For more information about available fields, go to the https://docs.elastic.co/integrations[Elastic integration documentation] and search for a specific threat intelligence integration. +==== +. Return to the Indicators page in {elastic-sec}. Refresh the page if indicator data isn't displaying. + +[discrete] +[[troubleshoot-indicators-page]] +=== Troubleshooting + +If indicator data is not appearing in the Indicators table after you installed a threat intelligence integration: + +* Verify that the index storing indicator documents is included in the <> (`securitySolution:defaultIndex`). The index storing indicator documents will differ based on the way you're collecting indicator data: ++ +** **{agent} integrations** - `logs_ti*` +** **{filebeat} integrations** - `filebeat-*` +* Ensure the indicator data you're ingesting is mapped to {ecs-ref}[Elastic Common Schema (ECS)]. + +[NOTE] +==== +These troubleshooting steps also apply to the <>. +==== + +[discrete] +[[intelligence-page-ui]] +== Indicators page UI + +After you add indicators to the Indicators page, you can <>, search, filter, and take action on indicator data. Indicators also appear in the Trend view, which shows the total values in the legend. + +[role="screenshot"] +image::images/indicators-of-compromise/-cases-interact-with-indicators-table.gif[Shows how to interact with the Intelligence page] + +[discrete] +[[examine-indicator-details]] +=== Examine indicator details + +Learn more about an indicator by clicking **View details**, then opening the Indicator details flyout. The flyout contains these informational tabs: + +* **Overview**: A summary of the indicator, including the indicator's name, the threat intelligence feed it came from, the indicator type, and additional relevant data. ++ +[NOTE] +==== +Some threat intelligence feeds provide https://www.cisa.gov/tlp#:~:text=Introduction,shared%20with%20the%20appropriate%20audience[Traffic Light Protocol (TLP) markings]. The `TLP Marking` and `Confidence` fields will be empty if the feed doesn't provide that data. +==== +* **Table**: The indicator data in table format. +* **JSON**: The indicator data in JSON format. ++ +[role="screenshot"] +image::images/indicators-of-compromise/-cases-indicator-details-flyout.png[Shows the Indicator details flyout, 600] + +[discrete] +[[find-related-sec-events]] +== Find related security events + +Investigate an indicator in <> to identify and predict related events in your environment. You can add an indicator to Timeline from the Indicators table or the Indicator details flyout. + +[role="screenshot"] +image::images/indicators-of-compromise/-cases-indicator-query-timeline.png[Shows the results of an indicator being investigated in Timeline] + +When you add an indicator to Timeline, a new Timeline opens with an auto-generated KQL query. The query contains the indicator field-value pair that you selected plus the field-value pair of the automatically mapped source event. By default, the query's time range is set to seven days before and after the indicator's `timestamp`. + +[discrete] +[[example-indicator-timeline]] +=== Example indicator Timeline investigation + +The following image shows a file hash indictor being investigated in Timeline. The indicator field-value pair is: + +`threat.indicator.file.hash.sha256 : 116dd9071887611c19c24aedde270285a4cf97157b846e6343407cf3bcec115a` + +[role="screenshot"] +image::images/indicators-of-compromise/-cases-indicator-in-timeline.png[Shows the results of an indicator being investigated in Timeline] + +The auto-generated query contains the indicator field-value pair (mentioned previously) and the auto-mapped source event field-value pair, which is: + +`file.hash.sha256 : 116dd9071887611c19c24aedde270285a4cf97157b846e6343407cf3bcec115a` + +The query results show an alert with a matching `file.hash.sha256` field value, which may indicate suspicious or malicious activity in the environment. + +[discrete] +[[attach-indicator-to-case]] +== Attach indicators to cases + +Attaching indicators to cases provides more context and available actions for your investigations. This feature allows you to easily share or escalate threat intelligence to other teams. + +To add indicators to cases: + +. From the Indicators table, click the **More actions** (image:images/icons/boxesHorizontal.svg[More actions]) menu. Alternatively, open an indicator's details, then select **Take action**. +. Select one of the following: ++ +** **Add to existing case**: From the **Select case** dialog box, select the case to which you want to attach the indicator. +** **Add to new case**: Configure the case details. Refer to <> to learn more about opening a new case. ++ +The indicator is added to the case as a new comment. + +[role="screenshot"] +image::images/indicators-of-compromise/-cases-indicator-added-to-case.png[An indicator attached to a case] + +[discrete] +[[review-indicator-in-case]] +=== Review indicator details in cases + +When you attach an indicator to a case, the indicator is added as a new comment with the following details: + +* **Indicator name**: Click the linked name to open the Indicator details flyout, which contains the following tabs: ++ +** **Overview**: A summary of the threat indicator, including its name and type, which threat intelligence feed it came from, and additional relevant data. ++ +[NOTE] +==== +Some threat intelligence feeds provide https://www.cisa.gov/tlp#:~:text=Introduction,shared%20with%20the%20appropriate%20audience[Traffic Light Protocol (TLP) markings]. The `TLP Marking` and `Confidence` fields will be empty if the feed doesn't provide that data. +==== +** **Table**: The indicator data in table format. +** **JSON**: The indicator data in JSON format. +* **Feed name**: The threat feed from which the indicator was ingested. +* **Indicator type**: The indicator type, for example, `file` or `.exe`. + +[discrete] +[[delete-indicator-from-case]] +=== Remove indicators from cases + +To remove an indicator attached to a case, click the **More actions** (image:images/icons/boxesHorizontal.svg[More actions]) menu → **Delete attachment** in the case comment. + +[role="screenshot"] +image::images/indicators-of-compromise/-cases-remove-indicator.png[Removing an indicator from a case] + +[discrete] +[[add-indicator-to-blocklist]] +== Use data from indicators to expand the blocklist + +Add indicator values to the <> to prevent selected applications from running on your hosts. You can use MD5, SHA-1, or SHA-256 hash values from `file` type indicators. + +You can add indicator values to the blocklist from the Indicators table or the Indicator details flyout. From the Indicators table, select the **More actions** (image:images/icons/boxesHorizontal.svg[More actions]) menu → **Add blocklist entry**. Alternatively, open an indicator's details, then select the **Take action** menu → **Add blocklist entry**. + +[NOTE] +==== +Refer to <> for more information about blocklist entries. +==== diff --git a/docs/serverless/investigate/investigate-events.asciidoc b/docs/serverless/investigate/investigate-events.asciidoc new file mode 100644 index 0000000000..1578ae5256 --- /dev/null +++ b/docs/serverless/investigate/investigate-events.asciidoc @@ -0,0 +1,16 @@ +[[investigate-events]] += Investigation tools + +:description: Investigate security events and track security issues in {elastic-sec}. +:keywords: serverless, security, overview + +preview:[] + +The following sections describe tools for investigating security events and tracking security issues directly in {elastic-sec}. + +These features are available in the {security-app}'s side navigation menu: + +* <>: Track investigation details about security issues. +* **Investigations** → <>: Workspace for investigations and threat hunting. +* **Investigations** → <>: Run live and scheduled queries on operating systems. +* <>: Indicators of compromise used for threat intelligence. diff --git a/docs/serverless/investigate/timeline-object-schema.asciidoc b/docs/serverless/investigate/timeline-object-schema.asciidoc new file mode 100644 index 0000000000..70d9e7200a --- /dev/null +++ b/docs/serverless/investigate/timeline-object-schema.asciidoc @@ -0,0 +1,441 @@ +[[timeline-object-schema]] += Timeline schema + +:description: A list of JSON elements inside the timeline object. +:keywords: serverless, security, reference + +preview:[] + +The Timeline schema lists all the JSON fields and objects required to create a Timeline or a Timeline template using the Create Timeline API. + +[IMPORTANT] +==== +All column, dropzone, and filter fields must be +{ecs-ref}[ECS fields]. +==== + +This screenshot maps the Timeline UI components to their JSON objects: + +[role="screenshot"] +image::images/timeline-object-schema/-reference-timeline-object-ui.png[] + +. <> (`title`) +. <> (`globalNotes`) +. <> (`dataViewId`) +. <> (`kqlQuery`) +. <> (`dateRange`) +. <> (`filters`) +. <> (`kqlMode`) +. <> (each clause is contained in its own `dataProviders` object) +. <> (`columns`) +. <> (`eventNotes`) + +|=== +| Name | Type | Description + +| [[timeline-object-schema-timeline-object-columns]] + + `columns` +| <> +| The Timeline's +columns. + +| `created` +| Float +| The time the Timeline was created, using a 13-digit Epoch +timestamp. + +| `createdBy` +| String +| The user who created the Timeline. + +| [[timeline-object-schema-timeline-object-dropzone]] `dataProviders` +| <> +| Object containing dropzone query +clauses. + +| [[timeline-object-schema-timeline-object-dataViewId]] + + `dataViewId` +| String +| ID of the Timeline's Data View, for example: `"dataViewId":"security-solution-default"`. + +| [[timeline-object-schema-timeline-object-daterange]] + + `dateRange` +| dateRange +a| The Timeline's search +period: + +* `end`: The time up to which events are searched, using a 13-digit Epoch +timestamp. +* `start`: The time from which events are searched, using a 13-digit Epoch +timestamp. + +| `description` +| String +| The Timeline's description. + +| [[timeline-object-schema-timeline-object-event-notes]] + + `eventNotes` +| <> +| Notes added to specific events in the Timeline. + +| `eventType` +| String +a| Event types displayed in +the Timeline, which can be: + +* `All data sources` +* `Events`: Event sources only +* `Detection Alerts`: Detection alerts only + +| `favorite` +| <> +| Indicates when and who marked a +Timeline as a favorite. + +| [[timeline-object-schema-timeline-object-filters]] + + `filters` +| <> +| Filters used +in addition to the dropzone query. + +| [[timeline-object-schema-timeline-object-global-notes]] `globalNotes` +| <> +| Global notes added to the Timeline. + +| [[timeline-object-schema-timeline-object-kqlmode]] + + `kqlMode` +| String +a| Indicates whether the KQL bar +filters the dropzone query results or searches for additional results, where: + +* `filter`: filters dropzone query results +* `search`: displays additional search results + +| [[timeline-object-schema-timeline-object-kqlquery]] + + `kqlQuery` +| <> +| KQL bar +query. + +| `pinnedEventIds` +| pinnedEventIds[] +| IDs of events pinned to the Timeline's +search results. + +| `savedObjectId` +| String +| The Timeline's saved object ID. + +| `savedQueryId` +| String +| If used, the saved query ID used to filter or search +dropzone query results. + +| `sort` +| sort +a| Object indicating how rows are sorted in the Timeline's grid: + +* `columnId` (string): The ID of the column used to sort results. +* `sortDirection` (string): The sort direction, which can be either `desc` or +`asc`. + +| `templateTimelineId` +| String +| A unique ID (UUID) for Timeline templates. For +Timelines, the value is `null`. + +| `templateTimelineVersion` +| Integer +| Timeline template version number. For +Timelines, the value is `null`. + +| [[timeline-object-schema-timeline-object-typeField]] + + `timelineType` +| String +a| Indicates whether the +Timeline is a template or not, where: + +* `default`: Indicates a Timeline used to actively investigate events. +* `template`: Indicates a Timeline template used when detection rule alerts are +investigated in Timeline. + +| [[timeline-object-schema-timeline-object-title]] + + `title` +| String +| The Timeline's title. + +| `updated` +| Float +| The last time the Timeline was updated, using a +13-digit Epoch timestamp. + +| `updatedBy` +| String +| The user who last updated the Timeline. + +| `version` +| String +| The Timeline's version. +|=== + +[discrete] +[[col-obj]] +== columns object + +|=== +| Name | Type | Description + +| `aggregatable` +| Boolean +| Indicates whether the field can be aggregated across +all indices (used to sort columns in the UI). + +| `category` +| String +| The ECS field set to which the field belongs. + +| `description` +| String +| UI column field description tooltip. + +| `example` +| String +| UI column field example tooltip. + +| `indexes` +| String +| Security indices in which the field exists and has the same +{es} type. `null` when all the security indices have the field with the same +type. + +| `id` +| String +| ECS field name, displayed as the column header in the UI. + +| `type` +| String +| The field's type. +|=== + +[discrete] +[[dataProvider-obj]] +== dataProviders object + +|=== +| Name | Type | Description + +| `and` +| dataProviders[] +| Array containing dropzone query clauses using `AND` +logic. + +| `enabled` +| Boolean +| Indicates if the dropzone query clause is enabled. + +| `excluded` +| Boolean +| Indicates if the dropzone query clause uses `NOT` logic. + +| `id` +| String +| The dropzone query clause's unique ID. + +| `name` +| String +| The dropzone query clause's name (the clause's value +when Timelines are exported from the UI). + +| `queryMatch` +| queryMatch +a| The dropzone query clause: + +* `field` (string): The field used to search Security indices. +* `operator` (string): The clause's operator, which can be: ++ +** `:` - The `field` has the specified `value`. +** `:*` - The field exists. +* `value` (string): The field's value used to match results. +|=== + +[discrete] +[[eventNotes-obj]] +== eventNotes object + +|=== +| Name | Type | Description + +| `created` +| Float +| The time the note was created, using a 13-digit Epoch +timestamp. + +| `createdBy` +| String +| The user who added the note. + +| `eventId` +| String +| The ID of the event to which the note was added. + +| `note` +| String +| The note's text. + +| `noteId` +| String +| The note's ID + +| `timelineId` +| String +| The ID of the Timeline to which the note was added. + +| `updated` +| Float +| The last time the note was updated, using a +13-digit Epoch timestamp. + +| `updatedBy` +| String +| The user who last updated the note. + +| `version` +| String +| The note's version. +|=== + +[discrete] +[[favorite-obj]] +== favorite object + +|=== +| Name | Type | Description + +| `favoriteDate` +| Float +| The time the Timeline was marked as a favorite, using a +13-digit Epoch timestamp. + +| `fullName` +| String +| The full name of the user who marked the Timeline as +a favorite. + +| `keySearch` +| String +| `userName` encoded in Base64. + +| `userName` +| String +| The username of the user who marked the +Timeline as a favorite. +|=== + +[discrete] +[[filters-obj]] +== filters object + +|=== +| Name | Type | Description + +| `exists` +| String +| {ref}/query-dsl-exists-query.html[Exists term query] for the +specified field (`null` when undefined). For example, `{"field":"user.name"}`. + +| `meta` +| meta +a| Filter details: + +* `alias` (string): UI filter name. +* `disabled` (boolean): Indicates if the filter is disabled. +* `key`(string): Field name or unique string ID. +* `negate` (boolean): Indicates if the filter query clause uses `NOT` logic. +* `params` (string): Value of `phrase` filter types. +* `type` (string): Type of filter. For example, `exists` and `range`. For more +information about filtering, see {ref}/query-dsl.html[Query DSL]. + +| `match_all` +| String +| {ref}/query-dsl-match-all-query.html[Match all term query] +for the specified field (`null` when undefined). + +| `query` +| String +| {ref}/query-dsl.html[DSL query] (`null` when undefined). For +example, `{"match_phrase":{"ecs.version":"1.4.0"}}`. + +| `range` +| String +| {ref}/query-dsl-range-query.html[Range query] (`null` when +undefined). For example, `{"@timestamp":{"gte":"now-1d","lt":"now"}}"`. +|=== + +[discrete] +[[globalNotes-obj]] +== globalNotes object + +|=== +| Name | Type | Description + +| `created` +| Float +| The time the note was created, using a 13-digit Epoch +timestamp. + +| `createdBy` +| String +| The user who added the note. + +| `note` +| String +| The note's text. + +| `noteId` +| String +| The note's ID + +| `timelineId` +| String +| The ID of the Timeline to which the note was added. + +| `updated` +| Float +| The last time the note was updated, using a +13-digit Epoch timestamp. + +| `updatedBy` +| String +| The user who last updated the note. + +| `version` +| String +| The note's version. +|=== + +[discrete] +[[kqlQuery-obj]] +== kqlQuery object + +|=== +| Name | Type | Description + +| `filterQuery` +| filterQuery +a| Object containing query details: + +* `kuery`: Object containing the query's clauses and type: ++ +** `expression`(string): The query's clauses. +** `kind` (string): The type of query, which can be `kuery` or `lucene`. +* `serializedQuery` (string): The query represented in JSON format. +|=== diff --git a/docs/serverless/investigate/timeline-templates-ui.asciidoc b/docs/serverless/investigate/timeline-templates-ui.asciidoc new file mode 100644 index 0000000000..7b5c56f861 --- /dev/null +++ b/docs/serverless/investigate/timeline-templates-ui.asciidoc @@ -0,0 +1,160 @@ +[[timeline-templates-ui]] += Timeline templates + +:description: Attach Timeline templates to detection rules to streamline investigations. +:keywords: serverless, security, how-to, analyze, manage + +preview:[] + +You can attach Timeline templates to detection rules. When attached, the rule's alerts use the template when they are investigated in Timeline. This enables immediately viewing the alert's most interesting fields when you start an investigation. + +Templates can include two types of filters: + +* **Regular filter**: Like other KQL filters, defines both the source event field and its value. For example: `host.name : "win-server"`. +* **Template filter**: Only defines the event field and uses a placeholder +for the field's value. When you investigate an alert in Timeline, the field's value is taken from the alert. + +For example, if you define the `host.name: "{host.name}"` template filter, when alerts generated by the rule are investigated in Timeline, the alert's +`host.name` value is used in the filter. If the alert's `host.name` value is +`Linux_stafordshire-061`, the Timeline filter is: +`host.name: "Linux_stafordshire-061"`. + +[NOTE] +==== +For information on how to add Timeline templates to rules, refer to <>. +==== + +When you load {elastic-sec} prebuilt rules, {elastic-sec} also loads a selection of prebuilt Timeline templates, which you can attach to detection rules. **Generic** templates use broad KQL queries to retrieve event data, and **Comprehensive** templates use detailed KQL queries to retrieve additional information. The following prebuilt templates appear by default: + +* **Alerts Involving a Single Host Timeline**: Investigate detection alerts involving a single host. +* **Alerts Involving a Single User Timeline**: Investigate detection alerts involving a single user. +* **Generic Endpoint Timeline**: Investigate {elastic-endpoint} detection alerts. +* **Generic Network Timeline**: Investigate network-related detection alerts. +* **Generic Process Timeline**: Investigate process-related detection alerts. +* **Generic Threat Match Timeline**: Investigate threat indicator match detection alerts. +* **Comprehensive File Timeline**: Investigate file-related detection alerts. +* **Comprehensive Network Timeline**: Investigate network-related detection alerts. +* **Comprehensive Process Timeline**: Investigate process-related detection alerts. +* **Comprehensive Registry Timeline**: Investigate registry-related detection alerts. + +[TIP] +==== +You can <> and use them as +a starting point for your own custom templates. +==== + +[discrete] +[[template-legend-ui]] +== Timeline template legend + +When you add filters to a Timeline template, the items are color coded to +indicate which type of filter is added. Additionally, you change Timeline +filters to template filters as you build your template. + +Regular Timeline filter:: +Clicking **Convert to template field** changes the filter to a template filter: + +[role="screenshot"] +image::images/timeline-templates-ui/-events-template-filter-value.png[] + +Template filter:: + +[role="screenshot"] +image:images/timeline-templates-ui/-events-timeline-template-filter.png[]\ +When you <>, template filters with placeholders are disabled: + +[role="screenshot"] +image::images/timeline-templates-ui/-events-invalid-filter.png[] + +To enable the filter, either specify a value or change it to a field's existing filter (refer to <>). + +[discrete] +[[create-timeline-template]] +== Create a Timeline template + +. Choose one of the following: ++ +** Go to **Investigations** → **Timelines**. Click the **Templates** tab, then click **Create new Timeline template**. +** Go to the Timeline bar (which is at the bottom of most pages), click the image:images/icons/plusInCircle.svg[New Timeline] button, then click **Create new Timeline template**. +** From an open Timeline or Timeline template, click **New** → **New Timeline template**. +. Add filters to the new Timeline template. Click **Add field**, and select the required option: ++ +** **Add field**: Add a regular Timeline filter. +** **Add template field**: Add a template filter with a value placeholder. ++ +[TIP] +==== +You can also drag and send items to the template from the **Overview**, **Hosts**, **Network**, and **Alerts** pages. +==== ++ +[role="screenshot"] +image::images/timeline-templates-ui/-events-create-a-timeline-template-field.png[An example of a Timeline filter] +. Click **Save** to give the template a title and description. + +**Example** + +To create a template for process-related alerts on a specific host: + +* Add a regular filter for the host name: +`host.name: "Linux_stafordshire-061"` +* Add template filter for process names: `process.name: "{process.name}"` + +[role="screenshot"] +image::images/timeline-templates-ui/-events-template-query-example.png[] + +When alerts generated by rules associated with this template are investigated +in Timeline, the host name is `Linux_stafordshire-061`, whereas the process name +value is retrieved from the alert's `process.name` field. + +[discrete] +[[man-templates-ui]] +== Manage existing Timeline templates + +You can view, duplicate, export, delete, and create templates from existing Timelines: + +. Go to **Investigations** → **Timelines** → **Templates**. ++ +[role="screenshot"] +image::images/timeline-templates-ui/-events-all-actions-timeline-ui.png[] +. Click the **All actions** icon in the relevant row, and then select the action: ++ +** **Create timeline from template** (refer to <>) +** **Duplicate template** +** **Export selected** (refer to <>) +** **Delete selected** +** **Create query rule from timeline** (only available if the Timeline contains a KQL query) +** **Create EQL rule from timeline** (only available if the Timeline contains an EQL query) + +[TIP] +==== +To perform the same action on multiple templates, select templates, then the required action from the **Bulk actions** menu. +==== + +[NOTE] +==== +You cannot delete prebuilt templates. +==== + +[discrete] +[[import-export-timeline-templates]] +== Export and import Timeline templates + +You can import and export Timeline templates, which enables importing templates from one {elastic-sec} instance to another. Exported templates are saved in an `ndjson` file. + +. Go to **Investigations** → **Timelines** → **Templates**. +. To export templates, do one of the following: ++ +** To export one template, click the **All actions** icon in the relevant row and then select **Export selected**. +** To export multiple templates, select all the required templates and then click **Bulk actions** → **Export selected**. +. To import templates, click **Import**, then select or drag and drop the template `ndjson` file. ++ +[NOTE] +==== +Each template object in the file must be represented in a single line. +Multiple template objects are delimited with newlines. +==== + +[NOTE] +==== +You cannot export prebuilt templates. +==== diff --git a/docs/serverless/investigate/timelines-ui.asciidoc b/docs/serverless/investigate/timelines-ui.asciidoc new file mode 100644 index 0000000000..4c6c5a55df --- /dev/null +++ b/docs/serverless/investigate/timelines-ui.asciidoc @@ -0,0 +1,270 @@ +[[timelines-ui]] += Timeline + +:description: Investigate events and complex threats in your network. +:keywords: serverless, security, how-to, analyze, manage + +preview:[] + +Use Timeline as your workspace for investigations and threat hunting. +You can add alerts from multiple indices to a Timeline to facilitate advanced investigations. + +You can drag or send fields of interest to a Timeline to create the desired query. For example, you can add fields from tables and histograms +on the **Overview**, **Alerts**, **Hosts**, and **Network** pages, as well as from +other Timelines. Alternatively, you can add a query directly in Timeline +by expanding the <> and clicking **+ Add field**. + +[role="screenshot"] +image::images/timelines-ui/-events-timeline-ui-updated.png[example Timeline with several events] + +In addition to Timelines, you can create and attach Timeline templates to +<>. Timeline templates allow you to +define the source event fields used when you investigate alerts in +Timeline. You can select whether the fields use predefined values or values +retrieved from the alert. For more information, refer to <>. + +[discrete] +[[open-create-timeline]] +== Create new or open existing Timeline + +To make a new Timeline, choose one of the following: + +* Go to the Timelines page (**Investigations** → **Timelines**), then click **Create new Timeline**. +* Go to the Timeline bar (which is at the bottom of most pages), click the image:images/icons/plusInCircle.svg[New Timeline] button, then click **Create new Timeline**. +* From an open Timeline or Timeline template, click **New** → **New Timeline**. + +To open an existing Timeline, choose one of the following: + +* Go to the Timelines page, then click a Timeline's title. +* Go to the Timeline bar, click the image:images/icons/plusInCircle.svg[New Timeline] button, then click **Open Timeline**. +* From an open Timeline or Timeline template, click **Open**, then select the appropriate Timeline. + +To avoid losing your changes, you must save the Timeline before moving to a different {security-app} page. If you change an existing Timeline, you can use the **Save as new timeline** toggle to make a new copy of the Timeline, without overwriting the original one. + +[TIP] +==== +Click the star icon (image:images/icons/starEmpty.svg[Favorite]) to favorite your Timeline and quickly find it later. +==== + +[discrete] +[[refine-timeline-results]] +== View and refine Timeline results + +You can select whether Timeline displays detection alerts and other raw events, or just alerts. By default, Timeline displays both raw events and alerts. To hide raw events and display alerts only, click **Data view** to the left of the KQL query bar, then select **Show only detection alerts**. + +[discrete] +[[timeline-inspect-events-alerts]] +== Inspect an event or alert + +To further inspect an event or detection alert, click the **View details** button. A flyout with event or <> appears. + +[discrete] +[[conf-timeline-display]] +== Configure Timeline event context and display + +Many types of events automatically appear in preconfigured views that provide relevant +contextual information, called **Event Renderers**. All event renderers are turned off by default. To turn them on, use the **Event renderers** toggle at the top of the results pane. To only turn on specific event renderers, click the gear (image:images/icons/gear.svg[The customize event renderer button]) icon next to the toggle, and select the ones you want enabled. Close the **Customize event renderers** pane when you're done. Your changes are automatically applied to Timeline. + +[role="screenshot"] +image::images/timelines-ui/-events-timeline-ui-renderer.png[example timeline with the event renderer highlighted] + +The example above displays the Flow event renderer, which highlights the movement of +data between its source and destination. If you see a particular part of the rendered event that +interests you, you can drag it up to the drop zone below the query bar for further investigation. + +You can also modify a Timeline's display in other ways: + +* <> from Timeline +* Create <> and display them in the Timeline +* Reorder and resize columns +* Copy a column name or values to a clipboard +* Change how the name, value, or description of a field are displayed in Timeline +* View the Timeline in full screen mode +* Add or delete notes on individual events +* Add or delete investigation notes on the entire Timeline +* Pin interesting events to the Timeline + +[discrete] +[[add-remove-timeline-fields]] +== Add and remove fields from Timeline + +The Timeline table shows fields that are available for alerts and events in the selected data view. You can modify the table to display fields that interest you. Use the sidebar to search for specific fields or scroll through it to find fields of interest. Fields that you select display as columns in the table. + +To add a field from the sidebar, hover over it, and click the **Add field as a column** button (image:images/icons/plusInCircle.svg[The button that lets you to add a field as a column]), or drag and drop the field into the table. To remove a field, hover over it, and click the **Remove field as a column** button (image:images/icons/cross.svg[The button that lets you to remove a field as a column]). + +[role="screenshot"] +image::images/timelines-ui/-events-timeline-sidebar.png[Shows the sidebar that allows you to configure the columns that display in Timeline] + +[discrete] +[[narrow-expand]] +== Use the Timeline query builder + +Expand the query builder by clicking the query builder button (image:images/icons/timeline.svg[Query builder]) to the right of the KQL query bar. Drop in fields to build a query that filters Timeline results. The fields' relative placement specifies their logical relationships: horizontally adjacent filters use `AND`, while vertically adjacent filters use `OR`. + +[TIP] +==== +Collapse the query builder and provide more space for Timeline results by clicking the query builder button (image:images/icons/timeline.svg[Query builder]). +==== + +[discrete] +[[pivot]] +== Edit existing filters + +Click a filter to access additional operations such as **Add filter**, **Clear all**, **Load saved query**, and more: + +[role="screenshot"] +image::images/timelines-ui/-events-timeline-ui-filter-options.png[] + +Here are examples of various types of filters: + +Field with value:: +Filters for events with the specified field value: + +[role="screenshot"] +image::images/timelines-ui/-events-timeline-filter-value.png[] + +Field exists:: +Filters for events containing the specified field: + +[role="screenshot"] +image::images/timelines-ui/-events-timeline-field-exists.png[] + +Exclude results:: +Filters for events that do not contain the specified field value +(`field with value` filter) or the specified field (`field exists` filter): + +[role="screenshot"] +image::images/timelines-ui/-events-timeline-filter-exclude.png[] + +Temporarily disable:: +The filter is not used in the query until it is enabled again: + +[role="screenshot"] +image::images/timelines-ui/-events-timeline-disable-filter.png[] + +Filter for field present:: +Converts a `field with value` filter to a `field exists` filter. + +[NOTE] +==== +When you convert a <> to a +Timeline, some fields may be disabled. For more information, refer to +<>. +==== + +[discrete] +[[timeline-to-cases-ui]] +== Attach Timeline to a case + +To attach a Timeline to a new or existing case, open it, click **Attach to case** in the upper right corner, +then select either **Attach to new case** or **Attach to existing case**. + +To learn more about cases, refer to <>. + +[discrete] +[[manage-timelines-ui]] +== Manage existing Timelines + +You can view, duplicate, export, delete, and create templates from existing Timelines: + +. Go to **Investigations** → **Timelines**. +. Click the **All actions** menu in the desired row, then select an action: + +* **Create template from timeline** (refer to <>) +* **Duplicate timeline** +* **Export selected** (refer to <>) +* **Delete selected** +* **Create query rule from timeline** (only available if the Timeline contains a KQL query) +* **Create EQL rule from timeline** (only available if the Timeline contains an EQL query) + +[TIP] +==== +To perform an action on multiple Timelines, first select the Timelines, +then select an action from the **Bulk actions** menu. +==== + +[discrete] +[[import-export-timelines]] +== Export and import Timelines + +You can export and import Timelines, which enables you to share Timelines from one {elastic-sec} instance to another. Exported Timelines are saved as `.ndjson` files. + +To export Timelines: + +* Go to **Investigations** → **Timelines**. +* Either click the **All actions** menu in the relevant row and select **Export selected**, or select multiple Timelines and then click **Bulk actions** → **Export selected**. + +To import Timelines: + +* Click **Import**, then select or drag and drop the relevant `.ndjson` file. ++ +[NOTE] +==== +Multiple Timeline objects are delimited with newlines. +==== + +[discrete] +[[filter-with-eql]] +== Filter Timeline results with EQL + +Use the **Correlation** tab to investigate Timeline results with {ref}/eql.html[EQL queries]. + +When forming EQL queries, you can write a basic query to return a list of events and alerts. Or, you can create sequences of EQL queries to view matched, ordered events across multiple event categories. Sequence queries are useful for identifying and predicting related events. They can also provide a more complete picture of potential adversary behavior in your environment, which you can use to create or update rules and detection alerts. + +The following image shows what matched ordered events look like in the Timeline table. Events that belong to the same sequence are matched together in groups and shaded red or blue. Matched events are also ordered from oldest to newest in each sequence. + +[role="screenshot"] +image::images/timelines-ui/-events-correlation-tab-eql-query.png[a Timeline's correlation tab] + +From the **Correlation** tab, you can also do the following: + +* Specify the date and time range that you want to investigate. +* Reorder the columns and choose which fields to display. +* Choose a data view and whether to show detection alerts only. + +[discrete] +[[esql-in-timeline]] +== Use {esql} to investigate events + +The {ref}/esql.html[Elasticsearch Query Language {(esql})] provides a powerful way to filter, transform, and analyze event data stored in {es}. {esql} queries use "pipes" to manipulate and transform data in a step-by-step fashion. This approach allows you to compose a series of operations, where the output of one operation becomes the input for the next, enabling complex data transformations and analysis. + +You can use {esql} in Timeline by opening the **{esql}** tab. From there, you can: + +* Write an {esql} query to explore your events. For example, start with the following query, then iterate on it to tailor your results: ++ +[source,esql] +---- +FROM .alerts-security.alerts-default,apm-*-transaction*,auditbeat-*,endgame-*,filebeat-*,logs-*,packetbeat-*,traces-apm*,winlogbeat-*,-*elastic-cloud-logs-* +| LIMIT 10 +| KEEP @timestamp, message, event.category, event.action, host.name, source.ip, destination.ip, user.name +---- ++ +This query does the following: ++ +** It starts by querying documents within the Security alert index (`.alerts-security.alerts-default`) and indices specified in the <>. +** Then, the query limits the output to the top 10 results. +** Finally, it keeps the default Timeline fields (`@timestamp`, `message`, `event.category`, `event.action`, `host.name`, `source.ip`, `destination.ip`, and `user.name`) in the output. ++ +[TIP] +==== +When querying indices that tend to be large (for example, `logs-*`), performance can be impacted by the number of fields returned in the output. To optimize performance, we recommend using the {ref}/esql-commands.html#esql-keep[`KEEP`] command to specify fields that you want returned. For example, add the clause `KEEP @timestamp, user.name` to the end of your query to specify that you only want the `@timestamp` and `user.name` fields returned. +==== ++ +[NOTE] +==== +* An error message displays when the query bar is empty. +* When specifying data sources for an {esql} query, autocomplete doesn't suggest hidden indices, such as `.alerts-*`. You must manually enter the index name or pattern. +==== +* Click the help icon (image:images/icons/iInCircle.svg[Click the ES|QL help icon]) on the far right side of the query editor to open the in-product reference documentation for all {esql} commands and functions. +* Visualize query results using https://www.elastic.co/docs/current/serverless/elasticsearch/explore-your-data-discover-your-data[Discover] functionality. + +[role="screenshot"] +image::images/timelines-ui/-events-esql-tab.png[Example of the ES|QL tab in Timeline] + +[discrete] +[[esql-in-timeline-resources]] +== Additional {esql} resources + +To get started using {esql}, read the tutorial for {ref}/esql-kibana.html[using {esql} in {kib}]. Much of the functionality available in {kib} is also available in Timeline. + +To find examples of using {esql} for threat hunting, check out https://www.elastic.co/blog/introduction-to-esql-new-query-language-flexible-iterative-analytics[our blog]. diff --git a/docs/serverless/osquery/alerts-run-osquery.asciidoc b/docs/serverless/osquery/alerts-run-osquery.asciidoc new file mode 100644 index 0000000000..6ee3910bed --- /dev/null +++ b/docs/serverless/osquery/alerts-run-osquery.asciidoc @@ -0,0 +1,60 @@ +[[alerts-run-osquery]] += Run Osquery from alerts + +:description: Run live queries against an alert's host to investigate potential security threats and system compromises. +:keywords: serverless, security, how-to, analyze + +preview:[] + +Run live queries on hosts associated with alerts to learn more about your infrastructure and operating systems. For example, with Osquery, you can search your system for indicators of compromise that might have contributed to the alert. You can then use this data to inform your investigation and alert triage efforts. + +.Requirements +[NOTE] +==== +* The {kibana-ref}/manage-osquery-integration.html[Osquery manager integration] must be installed. +* {agent}'s {fleet-guide}/monitor-elastic-agent.html[status] must be `Healthy`. Refer to {fleet-guide}/fleet-troubleshooting.html[{fleet} Troubleshooting] if it isn't. +* You must have the appropriate user role to use this feature. +==== + +To run Osquery from an alert: + +. Do one of the following from the Alerts table: ++ +** Click the **View details** button to open the Alert details flyout, then click **Take action → Run Osquery**. +** Select the **More actions** menu (image:images/icons/boxesHorizontal.svg[Actions menu icon]), then select **Run Osquery**. +. Choose to run a single query or a query pack. +. Select one or more {agent}s or groups to query. Start typing in the search field to get suggestions for {agent}s by name, ID, platform, and policy. ++ +[NOTE] +==== +The host associated with the alert is automatically selected. You can specify additional hosts to query. +==== +. Specify the query or pack to run: ++ +** **Query**: Select a saved query or enter a new one in the text box. After you enter the query, you can expand the **Advanced** section to set a timeout period for the query, and view or set {kibana-ref}/osquery.html#osquery-map-fields[mapped ECS fields] included in the results from the live query (optional). ++ +[NOTE] +==== +Overwriting the query's default timeout period allows you to support queries that take longer to run. The default and minimum supported value for the **Timeout** field is `60`. The maximum supported value is `900`. +==== ++ +[TIP] +==== +Use <> to dynamically add existing alert data to your query. +==== +** **Pack**: Select from available query packs. After you select a pack, all of the queries in the pack are displayed. ++ +[TIP] +==== +Refer to {kibana-ref}/osquery.html#osquery-prebuilt-packs-queries[prebuilt packs] to learn about using and managing Elastic prebuilt packs. +==== ++ +[role="screenshot"] +image:images/alerts-run-osquery/-osquery-setup-query.png[Shows how to set up a single query] +. Click **Submit**. Query results will display within the flyout. ++ +[NOTE] +==== +Refer to <> for more information about query results. +==== +. Click **Save for later** to save the query for future use (optional). diff --git a/docs/serverless/osquery/invest-guide-run-osquery.asciidoc b/docs/serverless/osquery/invest-guide-run-osquery.asciidoc new file mode 100644 index 0000000000..93067ab587 --- /dev/null +++ b/docs/serverless/osquery/invest-guide-run-osquery.asciidoc @@ -0,0 +1,78 @@ +[[invest-guide-run-osquery]] += Run Osquery from investigation guides + +:description: Add and run live queries from a rule's investigation guide. +:keywords: serverless, security, how-to, analyze + +preview:[] + +Detection rule investigation guides suggest steps for triaging, analyzing, and responding to potential security issues. When you build a custom rule, you can also set up an investigation guide that incorporates Osquery. This allows you to run live queries from a rule's investigation guide as you analyze alerts produced by the rule. + +.Requirements +[NOTE] +==== +* The {kibana-ref}/manage-osquery-integration.html[Osquery manager integration] must be installed. +* {agent}'s {fleet-guide}/monitor-elastic-agent.html[status] must be `Healthy`. Refer to {fleet-guide}/fleet-troubleshooting.html[{fleet} Troubleshooting] if it isn't. +* You must have the appropriate user role to use this feature. +==== + +[role="screenshot"] +image::images/invest-guide-run-osquery/-osquery-osquery-investigation-guide.png[Shows a live query in an investigation guide] + +[discrete] +[[add-live-queries-ig]] +== Add live queries to an investigation guide + +[NOTE] +==== +You can only add Osquery to investigation guides for custom rules because prebuilt rules cannot be edited. +==== + +. Go to **Rules** → **Detection rules (SIEM)**, select a rule, then click **Edit rule settings** on the rule details page. +. Select the **About** tab, then expand the rule's advanced settings. +. Scroll down to the Investigation guide section. In the toolbar, click the **Osquery** button ([role="screenshot"] +image:images/invest-guide-run-osquery/-osquery-osquery-button.png[Click the Osquery button]). ++ +.. Add a descriptive label for the query; for example, `Search for executables`. +.. Select a saved query or enter a new one. ++ +[TIP] +==== +Use <> to dynamically add existing alert data to your query. +==== +.. Expand the **Advanced** section to set a timeout period for the query, and view or set {kibana-ref}/osquery.html#osquery-map-fields[mapped ECS fields] included in the results from the live query (optional). ++ +[NOTE] +==== +Overwriting the query's default timeout period allows you to support queries that take longer to run. The default and minimum supported value for the **Timeout** field is `60`. The maximum supported value is `900`. +==== ++ +[role="screenshot"] +image:images/invest-guide-run-osquery/-osquery-setup-osquery-investigation-guide.png[Shows results from running a query from an investigation guide] +. Click **Save changes** to add the query to the rule's investigation guide. + +[discrete] +[[run-live-queries-ig]] +== Run live queries from an investigation guide + +. Go to **Rules** → **Detection rules (SIEM)**, then select a rule to open its details. +. Go to the About section of the rule details page and click **Investigation guide**. +. Click the query. The Run Osquery pane displays with the **Query** field autofilled. Do the following: ++ +.. Select one or more {agent}s or groups to query. Start typing in the search field to get suggestions for {agent}s by name, ID, platform, and policy. +.. Expand the **Advanced** section to set a timeout period for the query, and view or set the {kibana-ref}/osquery.html#osquery-map-fields[mapped ECS fields] which are included in the live query's results (optional). ++ +[NOTE] +==== +Overwriting the query's default timeout period allows you to support queries that take longer to run. The default and minimum supported value for the **Timeout** field is `60`. The maximum supported value is `900`. +==== +. Click **Submit** to run the query. Query results display in the flyout. ++ +[NOTE] +==== +Refer to <> for more information about query results. +==== +. Click **Save for later** to save the query for future use (optional). ++ +[role="screenshot"] +image:images/invest-guide-run-osquery/-osquery-run-query-investigation-guide.png[Shows results from running a query from an investigation guide] diff --git a/docs/serverless/osquery/osquery-placeholder-fields.asciidoc b/docs/serverless/osquery/osquery-placeholder-fields.asciidoc new file mode 100644 index 0000000000..e59c9530d5 --- /dev/null +++ b/docs/serverless/osquery/osquery-placeholder-fields.asciidoc @@ -0,0 +1,36 @@ +[[osquery-placeholder-fields]] += Use placeholder fields in Osquery queries + +:description: Pass data into queries dynamically, to enhance their flexibility and reusability. +:keywords: serverless, security, how-to, manage + +preview:[] + +Instead of hard-coding alert and event values into Osquery queries, you can use placeholder fields to dynamically pass this data into queries. Placeholder fields function like parameters. You can use placeholder fields to build flexible and reusable queries. + +Placeholder fields work in single queries or query packs. They're also supported in the following features: + +* <> +* <> +* <> + +[discrete] +[[placeholder-field-syntax]] +== Placeholder field syntax and requirements + +Placeholder fields use http://mustache.github.io/[mustache syntax] and must be wrapped in double curly brackets (`{{example.field}}`). You can use any field within an event or alert document as a placeholder field. + +Queries with placeholder fields can only run against alerts or events. Otherwise, they will lack the necessary values and the query status will be `error`. + +[discrete] +[[placeholder-field-example]] +=== Example query with a placeholder field + +The following query uses the `{{host.name}}` placeholder field: + +[source,sql] +---- +SELECT * FROM os_version WHERE name = {{host.os.name}} +---- + +When you run the query, the value that's stored in the alert or event's `host.name` field will be transferred to the `{{host.os.name}}` placeholder field. diff --git a/docs/serverless/osquery/osquery-response-action.asciidoc b/docs/serverless/osquery/osquery-response-action.asciidoc new file mode 100644 index 0000000000..61adb94252 --- /dev/null +++ b/docs/serverless/osquery/osquery-response-action.asciidoc @@ -0,0 +1,93 @@ +[[osquery-response-action]] += Add Osquery Response Actions + +:description: Osquery Response Actions allow you to add live queries to custom query rules so you can automatically collect data on systems the rules are monitoring. +:keywords: serverless, security, how-to, manage + +preview:[] + +preview::[] + +Osquery Response Actions allow you to add live queries to custom query rules so you can automatically collect data on systems the rule is monitoring. Use this data to support your alert triage and investigation efforts. + +.Requirements +[NOTE] +==== +* Osquery Response Actions require the Endpoint Protection Complete https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature]. +* The {kibana-ref}/manage-osquery-integration.html[Osquery manager integration] must be installed. +* {agent}'s {fleet-guide}/monitor-elastic-agent.html[status] must be `Healthy`. Refer to {fleet-guide}/fleet-troubleshooting.html[{fleet} Troubleshooting] if it isn't. +* You must have the appropriate user role to use this feature. +* You can only add Osquery Response Actions to custom query rules. +==== + +[role="screenshot"] +image::images/osquery-response-action/-osquery-available-response-actions-osquery.png[The Osquery response action] + +[discrete] +[[add-osquery-response-action]] +== Add Osquery Response Actions to rules + +You can add Osquery Response Actions to new or existing custom query rules. Queries run every time the rule executes. + +. Choose one of the following: ++ +** **New rule**: When you are on the last step of <> creation, go to the Response Actions section and click the **Osquery** icon. +** **Existing rule**: Edit the rule's settings, then go to the **Actions** tab. In the tab, click the **Osquery** icon under the Response Actions section. ++ +[NOTE] +==== +If the rule's investigation guide is using an Osquery query, you'll be asked if you want to add the query as an Osquery Response Action. Click **Add** to add the investigation guide's query to the rule's Osquery Response Action. +==== +. Specify whether you want to set up a single live query or a pack: ++ +** **Query**: Select a saved query or enter a new one. After you enter the query, you can expand the **Advanced** section to set a timeout period for the query, and view or set {kibana-ref}/osquery.html#osquery-map-fields[mapped ECS fields] included in the results from the live query. Mapping ECS fields is optional. ++ +[NOTE] +==== +Overwriting the query's default timeout period allows you to support queries that take longer to run. The default and minimum supported value for the **Timeout** field is `60`. The maximum supported value is `900`. +==== ++ +[TIP] +==== +You can use <> to dynamically add alert data to your query. +==== +** **Pack**: Select from available query packs. After you select a pack, all of the queries in the pack are displayed. ++ +[TIP] +==== +Refer to {kibana-ref}/osquery.html#osquery-prebuilt-packs-queries[prebuilt packs] to learn about using and managing Elastic prebuilt packs. +==== ++ +[role="screenshot"] +image::images/osquery-response-action/-osquery-setup-single-query.png[Shows how to set up a single query] +. Click the **Osquery** icon to add more live queries (optional). +. Click **Create & enable rule** (for a new rule) or **Save changes** (for existing rules) to finish adding the queries. + +[discrete] +[[edit-osquery-response-action]] +== Edit Osquery Response Actions + +If you want to choose a different query or query pack for the Osquery Response Action to use, edit the rule to update the Response Action. + +[IMPORTANT] +==== +If you edited a saved query or query pack that an Osquery Response Action is using, you must reselect the saved query or query pack on the related Osquery Response Action. Query changes are not automatically applied to Osquery Response Actions. +==== + +. Edit the rule's settings, then go to the **Actions** tab. +. Modify the settings for Osquery Response Actions you've added. +. Click **Save changes**. + +[discrete] +[[find-osquery-response-action-results]] +== Find query results + +When a rule generates an alert, Osquery automatically collects data on the host. Query results are displayed within the **Response Results** tab in the Alert details flyout. The number next to the **Response Results** tab represents the number of queries attached to the rule, in addition to endpoint response actions run by the rule. + +[NOTE] +==== +Refer to <> for more information about query results. +==== + +[role="screenshot"] +image::images/osquery-response-action/-osquery-osquery-results-tab.png[Shows how to set up a single query] diff --git a/docs/serverless/osquery/use-osquery.asciidoc b/docs/serverless/osquery/use-osquery.asciidoc new file mode 100644 index 0000000000..97faa53e19 --- /dev/null +++ b/docs/serverless/osquery/use-osquery.asciidoc @@ -0,0 +1,16 @@ +[[query-operating-systems]] += Osquery + +:description: Integrate Osquery with {elastic-sec} for comprehensive data collection and security monitoring. +:keywords: serverless, security, overview + +preview:[] + +Osquery is an open source tool that lets you use SQL to query operating systems like a database. When you add the {kibana-ref}/manage-osquery-integration.html[Osquery manager integration] to an {agent} policy, Osquery is deployed to all agents assigned to that policy. After completing this setup, you can {kibana-ref}/osquery.html[run live queries and schedule recurring queries] for agents and begin gathering data from your entire environment. + +Osquery is supported for Linux, macOS, and Windows. You can use it with {elastic-sec} to perform real-time incident response, threat hunting, and monitoring to detect vulnerability or compliance issues. The following Osquery features are available from {elastic-sec}: + +* <> - Use Osquery Response Actions to add live queries to custom query rules. +* <> - Incorporate live queries into investigation guides to enhance your research capabilities while investigating possible security issues. +* <> - Run live queries against an alert's host to learn more about your infrastructure and operating systems. +* {kibana-ref}/osquery.html[Osquery settings] - Navigate to **Investigations** → **Osquery** to manage project-level Osquery settings. diff --git a/docs/serverless/osquery/view-osquery-results.asciidoc b/docs/serverless/osquery/view-osquery-results.asciidoc new file mode 100644 index 0000000000..eb0050715e --- /dev/null +++ b/docs/serverless/osquery/view-osquery-results.asciidoc @@ -0,0 +1,48 @@ +[[examine-osquery-results]] += Examine Osquery results + +:description: Analyze results from queries and query packs. +:keywords: serverless, security, how-to, analyze + +preview:[] + +Osquery provides relevant, timely data that you can use to better understand and monitor your environment. When you run queries, results are indexed and displayed the Results table, which you can filter, sort, and interact with. + +[discrete] +[[osquery-result-types]] +== Results table + +The Results table displays results from single queries and query packs. + +[discrete] +[[review-single-osquery-results]] +=== Single query results + +Results for single queries appear on the **Results** tab. When you run a query, the number of agents queried and query status temporarily display in a status bar above the results table. Agent responses can be `Successful`, `Not yet responded` (pending), and `Failed`. + +[role="screenshot"] +image::images/view-osquery-results/-osquery-single-query-results.png[Shows query results] + +[discrete] +[[review-pack-osquery-results]] +=== Query pack results + +Results for each query in the pack appear in the **Results** tab. Click the expand icon (image:images/icons/arrowDown.svg[Markdown]) at the far right of each query row to display query results. The number of agents that were queried and their responses are shown for each query. Agent responses are color-coded. Green is `Sucessful`, `Not yet responded` (pending) is gray, and `Failed` is red. + +[role="screenshot"] +image::images/view-osquery-results/-osquery-pack-query-results.png[Shows query results] + +[discrete] +[[investigate-osquery-results]] +== Investigate query results + +From the results table, you can: + +* Click **View in Discover** (image:images/icons/discoverApp.svg[View in Discover app]) to explore the results in Discover. +* Click **View in Lens** (image:images/icons/lensApp.svg[View in Lens app]) to navigate to Lens, where you can use the drag-and-drop **Lens** editor to create visualizations. +* Click **Timeline** (image:images/icons/timeline.svg[Timeline]) to investigate a single query result in Timeline or **Add to timeline investigation** to investigate all results. This option is only available for single query results. ++ +When you open all results in Timeline, the events in Timeline are filtered based on the `action_ID` generated by the Osquery query. +* Click **Add to Case** (image:images/icons/casesApp.svg[Cases]) to add the query results to a new or existing case. If you ran a live query from an alert, the alert and query results are added to the case as comments. +* Click the view details icon (image:images/icons/expand.svg[View details]) to examine the query ID and statement. +* View more information about the request, such as failures, by opening the **Status** tab. diff --git a/docs/serverless/partials/in-review-notice.asciidoc b/docs/serverless/partials/in-review-notice.asciidoc new file mode 100644 index 0000000000..e4a8c965d7 --- /dev/null +++ b/docs/serverless/partials/in-review-notice.asciidoc @@ -0,0 +1,15 @@ +
+
+ + image:images/icons/glasses.svg[glasses icon] + +
+ +
+ **In review** + + + This page has been updated with content for {serverless-short} and is ready for review. + +
+
diff --git a/docs/serverless/partials/in-testing-notice.asciidoc b/docs/serverless/partials/in-testing-notice.asciidoc new file mode 100644 index 0000000000..ccf4227021 --- /dev/null +++ b/docs/serverless/partials/in-testing-notice.asciidoc @@ -0,0 +1,15 @@ +
+
+ + image:images/icons/beaker.svg[beaker icon] + +
+ +
+ **In testing** + + + This page has been reviewed and is ready for testing. + +
+
diff --git a/docs/serverless/partials/publish-ready-notice.asciidoc b/docs/serverless/partials/publish-ready-notice.asciidoc new file mode 100644 index 0000000000..6a07c9733e --- /dev/null +++ b/docs/serverless/partials/publish-ready-notice.asciidoc @@ -0,0 +1,15 @@ +
+
+ + image:images/icons/checkInCircleFilled.svg[check icon] + +
+ +
+ **Publish ready** + + + This page has been tested and is ready for publishing. + +
+
diff --git a/docs/serverless/partials/rough-content-notice.asciidoc b/docs/serverless/partials/rough-content-notice.asciidoc new file mode 100644 index 0000000000..dfe9c7876c --- /dev/null +++ b/docs/serverless/partials/rough-content-notice.asciidoc @@ -0,0 +1,16 @@ +
+
+ + image:images/icons/warning.svg[alert icon] + +
+ +
+ **Rough content** + + + This page may contain misleading and incorrect information. + The URL path and filename may change in the future, so use with caution. + +
+
diff --git a/docs/serverless/partials/rough-content-notice.mdx b/docs/serverless/partials/rough-content-notice.mdx index 4d78d4a325..51c902b3c2 100644 --- a/docs/serverless/partials/rough-content-notice.mdx +++ b/docs/serverless/partials/rough-content-notice.mdx @@ -1,7 +1,7 @@
- +
diff --git a/docs/serverless/projects-create/create-project.asciidoc b/docs/serverless/projects-create/create-project.asciidoc new file mode 100644 index 0000000000..0d53b122ce --- /dev/null +++ b/docs/serverless/projects-create/create-project.asciidoc @@ -0,0 +1,30 @@ +[[create-project]] += Create a Security project + +:description: Get started with {serverless-short} {elastic-sec} in a few steps. +:keywords: serverless, security, how-to, get-started + +preview:[] + +A {serverless-short} project allows you to run {elastic-sec} in an autoscaled and fully-managed environment, where you don't have to manage the underlying {es} cluster and {kib} instances. + +[discrete] +[[create-project-create-project]] +== Create project + +Use your {ecloud} account to create a fully-managed {elastic-sec} project: + +. Navigate to https://cloud.elastic.co/[cloud.elastic.co]. +. Log in to your {ecloud} account and select **Create project** from the **Serverless projects** panel. +. Select **Next** from the **Security** panel. +. Edit your project settings. (Click **Edit settings** to access all settings.) ++ +** **Name**: A unique name for your project. +** **Cloud provider**: The cloud platform where you’ll deploy your project. We currently support Amazon Web Services (AWS). +** **Region**: The cloud platform’s https://www.elastic.co/docs/current/serverless/regions[region] where your project will live. ++ +You can also check https://cloud.elastic.co/pricing[the pricing details] to see how you consume {serverless-short} {elastic-sec}. +. Select **Create project**. It takes a few minutes before your project gets created. +. Once the project is ready, select **Continue** to open the **Get started** page. (You might need to log into {ecloud} again.) ++ +From here, you can learn more about {elastic-sec} features and start setting up your workspace. diff --git a/docs/serverless/rules/about-rules.asciidoc b/docs/serverless/rules/about-rules.asciidoc new file mode 100644 index 0000000000..5bc8596309 --- /dev/null +++ b/docs/serverless/rules/about-rules.asciidoc @@ -0,0 +1,94 @@ +[[about-rules]] += About detection rules + +:description: Learn about detection rule types and how they work. +:keywords: serverless, security, overview + +++++ +Rules +++++ + +preview:[] + +Rules run periodically and search for source events, matches, sequences, or {ml} job anomaly results that meet their criteria. When a rule's criteria are met, a detection alert is created. + +[discrete] +[[rule-types]] +== Rule types + +You can create the following types of rules: + +* <>: Query-based rule, which searches the defined indices and +creates an alert when one or more documents match the rule's query. +* <>: {ml-cap} rule, which creates an alert when a {ml} job +discovers an anomaly above the defined threshold (see <>). ++ +For {ml} rules, the associated {ml} job must be running. If the {ml} job isn't +running, the rule will: ++ +** Run and create alerts if existing anomaly results with scores above the defined threshold +are discovered. +** Issue an error stating the {ml} job was not running when the rule executed. +* <>: Searches the defined indices and creates a detections alert +when the number of times the specified field's value is present and meets the threshold during +a single execution. When multiple values meet the threshold, an alert is +generated for each value. ++ +For example, if the threshold `field` is `source.ip` and its `value` is `10`, an +alert is generated for every source IP address that appears in at least 10 of +the rule's search results. +* <>: Searches the defined indices and creates an alert when results match an +{ref}/eql.html[Event Query Language (EQL)] query. +* <>: Creates an alert when {elastic-sec} index field values match field values defined in the specified indicator index patterns. For example, you can create an indicator index for IP addresses and use this index to create an alert whenever an event's `destination.ip` equals a value in the index. Indicator index field mappings should be {ecs-ref}[ECS-compliant]. For information on creating {es} indices and field types, see +{ref}/getting-started-index.html[Index some documents], +{ref}/indices-create-index.html[Create index API], and +{ref}/mapping-types.html[Field data types]. If you have indicators in a standard file format, such as CSV or JSON, you can also use the Machine Learning Data Visualizer to import your indicators into an indicator index. See {ml-docs}/ml-getting-started.html#sample-data-visualizer[Explore the data in {kib}] and use the **Import Data** option to import your indicators. ++ +[TIP] +==== +You can also use value lists as the indicator match index. See <> at the end of this topic for more information. +==== +* <>: Generates an alert for each new term detected in source documents within a specified time range. You can also detect a combination of up to three new terms (for example, a `host.ip` and `host.id` that have never been observed together before). +* <>: Searches the defined indices and creates an alert when results match an {ref}/esql.html[{esql} query]. + +[role="screenshot"] +image::images/about-rules/-detections-all-rules.png[Shows the Rules page] + +[discrete] +[[views-index-patterns]] +== Data views and index patterns + +When you create a rule, you must either specify the {es} index pattens for which you'd like the rule to run, or select a <> as the data source. If you select a data view, you can select <> associated with that data view to create a query for the rule (with the exception of {ml} rules, which do not use queries). + +[NOTE] +==== +To access data views, ensure you have the {kibana-ref}/data-views.html#data-views-read-only-access[required permissions]. +==== + +[discrete] +[[about-notifications]] +== Notifications + +For both prebuilt and custom rules, you can send notifications when alerts are created. Notifications can be sent via {jira}, Microsoft Teams, PagerDuty, Slack, and others, and can be configured when you create or edit a rule. + +[discrete] +[[alerting-authorization-model]] +== Authorization + +Rules, including all background detection and the actions they generate, are authorized using an {kibana-ref}/api-keys.html[API key] associated with the last user to edit the rule. Upon creating or modifying a rule, an API key is generated for that user, capturing a snapshot of their privileges. The API key is then used to run all background tasks associated with the rule including detection checks and executing actions. + +[IMPORTANT] +==== +If a rule requires certain privileges to run, such as index privileges, keep in mind that if a user without those privileges updates the rule, the rule will no longer function. +==== + +[discrete] +[[about-exceptions]] +== Exceptions + +When modifying rules or managing detection alerts, you can <> that prevent a rule from generating alerts even when its criteria are met. This is useful for reducing noise, such as preventing alerts from trusted processes and internal IP addresses. + +[NOTE] +==== +You can add exceptions to custom query, machine learning, event correlation, and indicator match rule types. +==== diff --git a/docs/serverless/rules/add-exceptions.asciidoc b/docs/serverless/rules/add-exceptions.asciidoc new file mode 100644 index 0000000000..2fbfe59e1f --- /dev/null +++ b/docs/serverless/rules/add-exceptions.asciidoc @@ -0,0 +1,292 @@ +[[add-exceptions]] += Add and manage exceptions + +:description: Learn how to create and manage rule exceptions. +:keywords: serverless, security, how-to, configure + +preview:[] + +You can add exceptions to a rule from the rule details page, the Alerts table, the alert details flyout, or the Shared Exception Lists page. When you add an exception, you can also close all alerts that meet the exception’s criteria. + +[IMPORTANT] +==== +* To ensure an exception is successfully applied, ensure that the fields you've defined for its query are correctly and consistently mapped in their respective indices. Refer to {ecs-ref}[ECS] to learn more about supported mappings. +* Be careful when adding exceptions to <> rules. Exceptions are evaluated against every event in the sequence, and if an exception matches any events that are necessary to complete the sequence, alerts are not created. ++ +To exclude values from a +specific event in the sequence, update the rule's EQL statement. For example: ++ +[source,eql] +---- +`sequence + [file where file.extension == "exe" + and file.name != "app-name.exe"] + [process where true + and process.name != "process-name.exe"]` +---- +* Be careful when adding exceptions to <> rules. Exceptions are evaluated against source and indicator indices, so if the exception matches events in _either_ index, alerts are not generated. +==== + +[discrete] +[[detection-rule-exceptions]] +== Add exceptions to a rule + +. Do one of the following: ++ +** To add an exception from the rule details page: ++ +... Go to the rule details page of the rule to which you want to add an +exception (**Rules** → **Detection rules (SIEM)** → **_Rule name_**). +... Scroll down the rule details page, select the **Rule exceptions** tab, then click **Add rule exception**. ++ +[role="screenshot"] +image::images/add-exceptions/-detections-rule-exception-tab.png[Detail of rule exceptions tab] ++ +** To add an exception from the Alerts table: ++ +... Go to **Alerts**. +... Scroll down to the Alerts table, go to the alert you want to create an exception for, click the **More Actions** menu (image:images/icons/boxesHorizontal.svg[Actions menu]), then select **Add rule exception**. +** To add an exception from the alert details flyout: ++ +... Go to **Alerts**. +... Click the **View details** button from the Alerts table. +... In the alert details flyout, click **Take action → Add rule exception**. +** To add an exception from the Shared Exception Lists page: ++ +... Go to **Rules** → **Shared exception lists**. +... Click **Create shared exception list** → **Create exception item**. +. In the **Add rule exception** flyout, name the exception. +. Add conditions that define the exception. When the exception's query evaluates to `true`, rules don't generate alerts even when their criteria are met. ++ +[IMPORTANT] +==== +Rule exceptions are case-sensitive, which means that any character that's entered as an uppercase or lowercase letter will be treated as such. In the event you _don't_ want a field evaluated as case-sensitive, some ECS fields have a `.caseless` version that you can use. +==== ++ +[NOTE] +==== +When you create a new exception from an alert, exception conditions are auto-populated with relevant alert data. Data from custom highlighted fields is listed first. A comment that describes the auto-generated exception conditions is also added to the **Add comments** section. +==== ++ +.. **Field**: Select a field to identify the event being filtered. ++ +[NOTE] +==== +A warning displays for fields with conflicts. Using these fields might cause unexpected exceptions behavior. Refer to <> for more information. +==== +.. **Operator**: Select an operator to define the condition: ++ +*** `is` | `is not` — Must be an exact match of the defined value. +*** `is one of` | `is not one of` — Matches any of the defined values. +*** `exists` | `does not exist` — The field exists. +*** `is in list` | `is not in list` — Matches values in a value list. ++ +[NOTE] +==== +* An exception defined by a value list must use `is in list` or `is not in list` in all conditions. +* Wildcards are not supported in value lists. +* If a value list can't be used due to <>, it'll be unavailable in the **Value** menu. +==== +*** `matches` | `does not match` — Allows you to use wildcards in **Value**, such as `C:\path\*\app.exe`. Available wildcards are `?` (match one character) and `*` (match zero or more characters). The selected **Field** data type must be {ref}/keyword.html#keyword-field-type[keyword], {ref}/text.html#text-field-type[text], or {ref}/keyword.html#wildcard-field-type[wildcard]. ++ +[NOTE] +==== +Some characters must be escaped with a backslash, such as `\` for a literal backslash, `*` for an asterisk, and `\?` for a question mark. Windows paths must be divided with double backslashes (for example, `C:\Windows\explorer.exe`), and paths that already include double backslashes might require four backslashes for each divider. +==== ++ +[IMPORTANT] +==== +Using wildcards can impact performance. To create a more efficient exception using wildcards, use multiple conditions and make them as specific as possible. For example, adding conditions using `process.name` or `file.name` can help limit the scope of wildcard matching. +==== +.. **Value**: Enter the value associated with the **Field**. To enter multiple values (when using `is one of` or `is not one of`), enter each value, then press **Return**. ++ +[NOTE] +==== +Identical, case-sensitive values are supported for the `is one of` and `is not one of` operators. For example, if you want to match the values `Windows` and `windows`, add both values to the **Value** field. +==== ++ +In the following example, the exception was created from the Rules page and prevents the rule from generating alerts when the `svchost.exe` process runs on hostname `siem-kibana`. ++ +[role="screenshot"] +image::images/add-exceptions/-detections-add-exception-ui.png[] +. Click **AND** or **OR** to create multiple conditions and define their relationships. +. Click **Add nested condition** to create conditions using nested fields. This is only required for +<>. For all other fields, nested conditions should not be used. +. Choose to add the exception to a rule or a shared exception list. ++ +[NOTE] +==== +If you are creating an exception from the Shared Exception Lists page, you can add the exception to multiple rules. +==== ++ +[TIP] +==== +If a shared exception list doesn't exist, you can <> from the Shared Exception Lists page. +==== +. (Optional) Enter a comment describing the exception. +. (Optional) Enter a future expiration date and time for the exception. +. Select one of the following alert actions: ++ +** **Close this alert**: Closes the alert when the exception is added. This option +is only available when adding exceptions from the Alerts table. +** **Close all alerts that match this exception and were generated by this rule**: Closes all alerts that match the exception's conditions and were generated only by the current rule. +. Click **Add rule exception**. + +[discrete] +[[endpoint-rule-exceptions]] +== Add {elastic-endpoint} exceptions + +Like detection rule exceptions, you can add Endpoint agent exceptions either by editing the Endpoint Security rule or by adding them as actions on alerts generated by the Endpoint Security rule. {elastic-endpoint} alerts have the following fields: + +* `kibana.alert.original_event.module determined:endpoint` +* `kibana.alert.original_event.kind:alert` + +You can also add Endpoint exceptions to rules that are associated with {elastic-endpoint} rule exceptions. To associate rules when creating or editing a rule, select the <> option. + +Endpoint exceptions are added to the Endpoint Security rule **and** the {elastic-endpoint} on your hosts. + +[IMPORTANT] +==== +Exceptions added to the Endpoint Security rule affect all alerts sent +from the Endpoint agent. Be careful not to unintentionally prevent useful Endpoint +alerts. + +Additionally, to add an Endpoint exception to the Endpoint Security rule, there must be at least one Endpoint Security alert generated in the system. For non-production use, if no alerts exist, you can trigger a test alert using malware emulation techniques or tools such as the Anti Malware Testfile from the https://www.eicar.org/[European Institute for Computer Anti-Virus Research (EICAR)]. +==== + +[IMPORTANT] +==== +{ref}/binary.html[Binary fields] are not supported in detection rule exceptions. +==== + +. Do one of the following: ++ +** To add an Endpoint exception from the rule details page: ++ +... Go to the rule details page (**Rules** → **Detection rules (SIEM)**), and then search for and select the Elastic **Endpoint Security** rule. +... Scroll down the rule details page, select the **Endpoint exceptions** tab, then click **Add endpoint exception**. +** To add an Endpoint exception from the Alerts table: ++ +... Go to **Alerts**. +... Scroll down to the Alerts table, and from an {elastic-endpoint} +alert, click the **More actions** menu (image:images/icons/boxesHorizontal.svg[Actions menu]), then select **Add Endpoint exception**. +** To add an Endpoint exception from Shared Exception Lists page: ++ +... Go to **Rules** → **Shared exception lists**. +... Expand the Endpoint Security Exception List or click the list name to open the list's details page. Next, click **Add endpoint exception**. ++ +[NOTE] +==== +The Endpoint Security Exception List is automatically created. By default, it's associated with the Endpoint Security rule and any rules with the <> option selected. +==== ++ +The **Add Endpoint Exception** flyout opens. ++ +[role="screenshot"] +image::images/add-exceptions/-detections-endpoint-add-exp.png[] +. If required, modify the conditions. Refer to <> for more information on when nested conditions are required. ++ +[IMPORTANT] +==== +Rule exceptions are case-sensitive, which means that any character that's entered as an uppercase or lowercase letter will be treated as such. In the event you _don't_ want a field evaluated as case-sensitive, some ECS fields have a `.caseless` version that you can use. +==== ++ +[NOTE] +==== +* Fields with conflicts are marked with a warning icon (image:images/icons/warning.svg[Warning]). Using these fields might cause unexpected exceptions behavior. For more information, refer to <>. +* Identical, case-sensitive values are supported for the `is one of` and `is not one of` operators. For example, if you want to match the values `Windows` and `windows`, add both values to the **Value** field. +==== +. (Optional) Add a comment to the exception. +. You can select any of the following: ++ +** **Close this alert**: Closes the alert when the exception is added. This option +is only available when adding exceptions from the Alerts table. +** **Close all alerts that match this exception and were generated by this rule**: +Closes all alerts that match the exception's conditions. +. Click **Add Endpoint Exception**. An exception is created for both the detection rule and the {elastic-endpoint}. ++ +[NOTE] +==== +It might take longer for exceptions to be applied to hosts within larger deployments. +==== + +[discrete] +[[ex-nested-conditions]] +== Exceptions with nested conditions + +Some Endpoint objects contain nested fields, and the only way to ensure you are +excluding the correct fields is with nested conditions. One example is the +`process.Ext` object: + +[source,json] +---- +{ + "ancestry": [], + "code_signature": { + "trusted": true, + "subject_name": "LFC", + "exists": true, + "status": "trusted" + }, + "user": "WDAGUtilityAccount", + "token": { + "elevation": true, + "integrity_level_name": "high", + "domain": "27FB305D-3838-4", + "user": "WDAGUtilityAccount", + "elevation_type": "default", + "sid": "S-1-5-21-2047949552-857980807-821054962-504" + } +} +---- + +Only these objects require nested conditions to ensure the exception functions +correctly: + +* `Endpoint.policy.applied.artifacts.global.identifiers` +* `Endpoint.policy.applied.artifacts.user.identifiers` +* `Target.dll.Ext.code_signature` +* `Target.process.Ext.code_signature` +* `Target.process.Ext.token.privileges` +* `Target.process.parent.Ext.code_signature` +* `Target.process.thread.Ext.token.privileges` +* `dll.Ext.code_signature` +* `file.Ext.code_signature` +* `file.Ext.macro.errors` +* `file.Ext.macro.stream` +* `process.Ext.code_signature` +* `process.Ext.token.privileges` +* `process.parent.Ext.code_signature` +* `process.thread.Ext.token.privileges` + +[discrete] +[[add-exceptions-nested-condition-example]] +=== Nested condition example + +Creates an exception that excludes all LFC-signed trusted processes: + +[role="screenshot"] +image::images/add-exceptions/-detections-nested-exp.png[] + +[discrete] +[[manage-exception]] +== View and manage exceptions + +To view a rule's exceptions, open the rule's details page (**Rules** → **Detection rules (SIEM)** → **_Rule name_**), then scroll down and select the **Rule exceptions** or **Endpoint exceptions** tab. All exceptions that belong to the rule will display in a list. From the list, you can filter, edit, and delete exceptions. You can also toggle between **Active exceptions** and **Expired exceptions**. + +[role="screenshot"] +image::images/add-exceptions/-detections-manage-default-rule-list.png[A default rule list] + +[discrete] +[[rules-using-same-exception]] +== Find rules using the same exceptions + +To find out if an exception is used by other rules, select the **Rule exceptions** or **Endpoint exceptions** tab, navigate to an exception list item, then click **Affects _X_ rules**. + +[NOTE] +==== +Changes that you make to the exception also apply to other rules that use the exception. +==== + +[role="screenshot"] +image::images/add-exceptions/-detections-exception-affects-multiple-rules.png[Exception that affects multiple rules] diff --git a/docs/serverless/rules/alerts-ui-monitor.asciidoc b/docs/serverless/rules/alerts-ui-monitor.asciidoc new file mode 100644 index 0000000000..7b8bc18ed8 --- /dev/null +++ b/docs/serverless/rules/alerts-ui-monitor.asciidoc @@ -0,0 +1,235 @@ +[[alerts-ui-monitor]] += Monitor and troubleshoot rule executions + +:description: Find out how your rules are performing, and troubleshoot common rule issues. +:keywords: serverless, security, how-to, monitor, manage + +preview:[] + +Several tools can help you gain insight into the performance of your detection rules: + +* <> — The current state of all detection rules and their most recent executions. Go to the **Rule Monitoring** tab to get an overview of which rules are running, how long they're taking, and if they're having any trouble. +* <> — Historical data for a single detection rule's executions over time. Consult the execution results to understand how a particular rule is running and whether it's creating the alerts you expect. +* <> — Visualizations to help you monitor the overall health and performance of {elastic-sec}'s detection rules. Consult this dashboard for a high-level view of whether your rules are running successfully and how long they're taking to run, search data, and create alerts. + +Refer to the <> section below for strategies on adjusting rules if they aren't creating the expected alerts. + +[discrete] +[[rule-monitoring-tab]] +== Rule Monitoring tab + +To view a summary of all rule executions, including the most recent failures and execution +times, select the **Rule Monitoring** tab on the **Rules** page (**Rules** → +**Detection rules (SIEM)** → **Rule Monitoring**). + +[role="screenshot"] +image::images/alerts-ui-monitor/-detections-monitor-table.png[] + +On the **Rule Monitoring** tab, you can <> just like you can on the **Installed Rules** tab. + +[TIP] +==== +To sort the rules list, click any column header. To sort in descending order, click the column header again. +==== + +For detailed information on a rule, the alerts it generated, and associated errors, click on its name in the table. This also allows you to perform the same actions that are available on the <>, such as modifying or deleting rules, activating or deactivating rules, exporting or importing rules, and duplicating prebuilt rules. + +[discrete] +[[rule-execution-logs]] +== Execution results + +Each detection rule execution is logged, including the execution type, the execution's success or failure, any warning or error messages, how long it took to search for data, create alerts, and complete. This can help you troubleshoot a particular rule if it isn't behaving as expected (for example, if it isn't creating alerts or takes a long time to run). + +To access a rule's execution log, go to **Rules** → **Detection rules (SIEM)**, click the rule's name to open its details, then scroll down and select the **Execution results** tab. Within the Execution log table, you can click the arrow at the end of a row to expand a long warning or error message. + +[role="screenshot"] +image::images/alerts-ui-monitor/-detections-rule-execution-logs.png[Rule execution log on the rule execution results tab] + +You can hover over each column heading to display a tooltip about that column's data. Click a column heading to sort the table by that column. + +Use these controls to filter what's included in the logs table: + +* The **Run type** drop-down filters the table by rule execution type: ++ +** **Scheduled**: Automatic, scheduled rule executions. +** **Manual**: Rule executions that were <>. +* The **Status** drop-down filters the table by rule execution status: ++ +** **Succeeded**: The rule completed its defined search. This doesn't necessarily mean it generated an alert, just that it ran without error. +** **Failed**: The rule encountered an error that prevented it from running. For example, a {ml} rule whose corresponding {ml} job wasn't running. +** **Warning**: Nothing prevented the rule from running, but it might have returned unexpected results. For example, a custom query rule tried to search an index pattern that couldn't be found in {es}. +* The date and time picker sets the time range of rule executions included in the table. This is separate from the global date and time picker at the top of the rule details page. +* The **Source event time range** button toggles the display of data pertaining to the time range of manual runs. +* The **Show metrics columns** toggle includes more or less data in the table, pertaining to the timing of each rule execution. +* The **Actions** column allows you to show alerts generated from a given rule execution. Click the filter icon (image:images/icons/filterInCircle.svg[Filter]) to create a global search filter based on the rule execution's ID value. This replaces any previously applied filters, changes the global date and time range to 24 hours before and after the rule execution, and displays a confirmation notification. You can revert this action by clicking **Restore previous filters** in the notification. + +[discrete] +[[manual-runs-table]] +=== Manual runs table + +beta:[] + +Each manual run can produce multiple rule executions, depending on the time range of the run and the rule's execution schedule. These details are shown in the Manual runs table. + +To access the Manual runs table, navigate to the detection rules page, click the rule's name to open its details, then scroll down and select the **Execution results** tab. Scroll down again to find the Manual runs table. + +To stop an active run, go to the appropriate row and click **Stop run** in the **Actions** column. Completed rule executions for each manual run are logged in the Execution log table. + +[role="screenshot"] +image::images/alerts-ui-monitor/-detections-manual-rule-run-table.png[Manual rule runs table on the rule execution results tab] + +The Manual runs table displays important details such as: + +* The status of each manual run: ++ +** **Pending**: The rule is not yet running. +** **Running**: The rule is executing during the time range you specified. Some rules, such as indicator match rules, can take longer to run. +** **Error**: The rule's configuration is preventing it from running correctly. For example, the rule's conditions cannot be validated. +* When a manual run started and the time in which it will run +* The number of rule executions that are failing, pending, running, and completed for a manual run +* The total number of rule executions that are occurring for a manual run + +[discrete] +[[troubleshoot-signals]] +== Troubleshoot missing alerts + +When a rule fails to run close to its scheduled time, some alerts may be +missing. There are a number of ways to try to resolve this issue: + +* <> +* <> +* <> + +You can also use Task Manager in {kib} to troubleshoot background tasks and processes that may be related to missing alerts: + +* {kibana-ref}/task-manager-health-monitoring.html[Task Manager health monitoring] +* {kibana-ref}/task-manager-troubleshooting.html[Task Manager troubleshooting] + +// Will need to revisit this section since it references a Kibana feature that's not currently available in serverless Security + +[discrete] +[[troubleshoot-max-alerts]] +=== Troubleshoot maximum alerts warning + +When a rule reaches the maximum number of alerts it can generate during a single rule execution, the following warning appears on the rule's details page and in the rule execution log: `This rule reached the maximum alert limit for the rule execution. Some alerts were not created.` + +If you receive this warning, go to the rule's **Alerts** tab and check for anything unexpected. Unexpected alerts might be created from data source issues or queries that are too broadly scoped. To further reduce alert volume, you can also add <> or <>. + +[discrete] +[[troubleshoot-gaps]] +=== Troubleshoot gaps + +If you see values in the Gaps column in the Rule Monitoring table or on the Rule details page +for a small number of rules, you can increase those rules' +Additional look-back time (**Rules** → **Detection rules (SIEM)** → the rule's **All actions** menu (_..._) → **Edit rule settings** → **Schedule** → **Additional look-back time**). + +It's recommended to set the `Additional look-back time` to at +least 1 minute. This ensures there are no missing alerts when a rule doesn't +run exactly at its scheduled time. + +{elastic-sec} prevents duplication. Any duplicate alerts that are discovered during the +`Additional look-back time` are _not_ created. + +[NOTE] +==== +If the rule that experiences gaps is an indicator match rule, see <>. Also please note that {elastic-sec} provides <>. +==== + +If you see gaps for numerous rules: + +* If you restarted {kib} when many rules were activated, try deactivating them +and then reactivating them in small batches at staggered intervals. This +ensures {kib} does not attempt to run all the rules at the same time. +* Consider adding another {kib} instance to your environment. + +// Will need to revisit this section since it references Kibana. + +[discrete] +[[troubleshoot-ingestion-pipeline-delay]] +=== Troubleshoot ingestion pipeline delay + +// Will need to revisit this section since it mentions versions of the stack, Beats, and Agent. + +Even if your rule runs at its scheduled time, there might still be missing alerts if your ingestion pipeline delay is greater than your rule interval + additional look-back time. Prebuilt rules have a minimum interval + additional look-back time of 6 minutes. To avoid missed alerts for prebuilt rules, use caution to ensure that ingestion pipeline delays remain below 6 minutes. + +In addition, use caution when creating custom rule schedules to ensure that the specified interval + additional look-back time is greater than your deployment's ingestion pipeline delay. + +You can reduce the number of missed alerts due to ingestion pipeline delay by specifying the `Timestamp override` field value to `event.ingested` in <> during rule creation or editing. The detection engine uses the value from the `event.ingested` field as the timestamp when executing the rule. + +For example, say an event occurred at 10:00 but wasn't ingested into {es} until 10:10 due to an ingestion pipeline delay. If you created a rule to detect that event with an interval + additional look-back time of 6 minutes, and the rule executes at 10:12, it would still detect the event because the `event.ingested` timestamp was from 10:10, only 2 minutes before the rule executed and well within the rule's 6-minute interval + additional look-back time. + +[role="screenshot"] +image::images/alerts-ui-monitor/-detections-timestamp-override.png[] + +[discrete] +[[ml-job-compatibility]] +=== Troubleshoot missing alerts for {ml} jobs + +{ml-cap} detection rules use {ml} jobs that have dependencies on data fields populated by the {beats} and {agent} integrations. In {stack} version 8.3, new {ml} jobs (prefixed with `v3`) were released to operate on the ECS fields available at that time. + +If you're using 8.2 or earlier versions of {beats} or {agent} with {stack} version 8.3 or later, you may need to duplicate prebuilt rules or create new custom rules _before_ you update the Elastic prebuilt rules. Once you update the prebuilt rules, they will only use `v3` {ml} jobs. Duplicating the relevant prebuilt rules before updating them ensures continued coverage by allowing you to keep using `v1` or `v2` jobs (in the duplicated rules) while also running the new `v3` jobs (in the updated prebuilt rules). + +[IMPORTANT] +==== +* Duplicated rules may result in duplicate anomaly detections and alerts. +* Ensure that the relevant `v3` {ml} jobs are running before you update the Elastic prebuilt rules. +==== + +* If you only have **8.3 or later versions of {beats} and {agent}**: You can download or update your prebuilt rules and use the latest `v3` {ml} jobs. No additional action is required. +* If you only have **8.2 or earlier versions of {beats} or {agent}**, or **a mix of old and new versions**: To continue using the `v1` and `v2` {ml} jobs specified by pre-8.3 prebuilt detection rules, you must duplicate affected prebuilt rules _before_ updating them to the latest rule versions. The duplicated rules can continue using the same `v1` and `v2` {ml} jobs, and the updated prebuilt {ml} rules will use the new `v3` {ml} jobs. +* If you have **a non-Elastic data shipper that gathers ECS-compatible events**: You can use the latest `v3` {ml} jobs with no additional action required, as long as your data shipper uses the latest ECS specifications. However, if you're migrating from {ml} rules using `v1`/`v2` jobs, ensure that you start the relevant `v3` jobs before updating the Elastic prebuilt rules. + +The following Elastic prebuilt rules use the new `v3` {ml} jobs to generate alerts. Duplicate their associated `v1`/`v2` prebuilt rules _before_ updating them if you need continued coverage from the `v1`/`v2` {ml} jobs: + +//// +/* {/* Links to prebuilt rule pages temporarily removed for initial serverless docs. We can renable links once +we add prebuilt rule pages to the serverless docs.*/ +//// + +//// +/* +* Unusual Linux Network Port Activity: `v3_linux_anomalous_network_port_activity` + +* Anomalous Process For a Linux Population: `v3_linux_anomalous_process_all_hosts` + +* Unusual Linux Username: `v3_linux_anomalous_user_name` + +* Unusual Linux Process Calling the Metadata Service: `v3_linux_rare_metadata_process` + +* Unusual Linux User Calling the Metadata Service: `v3_linux_rare_metadata_user` + +* Unusual Process For a Linux Host: `v3_rare_process_by_host_linux` + +* Unusual Process For a Windows Host: `v3_rare_process_by_host_windows` + +* Unusual Windows Network Activity: `v3_windows_anomalous_network_activity` + +* Unusual Windows Path Activity: `v3_windows_anomalous_path_activity` + +* Anomalous Windows Process Creation: `v3_windows_anomalous_process_creation` + +* Anomalous Process For a Windows Population: `v3_windows_anomalous_process_all_hosts` + +* Unusual Windows Username: `v3_windows_anomalous_user_name` + +* Unusual Windows Process Calling the Metadata Service: `v3_windows_rare_metadata_process` + +* Unusual Windows User Calling the Metadata Service: `v3_windows_rare_metadata_user` +*/ +//// + +* Unusual Linux Network Port Activity: `v3_linux_anomalous_network_port_activity` +* Unusual Linux Network Connection Discovery: `v3_linux_anomalous_network_connection_discovery` +* Anomalous Process For a Linux Population: `v3_linux_anomalous_process_all_hosts` +* Unusual Linux Username: `v3_linux_anomalous_user_name` +* Unusual Linux Process Calling the Metadata Service: `v3_linux_rare_metadata_process` +* Unusual Linux User Calling the Metadata Service: `v3_linux_rare_metadata_user` +* Unusual Process For a Linux Host: `v3_rare_process_by_host_linux` +* Unusual Process For a Windows Host: `v3_rare_process_by_host_windows` +* Unusual Windows Network Activity: `v3_windows_anomalous_network_activity` +* Unusual Windows Path Activity: `v3_windows_anomalous_path_activity` +* Anomalous Windows Process Creation: `v3_windows_anomalous_process_creation` +* Anomalous Process For a Windows Population: `v3_windows_anomalous_process_all_hosts` +* Unusual Windows Username: `v3_windows_anomalous_user_name` +* Unusual Windows Process Calling the Metadata Service: `v3_windows_rare_metadata_process` +* Unusual Windows User Calling the Metadata Service: `v3_windows_rare_metadata_user` diff --git a/docs/serverless/rules/building-block-rule.asciidoc b/docs/serverless/rules/building-block-rule.asciidoc new file mode 100644 index 0000000000..fc4b00b730 --- /dev/null +++ b/docs/serverless/rules/building-block-rule.asciidoc @@ -0,0 +1,41 @@ +[[building-block-rules]] += Use building block rules + +:description: Set up building block rules and view building block alerts. +:keywords: serverless, security, how-to + +preview:[] + +Create building block rules when you do not want to see their generated alerts +in the UI. This is useful when you want: + +* A record of low-risk alerts without producing noise in the Alerts table. +* Rules that execute on the alert indices (`.alerts-security.alerts-`). +You can then use building block rules to create hidden alerts that act as a +basis for an 'ordinary' rule to generate visible alerts. + +[discrete] +[[building-block-rules-set-up-rules-that-run-on-alert-indices]] +== Set up rules that run on alert indices + +To create a rule that searches alert indices, select **Index Patterns** as the rule's **Source** and enter the index pattern for alert indices (`.alerts-security.alerts-*`): + +[role="screenshot"] +image::images/building-block-rule/-detections-alert-indices-ui.png[] + +[discrete] +[[building-block-rules-view-building-block-alerts-in-the-ui]] +== View building block alerts in the UI + +By default, building block alerts are excluded from the Overview and Alerts pages. +You can choose to include building block alerts on the Alerts page, which expands the number of alerts. + +. Go to **Alerts**. +. In the Alerts table, select **Additional filters** → +**Include building block alerts**, located on the far-right. + +[NOTE] +==== +On a building block rule details page, the rule's alerts are displayed (by +default, **Include building block alerts** is selected). +==== diff --git a/docs/serverless/rules/detection-engine-overview.asciidoc b/docs/serverless/rules/detection-engine-overview.asciidoc new file mode 100644 index 0000000000..9b1e785a84 --- /dev/null +++ b/docs/serverless/rules/detection-engine-overview.asciidoc @@ -0,0 +1,144 @@ +[[detection-engine-overview]] += Detection engine overview + +:description: Learn about the detection engine and its features. +:keywords: serverless, security, overview + +preview:[] + +Use the detection engine to create and manage rules and view the alerts +these rules create. Rules periodically search indices (such as `logs-*` and +`filebeat-*`) for suspicious source events and create alerts when a rule's +conditions are met. When an alert is created, its status is `Open`. To help +track investigations, an alert's <> can be set as +`Open`, `Acknowledged`, or `Closed`. + +[role="screenshot"] +image::images/detection-engine-overview/-detections-alert-page.png[Alerts page] + +In addition to creating <>, enable +<> to immediately start detecting +suspicious activity. For detailed information on all the prebuilt rules, see the <>. Once the prebuilt rules are loaded and +running, <> and <> explain +how to modify the rules to reduce false positives and get a better set of +actionable alerts. You can also use exceptions and value lists when creating or +modifying your own rules. + +There are two special prebuilt rules you need to know about: + +// Links to prebuilt rule pages temporarily removed for initial serverless docs. + +* **Endpoint Security**: +Automatically creates an alert from all incoming Elastic Endpoint alerts. To +receive Elastic Endpoint alerts, you must install the Endpoint agent on your +hosts (see <>). ++ +When this rule is enabled, the following Endpoint events are displayed as +detection alerts: ++ +** Malware Prevention Alert +** Malware Detection Alert ++ +[NOTE] +==== +When you load the prebuilt rules, this is the only rule that is enabled +by default. +==== + +// Links to prebuilt rule pages temporarily removed for initial serverless docs. + +* **External Alerts**: Automatically creates an alert for +all incoming third-party system alerts (for example, Suricata alerts). + +If you want to receive notifications via external systems, such as Slack or +email, when alerts are created, use the {kibana-ref}/alerting-getting-started.html[Alerting and Actions] framework. + +After rules have started running, you can monitor their executions to verify +they are functioning correctly, as well as view, manage, and troubleshoot +alerts (see <> and <>). + +You can create and manage rules and alerts via the UI or the {security-guide}/rule-api-overview.html[Detections API]. + +// Link to classic docs until serverless API docs are available. + +[IMPORTANT] +==== +To make sure you can access Detections and manage rules, see +<>. +==== + +[discrete] +[[support-indicator-rules]] +== Limited support for indicator match rules + +Indicator match rules provide a powerful capability to search your security data; however, their queries can consume significant deployment resources. When creating an <>, we recommend limiting the time range of the indicator index query to the minimum period necessary for the desired rule coverage. For example, the default indicator index query `@timestamp > "now-30d/d"` searches specified indicator indices for indicators ingested during the past 30 days and rounds the query start time down to the nearest day (resolves to UTC `00:00:00`). Without this limitation, the rule will include all of the indicators in your indicator indices, which may extend the time it takes for the indicator index query to complete. + +In addition, indicator match rules with an additional look-back time value greater than 24 hours are not supported. + +[discrete] +[[detections-permissions]] +== Detections configuration and prerequisites + +<> provides detailed information on all the +permissions required to initiate and use the Detections feature. + +[discrete] +[[malware-prevention]] +== Malware prevention + +Malware, short for malicious software, is any software program designed to damage or execute unauthorized actions on a +computer system. Examples of malware include viruses, worms, Trojan horses, adware, scareware, and spyware. Some +malware, such as viruses, can severely damage a computer's hard drive by deleting files or directory information. Other +malware, such as spyware, can obtain user data without their knowledge. + +Malware may be stealthy and appear as legitimate executable code, scripts, active content, and other software. It is also +often embedded in non-malicious files, non-suspicious websites, and standard programs — sometimes making the root +source difficult to identify. If infected and not resolved promptly, malware can cause irreparable damage to a computer +network. + +For information on how to enable malware protection on your host, see <>. + +[discrete] +[[machine-learning-model]] +=== Machine learning model + +To determine if a file is malicious or benign, a machine learning model looks for static attributes of files (without executing +the file) that include file structure, layout, and content. This includes information such as file header data, imports, exports, +section names, and file size. These attributes are extracted from millions of benign and malicious file samples, which then +are passed to a machine-learning algorithm that distinguishes a benign file from a malicious one. The machine learning +model is updated as new data is procured and analyzed. + +[discrete] +[[detection-engine-overview-threshold]] +=== Threshold + +A malware threshold determines the action the agent should take if malware is detected. The Elastic Agent uses a recommended threshold level that generates a balanced number of alerts with a low probability of undetected malware. This threshold also minimizes the number of false positive alerts. + +[discrete] +[[ransomware-prevention]] +== Ransomware prevention + +Ransomware is computer malware that installs discreetly on a user's computer and encrypts data until a specified amount of money (ransom) is paid. Ransomware is usually similar to other malware in its delivery and execution, infecting systems +through spear-phishing or drive-by downloads. If not resolved immediately, ransomware can cause irreparable damage to an entire computer network. + +Behavioral ransomware prevention on the Elastic Endpoint detects and stops ransomware attacks on Windows systems by analyzing data from low-level system processes, and is effective across an array of widespread ransomware families — including those targeting the system’s master boot record. + +For information on how to enable ransomware protection on your host, see <>. + +[discrete] +[[detection-engine-overview-resolve-ui-error-messages]] +=== Resolve UI error messages + +Depending on your user role privileges and whether detection system indices have already been created, you might get one of these error messages when you +open the **Alerts** or **Rules** page: + +* **`Let’s set up your detection engine`** ++ +If you get this message, a user with specific privileges must visit the +**Alerts** or **Rules** page before you can view detection alerts and rules. +Refer to <> for a list of all the requirements. +* **`Detection engine permissions required`** ++ +If you get this message, you do not have the +<> to view the **Detections** feature, +and you should contact your project administrator. diff --git a/docs/serverless/rules/detections-permissions-section.asciidoc b/docs/serverless/rules/detections-permissions-section.asciidoc new file mode 100644 index 0000000000..111c6df0fe --- /dev/null +++ b/docs/serverless/rules/detections-permissions-section.asciidoc @@ -0,0 +1,110 @@ +[[detections-requirements]] += Detections requirements + +:description: Requirements for setting up and configuring the detections feature. +:keywords: serverless, security, reference, manage + +preview:[] + +To use the <>, you first need to +configure a few settings. You also need the appropriate role to send +<> when detection alerts are generated. + +Additionally, there are some <> used to +configure <> upload limits. + +[discrete] +[[enable-detections-ui]] +== Enable and access detections + +To use the Detections feature, it must be enabled and you must have either the appropriate https://www.elastic.co/docs/current/serverless/general/assign-user-roles[predefined Security user role] or a https://www.elastic.co/docs/current/serverless/custom-roles[custom role] with privileges to access rules and alerts. If your role doesn't have the privileges needed to enable this feature, you can request someone who has these privileges to visit your {kib} space, which will turn it on for you. + +[NOTE] +==== +For instructions about using {ml} jobs and rules, refer to <>. +==== + +[discrete] +[[detections-requirements-custom-role-privileges]] +=== Custom role privileges + +The following table describes the required custom role privileges to access the Detections feature, including rules and alerts. For more information on {kib} privileges, refer to https://www.elastic.co/docs/current/serverless/custom-roles[]. + +|=== +| Action | Cluster Privilege | Index Privileges | {kib} Privileges + +| Enable detections in your space +| `manage` +a| `manage`, `write`, `read`, and `view_index_metadata` for these system indices and data streams, where `` is the space name: + +* `.alerts-security.alerts-` +* `.lists-` +* `.items-` +| `All` for the `Security` feature + +a| Enable detections in all spaces + +**NOTE:** To turn on detections, visit the Rules and Alerts pages for each space. +| `manage` +a| `manage`, `write`, `read`, and `view_index_metadata` for these system indices and data streams: + +* `.alerts-security.alerts-` +* `.lists-` +* `.items-` +| `All` for the `Security` feature + +| Preview rules +| N/A +a| `read` for these indices: + +* `.preview.alerts-security.alerts-` +* `.internal.preview.alerts-security.alerts--*` +| `All` for the `Security` feature + +| Manage rules +| N/A +a| `manage`, `write`, `read`, and `view_index_metadata` for these system indices and data streams, where `` is the space name: + +* `.alerts-security.alerts-` +* `.items-` +a| `All` for the `Security` feature + +**NOTE:** You need additional `Action and Connectors` feature privileges (**Management → Action and Connectors**) to manage rules with actions and connectors: + +* To provide full access to rule actions and connectors, give your role `All` privileges. With `Read` privileges, you can edit rule actions, but will have limited capabilities to manage connectors. For example, `Read` privileges allow you to add or remove an existing connector from a rule, but does not allow you to create a new connector. +* To import rules with actions, you need at least `Read` privileges for the `Action and Connectors` feature. To overwrite or add new connectors, you need `All` privileges for the `Actions and Connectors` feature. To import rules without actions, you don't need `Actions and Connectors` privileges. + +a| Manage alerts + +**NOTE**: Allows you to manage alerts, but not modify rules. +| N/A +a| `maintenance`, `write`, `read`, and `view_index_metadata` for these system indices and data streams, where `` is the space name: + +* `.alerts-security.alerts-` +* `.internal.alerts-security.alerts--*` +* `.lists-` +* `.items-` +| `Read` for the `Security` feature + +a| Create the `.lists` and `.items` data streams in your space + +**NOTE**: To initiate the process that creates the data streams, you must visit the Rules page for each appropriate space. +| `manage` +a| `manage`, `write`, `read`, and `view_index_metadata` for these data streams, where `` is the space name: + +* `.lists-` +* `.items-` +| `All` for the `Security` and `Saved Objects Management` features +|=== + +[discrete] +[[alerting-auth-model]] +=== Authorization + +Rules, including all background detection and the actions they generate, are authorized using an {kibana-ref}/api-keys.html[API key] associated with the last user to edit the rule. Upon creating or modifying a rule, an API key is generated for that user, capturing a snapshot of their privileges. The API key is then used to run all background tasks associated with the rule including detection checks and executing actions. + +[IMPORTANT] +==== +If a rule requires certain privileges to run, such as index privileges, keep in mind that if a user without those privileges updates the rule, the rule will no longer function. +==== diff --git a/docs/serverless/rules/detections-ui-exceptions.asciidoc b/docs/serverless/rules/detections-ui-exceptions.asciidoc new file mode 100644 index 0000000000..4b76651e8c --- /dev/null +++ b/docs/serverless/rules/detections-ui-exceptions.asciidoc @@ -0,0 +1,36 @@ +[[rule-exceptions]] += Rule exceptions + +:description: Understand the different types of rule exceptions. +:keywords: serverless, security, overview + +preview:[] + +You can associate rule exceptions with detection and endpoint rules to prevent trusted processes and network activity from generating unnecessary alerts, therefore, reducing the number of false positives. + +When creating exceptions, you can assign them to <> or to <>. + +[discrete] +[[rule-exceptions-intro]] +== Exceptions for individual rules + +Exceptions, also referred to as _exception items_, contain the source event conditions that determine when alerts shouldn't be generated. + +You can create exceptions that apply exclusively to a single rule. These types of exceptions can't be used by other rules, and you must manage them from the rule’s details page. To learn more about creating and managing single-rule exceptions, refer to <>. + +[role="screenshot"] +image::images/detections-ui-exceptions/-detections-exception-item-example.png[An exception item] + +[NOTE] +==== +You can also use <> to define exceptions for detection rules. Value lists allow you to match an exception against a list of possible values. +==== + +[discrete] +[[shared-exception-list-intro]] +== Exceptions shared among multiple rules + +If you want an exception to apply to multiple rules, you can add an exception to a shared exception list. Shared exception lists allow you to group exceptions together and then associate them with multiple rules. Refer to <> to learn more. + +[role="screenshot"] +image::images/detections-ui-exceptions/-detections-rule-exceptions-page.png[Shared Exception Lists page] diff --git a/docs/serverless/rules/interactive-investigation-guides.asciidoc b/docs/serverless/rules/interactive-investigation-guides.asciidoc new file mode 100644 index 0000000000..ef363f7a31 --- /dev/null +++ b/docs/serverless/rules/interactive-investigation-guides.asciidoc @@ -0,0 +1,138 @@ +[[interactive-investigation-guides]] += Launch Timeline from investigation guides + +:description: Pivot from detection alerts to investigations with interactive investigation guide actions. +:keywords: serverless, security, how-to, analyze, configure + +preview:[] + +Detection rule investigation guides suggest steps for triaging, analyzing, and responding to potential security issues. For custom rules, you can create an interactive investigation guide that includes buttons for launching runtime queries in <>, using alert data and hard-coded literal values. This allows you to start detailed Timeline investigations directly from an alert using relevant data. + +[role="screenshot"] +image::images/interactive-investigation-guides/-detections-ig-alert-flyout.png[Alert details flyout with interactive investigation guide] + +Under the Investigation section, click **Show investigation guide** to open the **Investigation** tab in the left panel of the alert details flyout. + +[role="screenshot"] +image::images/interactive-investigation-guides/-detections-ig-alert-flyout-invest-tab.png[Alert details flyout with interactive investigation guide] + +The **Investigation** tab displays query buttons, and each query button displays the number of event documents found. Click the query button to automatically load the query in Timeline, based on configuration settings in the investigation guide. + +[role="screenshot"] +image::images/interactive-investigation-guides/-detections-ig-timeline.png[Timeline with query pre-loaded from investigation guide action] + +[discrete] +[[add-ig-actions-rule]] +== Add investigation guide actions to a rule + +[NOTE] +==== +You can only create interactive investigation guides with custom rules because Elastic prebuilt rules can't be edited. However, you can duplicate a prebuilt rule, then configure the investigation guide for the duplicated rule. +==== + +You can configure an interactive investigation guide when you <> or <>. + +. When configuring the rule's settings (the **About rule** step for a new rule, or the **About** tab for an existing rule), expand the **Advanced settings**, then scroll down to the **Investigation guide** Markdown editor. ++ +[role="screenshot"] +image::images/interactive-investigation-guides/-detections-ig-investigation-guide-editor.png[Investigation guide editor field] +. Place the editor cursor where you want to add the query button in the investigation guide, then select the Investigate icon in the toolbar. The **Add investigation query** builder form appears. ++ +[role="screenshot"] +image:images/interactive-investigation-guides/-detections-ig-investigation-query-builder.png[Add investigation guide UI] +. Complete the query builder form to create an investigation query: ++ +.. **Label**: Enter the text to appear on the query button. +.. **Description**: (Optional) Enter additional text to include with the button. +.. **Filters**: Select fields, operators, and values to build the query. Click **OR** or **AND** to create multiple filters and define their relationships. ++ +To use a field value from the alert as a query parameter, enter the field name surrounded by double curly brackets — such as `{{kibana.alert.example}}` — as a custom option for the filter value. ++ +[role="screenshot"] +image:images/interactive-investigation-guides/-detections-ig-filters-field-custom-value.png[Add investigation guide UI] +.. **Relative time range**: (Optional) Select a time range to limit the query, relative to the alert's creation time. +. Click **Save changes**. The syntax is added to the investigation guide editor. ++ +[NOTE] +==== +If you need to change the query button's configuration, you can either edit the syntax directly in the editor (refer to the <> below), or delete the syntax and use the query builder form to recreate the query. +==== +. Save and enable the rule. + +[discrete] +[[query-button-syntax]] +=== Query button syntax + +The following syntax defines a query button in an interactive investigation guide. + +|=== +| Field | Description + +| `!{investigate{ }}` +| The container object holding all the query button's configuration attributes. + +| `label` +| Identifying text on the button. + +| `description` +| Additional text included with the button. + +| `providers` +a| A two-level nested array that defines the query to run in Timeline. Similar to the structure of queries in Timeline, items in the outer level are joined by an `OR` relationship, and items in the inner level are joined by an `AND` relationship. + +Each item in `providers` corresponds to a filter created in the query builder UI and is defined by these attributes: + +* `field`: The name of the field to query. +* `excluded`: Whether the query result is excluded (such as **is not one of**) or included (_is one of_). +* `queryType`: The query type used to filter events, based on the filter's operator. For example, `phrase` or `range`. +* `value`: The value to search for. Either a hard-coded literal value, or the name of an alert field (in double curly brackets) whose value you want to use as a query parameter. +* `valueType`: The data type of `value`, such as `string` or `boolean`. + +| `relativeFrom`, `relativeTo` +| (Optional) The start and end, respectively, of the relative time range for the query. Times are relative to the alert's creation time, represented as `now` in {ref}/common-options.html#date-math[date math] format. For example, selecting **Last 15 minutes** in the query builder form creates the syntax `"relativeFrom": "now-15m", "relativeTo": "now"`. +|=== + +[NOTE] +==== +Some characters must be escaped with a backslash, such as `\"` for a quotation mark and `\` for a literal backslash. Divide Windows paths with double backslashes (for example, `C:\Windows\explorer.exe`), and paths that already include double backslashes might require four backslashes for each divider. A clickable error icon (image:images/icons/error.svg[Error]) displays below the Markdown editor if there are any syntax errors. +==== + +[discrete] +[[interactive-investigation-guides-example-syntax]] +=== Example syntax + +[source,json] +---- +!{investigate{ + "label": "Test action", + "description": "Click to investigate.", + "providers": [ + [ + {"field": "event.id", "excluded": false, "queryType": "phrase", "value": "{{event.id}}", "valueType": "string"} + ], + [ + {"field": "event.action", "excluded": false, "queryType": "phrase", "value": "rename", "valueType": "string"}, + {"field": "process.pid", "excluded": false, "queryType": "phrase", "value": "{{process.pid}}", "valueType": "string"} + ] + ], + "relativeFrom": "now-15m", + "relativeTo": "now" +}} +---- + +This example creates the following Timeline query, as illustrated below: + +`(event.id : )` +`OR (event.action : "rename" AND process.pid : )` + +[role="screenshot"] +image::images/interactive-investigation-guides/-detections-ig-timeline-query.png[Timeline query] + +[discrete] +[[interactive-investigation-guides-timeline-template-fields]] +=== Timeline template fields + +When viewing an interactive investigation guide in contexts unconnected to a specific alert (such a rule's details page), queries open as <>, and `parameter` fields are treated as Timeline template fields. + +[role="screenshot"] +image::images/interactive-investigation-guides/-detections-ig-timeline-template-fields.png[Timeline template] diff --git a/docs/serverless/rules/prebuilt-rules/prebuilt-rules-management.asciidoc b/docs/serverless/rules/prebuilt-rules/prebuilt-rules-management.asciidoc new file mode 100644 index 0000000000..ca79152b6f --- /dev/null +++ b/docs/serverless/rules/prebuilt-rules/prebuilt-rules-management.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rules-management]] += Install and manage Elastic prebuilt rules + +:description: Start detections quickly with prebuilt rules designed and updated by Elastic. +:keywords: serverless, security, how-to, manage + +++++ +Use Elastic prebuilt rules +++++ + +preview:[] + +Follow these guidelines to start using the {security-app}'s <>, keep them updated, and make sure they have the data needed to run successfully. + +* <> +* <> +* <> +* <> +* <> + +[NOTE] +==== +* Prebuilt rules don't start running by default. You must first install the rules, then enable them. After installation, only a few prebuilt rules will be enabled by default, such as the Endpoint Security rule. +* You can't modify most settings on Elastic prebuilt rules. You can only edit <> and <>. If you want to modify other settings on a prebuilt rule, you must first duplicate it, then make your changes to the duplicated rule. However, your customized rule is entirely separate from the original prebuilt rule, and will not get updates from Elastic if the prebuilt rule is updated. +==== + +[discrete] +[[load-prebuilt-rules]] +== Install and enable Elastic prebuilt rules + +. Go to **Rules** → **Detection rules (SIEM)**. The badge next to **Add Elastic rules** shows the number of prebuilt rules available for installation. ++ +[role="screenshot"] +image::images/prebuilt-rules-management/-detections-prebuilt-rules-add-badge.png[The Add Elastic Rules page] +. Click **Add Elastic rules**. ++ +[TIP] +==== +To examine the details of a rule before you install it, select the rule name. This opens the rule details flyout. +==== +. Do one of the following: ++ +** Install all available rules: Click **Install all**. +** Install a single rule: Click **Install rule** for that rule. +** Install multiple rules: Select the rules and click **Install _x_ selected rule(s)**. ++ +[TIP] +==== +Use the search bar and **Tags** filter to find the rules you want to install. For example, filter by `OS: Windows` if your environment only includes Windows endpoints. For more on tag categories, refer to <>. +==== ++ +[role="screenshot"] +image::images/prebuilt-rules-management/-detections-prebuilt-rules-add.png[The Add Elastic Rules page] +. Go back to the **Rules** page, search or filter for any rules you want to run, and do either of the following: ++ +** Enable a single rule: Turn on the rule's **Enabled** switch. +** Enable multiple rules: Select the rules, then click **Bulk actions** → **Enable**. + +Once you enable a rule, it starts running on its configured schedule. To confirm that it's running successfully, check its **Last response** status in the rules table, or open the rule's details page and check the <> tab. + +[discrete] +[[prebuilt-rule-tags]] +== Prebuilt rule tags + +Each prebuilt rule includes several tags identifying the rule's purpose, detection method, associated resources, and other information to help categorize your rules. These tags are category-value pairs; for example, `OS: Windows` indicates rules designed for Windows endpoints. Categories include: + +* `Data Source`: The application, cloud provider, data shipper, or Elastic integration providing data for the rule. +* `Domain`: A general category of data source types (such as cloud, endpoint, or network). +* `OS`: The host operating system, which could be considered another data source type. +* `Resources`: Additional rule resources such as investigation guides. +* `Rule Type`: Identifies if the rule depends on specialized resources (such as machine learning jobs or threat intelligence indicators), or if it's a higher-order rule built from other rules' alerts. +* `Tactic`: MITRE ATT&CK tactics that the rule addresses. +* `Threat`: Specific threats the rule detects (such as Cobalt Strike or BPFDoor). +* `Use Case`: The type of activity the rule detects and its purpose. Use cases include: ++ +** `Active Directory Monitoring`: Detects changes related to Active Directory. +** `Asset Visibility`: Detects changes to specified asset types. +** `Configuration Audit`: Detects undesirable configuration changes. +** `Guided Onboarding`: Example rule, used for {elastic-sec}'s guided onboarding tour. +** `Identity and Access Audit`: Detects activity related to identity and access management (IAM). +** `Log Auditing`: Detects activity on log configurations or storage. +** `Network Security Monitoring`: Detects network security configuration activity. +** `Threat Detection`: Detects threats. +** `Vulnerability`: Detects exploitation of specific vulnerabilities. + +[discrete] +[[select-all-prebuilt-rules]] +== Select and duplicate all prebuilt rules + +. Go to **Rules** → **Detection rules (SIEM)**, then select the **Elastic rules** filter. +. Click **Select all _x_ rules** above the rules table. +. Click **Bulk actions** → **Duplicate**. +. Select whether to duplicate the rules' exceptions, then click **Duplicate**. + +You can then modify the duplicated rules and, if required, delete the prebuilt ones. However, your customized rules are entirely separate from the original prebuilt rules, and will not get updates from Elastic if the prebuilt rules are updated. + +[discrete] +[[update-prebuilt-rules]] +== Update Elastic prebuilt rules + +Elastic regularly updates prebuilt rules to optimize their performance and ensure they detect the latest threats and techniques. When updated versions are available for your installed prebuilt rules, the **Rule Updates** tab appears on the **Rules** page, allowing you to update your installed rules with the latest versions. + +. Go to **Rules** → **Detection rules (SIEM)**, then select the **Rule Updates** tab. ++ +[NOTE] +==== +The **Rule Updates** tab doesn't appear if all your installed prebuilt rules are up to date. +==== ++ +[role="screenshot"] +image::images/prebuilt-rules-management/-detections-prebuilt-rules-update.png[The Rule Updates tab on the Rules page] +. (Optional) To examine the details of a rule's latest version before you update it, select the rule name. This opens the rule details flyout. ++ +Select the **Updates** tab to view rule changes field by field, or the **JSON view** tab to view changes for the entire rule in JSON format. Both tabs display side-by-side comparisons of the **Current rule** (what you currently have installed) and the **Elastic update** version (what you can choose to install). Deleted characters are highlighted in red; added characters are highlighted in green. ++ +To accept the changes and install the updated version, select **Update**. ++ +[role="screenshot"] +image::images/prebuilt-rules-management/prebuilt-rules-update-diff.png[Prebuilt rule comparison] +. Do one of the following to update prebuilt rules on the **Rules** page: ++ +** Update all available rules: Click **Update all**. +** Update a single rule: Click **Update rule** for that rule. +** Update multiple rules: Select the rules and click **Update _x_ selected rule(s)**. ++ +[TIP] +==== +Use the search bar and **Tags** filter to find the rules you want to update. For example, filter by `OS: Windows` if your environment only includes Windows endpoints. For more on tag categories, refer to <>. +==== diff --git a/docs/serverless/rules/prebuilt-rules/prebuilt-rules.asciidoc b/docs/serverless/rules/prebuilt-rules/prebuilt-rules.asciidoc new file mode 100644 index 0000000000..c6bf785c70 --- /dev/null +++ b/docs/serverless/rules/prebuilt-rules/prebuilt-rules.asciidoc @@ -0,0 +1,18 @@ +[[prebuilt-rules]] += Prebuilt rule reference + +:description: Learn more about Elastic's prebuilt detection rules. + +preview:[] + +Refer to the following documentation for more details about Elastic's prebuilt rules: + +|=== +| | + +| {security-guide}/prebuilt-rules.html[Prebuilt rule reference] +| Lists all available prebuilt rules. + +| {security-guide}/prebuilt-rules-downloadable-updates.html[Downloadable rule updates] +| Lists all updates to prebuilt detection rules. +|=== diff --git a/docs/serverless/rules/rules-coverage.asciidoc b/docs/serverless/rules/rules-coverage.asciidoc new file mode 100644 index 0000000000..64c3a9a0f0 --- /dev/null +++ b/docs/serverless/rules/rules-coverage.asciidoc @@ -0,0 +1,60 @@ +[[rules-coverage]] += MITRE ATT&CK® coverage + +:description: Review your current coverage of MITRE ATT&CK® tactics and techniques, based on installed rules. +:keywords: security, how-to, manage, analyze, visualize + +preview:[] + +The **MITRE ATT&CK® coverage** page (**Rules** → **MITRE ATT&CK® Coverage**) shows which https://attack.mitre.org[MITRE ATT&CK®] adversary tactics and techniques are covered by your installed and enabled detection rules. This includes both Elastic prebuilt rules and custom rules. + +Mirroring the MITRE ATT&CK® framework, columns represent major tactics, and cells within each column represent a tactic's related techniques. Cells are darker when a technique has more rules matching the current filters, as indicated in the **Legend** at the top. + +[NOTE] +==== +This page only includes the detection rules you currently have installed, and only rules that are mapped to MITRE ATT&CK®. The coverage page maps detections to the following https://attack.mitre.org/resources/updates/updates-april-2024[MITRE ATT&CK® version] used by {elastic-sec}: `v15.1`. Elastic prebuilt rules that aren't installed and custom rules that are either unmapped or mapped to a deprecated tactic or technique will not appear on the coverage map. + +You can map custom rules to tactics in **Advanced settings** when creating or editing a rule. +==== + +[role="screenshot"] +image::images/rules-coverage/-detections-rules-coverage.png[MITRE ATT&CK® coverage page] + +[discrete] +[[rules-coverage-filter-rules]] +== Filter rules + +Use the drop-down filters at the top of the page to control which of your installed detection rules are included in calculating coverage. + +* **Installed rule status**: Select to include **Enabled rules**, **Disabled rules**, or both. +* **Installed rule type**: Select to include **Elastic rules** (prebuilt rules), **Custom rules** (user-created rules), or both. + +You can also search for a tactic or technique name, technique number, or rule name in the search bar. The search bar acts as a filter for the coverage grid: only rules matching the search term will be included. + +[NOTE] +==== +Searches for tactics and techniques must match exactly, are case sensitive, and do _not_ support wildcards. +==== + +[discrete] +[[rules-coverage-expand-and-collapse-cells]] +== Expand and collapse cells + +Click **Collapse cells** or **Expand cells** to change how much information the cells display. Cells always include the technique's name and the number of sub-techniques covered by enabled rules. Expand the cells to also display counts of disabled and enabled rules for each technique. + +[NOTE] +==== +The counts inside cells are affected by how you filter the page. For example, if you filter the **Installed rule status** to only include **Enabled rules**, then all disabled rule counts will be 0 because disabled rules are filtered out. +==== + +[discrete] +[[rules-coverage-enable-rules]] +== Enable rules + +You can quickly enable all the rules for a specific technique that you've installed, but not enabled. Click the technique's cell, then click **Enable all disabled** in the popup that appears. + +[discrete] +[[rules-coverage-learn-more-about-techniques-and-sub-techniques]] +== Learn more about techniques and sub-techniques + +For more information on a specific technique and its sub-techniques, click the technique's cell, then click the title in the popup that appears. This opens a new browser tab with the technique's MITRE ATT&CK® documentation. diff --git a/docs/serverless/rules/rules-ui-create.asciidoc b/docs/serverless/rules/rules-ui-create.asciidoc new file mode 100644 index 0000000000..07927c9922 --- /dev/null +++ b/docs/serverless/rules/rules-ui-create.asciidoc @@ -0,0 +1,898 @@ +[[rules-create]] += Create a detection rule + +:description: Create detection rules to monitor your environment for suspicious and malicious behavior. +:keywords: serverless, security, defend, how-to, manage, secure + +preview:[] + +To create a new detection rule, follow these steps: + +. Define the <>. The configuration for this step varies depending on the rule type. +. Configure basic rule settings. +. Configure advanced rule settings (optional). +. Set the rule's schedule. +. Set up rule actions (optional). +. Set up response actions (optional). + +.Requirements +[NOTE] +==== +* To create detection rules, you must have access to data views, which requires the appropriate user role. +* You'll also need permissions to enable and view detections, manage rules, manage alerts, and preview rules. These permissions depend on the user role. Refer to <> for more information. +==== + +[TIP] +==== +At any step, you can <> before saving it to see what kind of results you can expect. +==== + +[discrete] +[[create-ml-rule]] +== Create a machine learning rule + +[IMPORTANT] +==== +To create or edit {ml} rules, you need an appropriate user role. Additionally, the selected {ml} job must be running for the rule to function correctly. +==== + +. Go to **Rules** → **Detection rules (SIEM)** → **Create new rule**. The **Create new rule** page displays. +. To create a rule based on a {ml} anomaly threshold, select **Machine Learning**, +then select: ++ +.. The required {ml} jobs. ++ +[NOTE] +==== +If a required job isn't currently running, it will automatically start when you finish configuring and enable the rule. +==== +.. The anomaly score threshold above which alerts are created. +. (Optional) Use **Suppress alerts by** to reduce the number of repeated or duplicate alerts created by the rule. Refer to <> for more information. ++ +[NOTE] +==== +Because {ml} rules generate alerts from anomalies, which don't contain source event fields, you can only use anomaly fields when configuring alert suppression. +==== ++ +//// +/* The following steps are repeated across multiple rule types. If you change anything +in these steps or sub-steps, apply the change to the other rule types, too. */ +//// +. (Optional) Add **Related integrations** to associate the rule with one or more {integrations-docs}[Elastic integrations]. This indicates the rule's dependency on specific integrations and the data they generate, and allows users to confirm each integration's <> when viewing the rule. ++ +.. Click **Add integration**, then select an integration from the list. You can also start typing an integration's name to find it faster. +.. Enter the version of the integration you want to associate with the rule, using https://semver.org/[semantic versioning]. For version ranges, you must use tilde or caret syntax. For example, `~1.2.3` is from 1.2.3 to any patch version less than 1.3.0, and `^1.2.3` is from 1.2.3 to any minor and patch version less than 2.0.0. +. Click **Continue** to <>. + +[discrete] +[[create-custom-rule]] +== Create a custom query rule + +. Go to **Rules** → **Detection rules (SIEM)** → **Create new rule**. The **Create new rule** page displays. +. To create a rule based on a KQL or Lucene query, select **Custom query**, +then: ++ +.. Define which {es} indices or data view the rule searches for alerts. +.. Use the filter and query fields to create the criteria used for detecting +alerts. ++ +The following example (based on the prebuilt rule Volume Shadow Copy Deleted or Resized via VssAdmin) detects when the `vssadmin delete shadows` +Windows command is executed: ++ +*** **Index patterns**: `winlogbeat-*` ++ +Winlogbeat ships Windows event logs to {elastic-sec}. +*** **Custom query**: `event.action:"Process Create (rule: ProcessCreate)" and process.name:"vssadmin.exe" and process.args:("delete" and "shadows")` ++ +Searches the `winlogbeat-*` indices for `vssadmin.exe` executions with +the `delete` and `shadow` arguments, which are used to delete a volume's shadow +copies. ++ +[role="screenshot"] +image::images/rules-ui-create/-detections-rule-query-example.png[Rule query example] +.. You can use saved queries (image:images/icons/filterInCircle.svg[Filter]) and queries from saved Timelines (**Import query from saved Timeline**) as rule conditions. ++ +When you use a saved query, the **Load saved query "_query name_" dynamically on each rule execution** check box appears: ++ +*** Select this to use the saved query every time the rule runs. This links the rule to the saved query, and you won't be able to modify the rule's **Custom query** field or filters because the rule will only use settings from the saved query. To make changes, modify the saved query itself. +*** Deselect this to load the saved query as a one-time way of populating the rule's **Custom query** field and filters. This copies the settings from the saved query to the rule, so you can then further adjust the rule's query and filters as needed. If the saved query is later changed, the rule will not inherit those changes. +. (Optional) Use **Suppress alerts by** to reduce the number of repeated or duplicate alerts created by the rule. Refer to <> for more information. ++ +//// +/* The following steps are repeated across multiple rule types. If you change anything +in these steps or sub-steps, apply the change to the other rule types, too. */ +//// +. (Optional) Create a list of **Required fields** that the rule needs to function. This list is informational only, to help users understand the rule; it doesn't affect how the rule actually runs. ++ +.. Click **Add required field**, then select a field from the index patterns or data view you specified for the rule. You can also start typing a field's name to find it faster, or type in an entirely new custom field. +.. Enter the field's data type. +. (Optional) Add **Related integrations** to associate the rule with one or more {integrations-docs}[Elastic integrations]. This indicates the rule's dependency on specific integrations and the data they generate, and allows users to confirm each integration's <> when viewing the rule. ++ +.. Click **Add integration**, then select an integration from the list. You can also start typing an integration's name to find it faster. +.. Enter the version of the integration you want to associate with the rule, using https://semver.org/[semantic versioning]. For version ranges, you must use tilde or caret syntax. For example, `~1.2.3` is from 1.2.3 to any patch version less than 1.3.0, and `^1.2.3` is from 1.2.3 to any minor and patch version less than 2.0.0. +. Click **Continue** to <>. + +[discrete] +[[create-threshold-rule]] +== Create a threshold rule + +. Go to **Rules** → **Detection rules (SIEM)** → **Create new rule**. The **Create new rule** page displays. +. To create a rule based on a source event field threshold, select **Threshold**, then: ++ +.. Define which {es} indices the rule analyzes for alerts. +.. Use the filter and query fields to create the criteria used for detecting +alerts. ++ +[NOTE] +==== +You can use saved queries (image:images/icons/filterInCircle.svg[Filter]) and queries from saved Timelines (**Import query from saved Timeline**) as rule conditions. +==== +.. Use the **Group by** and **Threshold** fields to determine which source event field is used as a threshold and the threshold's value. +.. Use the **Count** field to limit alerts by cardinality of a certain field. ++ +For example, if **Group by** is `source.ip, destination.ip` and its **Threshold** is `10`, an alert is generated for every pair of source and destination IP addresses that appear in at least 10 of the rule's search results. ++ +You can also leave the **Group by** field undefined. The rule then creates an alert when the number of search results is equal to or greater than the threshold value. If you set **Count** to limit the results by `process.name` >= 2, an alert will only be generated for source/destination IP pairs that appear with at least 2 unique process names across all events. ++ +[IMPORTANT] +==== +Alerts created by threshold rules are synthetic alerts that do not resemble the source documents. The alert itself only contains data about the fields that were aggregated over (the **Group by** fields). Other fields are omitted, because they can vary across all source documents that were counted toward the threshold. Additionally, you can reference the actual count of documents that exceeded the threshold from the `kibana.alert.threshold_result.count` field. +==== +. (Optional) Select **Suppress alerts** to reduce the number of repeated or duplicate alerts created by the rule. Refer to <> for more information. ++ +//// +/* The following steps are repeated across multiple rule types. If you change anything +in these steps or sub-steps, apply the change to the other rule types, too. */ +//// +. (Optional) Create a list of **Required fields** that the rule needs to function. This list is informational only, to help users understand the rule; it doesn't affect how the rule actually runs. ++ +.. Click **Add required field**, then select a field from the index patterns or data view you specified for the rule. You can also start typing a field's name to find it faster, or type in an entirely new custom field. +.. Enter the field's data type. +. (Optional) Add **Related integrations** to associate the rule with one or more {integrations-docs}[Elastic integrations]. This indicates the rule's dependency on specific integrations and the data they generate, and allows users to confirm each integration's <> when viewing the rule. ++ +.. Click **Add integration**, then select an integration from the list. You can also start typing an integration's name to find it faster. +.. Enter the version of the integration you want to associate with the rule, using https://semver.org/[semantic versioning]. For version ranges, you must use tilde or caret syntax. For example, `~1.2.3` is from 1.2.3 to any patch version less than 1.3.0, and `^1.2.3` is from 1.2.3 to any minor and patch version less than 2.0.0. +. Click **Continue** to <>. + +[discrete] +[[create-eql-rule]] +== Create an event correlation rule + +. Go to **Rules** → **Detection rules (SIEM)** → **Create new rule**. The **Create new rule** page displays. +. To create an event correlation rule using EQL, select **Event Correlation**, then: ++ +.. Define which {es} indices or data view the rule searches when querying for events. +.. Write an {ref}/eql-syntax.html[EQL query] that searches for matching events or a series of matching events. ++ +[TIP] +==== +To find events that are missing in a sequence, use the {ref}/eql-syntax.html#eql-missing-events[missing events] syntax. +==== ++ +For example, the following rule detects when `msxsl.exe` makes an outbound +network connection: ++ +*** **Index patterns**: `winlogbeat-*` ++ +Winlogbeat ships Windows events to {elastic-sec}. +*** **EQL query**: ++ +[source,eql] +---- +sequence by process.entity_id + [process + where event.type in ("start", "process_started") + and process.name == "msxsl.exe"] + [network + where event.type == "connection" + and process.name == "msxsl.exe" + and network.direction == "outgoing"] +---- ++ +Searches the `winlogbeat-*` indices for sequences of a `msxsl.exe` process start +event followed by an outbound network connection event that was started by the +`msxsl.exe` process. ++ +[role="screenshot"] +image::images/rules-ui-create/-detections-eql-rule-query-example.png[] ++ +[NOTE] +==== +For sequence events, the {security-app} generates a single alert when all events listed in the sequence are detected. To see the matched sequence events in more detail, you can view the alert in the Timeline, and, if all events came from the same process, open the alert in Analyze Event view. +==== +. (Optional) Click the EQL settings icon (image:images/icons/controlsVertical.svg[EQL settings]) to configure additional fields used by {ref}/eql.html#specify-a-timestamp-or-event-category-field[EQL search]: ++ +** **Event category field**: Contains the event classification, such as `process`, `file`, or `network`. This field is typically mapped as a field type in the {ref}/keyword.html[keyword family]. Defaults to the `event.category` ECS field. +** **Tiebreaker field**: Sets a secondary field for sorting events (in ascending, lexicographic order) if they have the same timestamp. +** **Timestamp field**: Contains the event timestamp used for sorting a sequence of events. This is different from the **Timestamp override** advanced setting, which is used for querying events within a range. Defaults to the `@timestamp` ECS field. +. preview:[] (Optional) Use **Suppress alerts by** to reduce the number of repeated or duplicate alerts created by the rule. Refer to <> for more information. ++ +//// +/* The following steps are repeated across multiple rule types. If you change anything +in these steps or sub-steps, apply the change to the other rule types, too. */ +//// +. (Optional) Create a list of **Required fields** that the rule needs to function. This list is informational only, to help users understand the rule; it doesn't affect how the rule actually runs. ++ +.. Click **Add required field**, then select a field from the index patterns or data view you specified for the rule. You can also start typing a field's name to find it faster, or type in an entirely new custom field. +.. Enter the field's data type. +. (Optional) Add **Related integrations** to associate the rule with one or more {integrations-docs}[Elastic integrations]. This indicates the rule's dependency on specific integrations and the data they generate, and allows users to confirm each integration's <> when viewing the rule. ++ +.. Click **Add integration**, then select an integration from the list. You can also start typing an integration's name to find it faster. +.. Enter the version of the integration you want to associate with the rule, using https://semver.org/[semantic versioning]. For version ranges, you must use tilde or caret syntax. For example, `~1.2.3` is from 1.2.3 to any patch version less than 1.3.0, and `^1.2.3` is from 1.2.3 to any minor and patch version less than 2.0.0. +. Click **Continue** to <>. + +[discrete] +[[create-indicator-rule]] +== Create an indicator match rule + +[NOTE] +==== +{elastic-sec} provides limited support for indicator match rules. See <> for more information. +==== + +. Go to **Rules** → **Detection rules (SIEM)** → **Create new rule**. The **Create new rule** page displays. +. To create a rule that searches for events whose specified field value matches the specified indicator field value in the indicator index patterns, select **Indicator Match**, then fill in the following fields: ++ +.. **Source**: The individual index patterns or data view that specifies what data to search. +.. **Custom query**: The query and filters used to retrieve the required results from +the {elastic-sec} event indices. For example, if you want to match documents that only contain a `destination.ip` address field, add `destination.ip : *`. ++ +[TIP] +==== +If you want the rule to check every field in the indices, use this +wildcard expression: `*:*`. +==== ++ +[NOTE] +==== +You can use saved queries (image:images/icons/filterInCircle.svg[Filter]) and queries from saved Timelines (**Import query from saved Timeline**) as rule conditions. +==== +.. **Indicator index patterns**: The indicator index patterns containing field values for which you want to generate alerts. This field is automatically populated with indices specified in the `securitySolution:defaultThreatIndex` advanced setting. For more information, see <>. ++ +[IMPORTANT] +==== +Data in indicator indices must be <>, and so it must contain a `@timestamp` field. +==== +.. **Indicator index query**: The query and filters used to filter the fields from +the indicator index patterns. The default query `@timestamp > "now-30d/d"` searches specified indicator indices for indicators ingested during the past 30 days and rounds the start time down to the nearest day (resolves to UTC `00:00:00`). +.. **Indicator mapping**: Compares the values of the specified event and indicator fields, and generates an alert if the values are identical. ++ +[NOTE] +==== +Only single-value fields are supported. +==== ++ +To define which field values are compared from the indices, add the following: ++ +*** **Field**: The field used for comparing values in the {elastic-sec} event +indices. +*** **Indicator index field**: The field used for comparing values in the indicator +indices. +.. You can add `AND` and `OR` clauses to define when alerts are generated. ++ +For example, to create a rule that generates alerts when `host.name` **and** +`destination.ip` field values in the `logs-*` or `packetbeat-*` {elastic-sec} indices +are identical to the corresponding field values in the `mock-threat-list` indicator +index, enter the rule parameters seen in the following image: ++ +[role="screenshot"] +image::images/rules-ui-create/-detections-indicator-rule-example.png[Indicator match rule settings] ++ +[TIP] +==== +Before you create rules, create <> so +they can be selected here. When alerts generated by the rule are investigated in the Timeline, Timeline query values are replaced with their corresponding alert field values. +==== +. (Optional) Use **Suppress alerts by** to reduce the number of repeated or duplicate alerts created by the rule. Refer to <> for more information. ++ +//// +/* The following steps are repeated across multiple rule types. If you change anything +in these steps or sub-steps, apply the change to the other rule types, too. */ +//// +. (Optional) Create a list of **Required fields** that the rule needs to function. This list is informational only, to help users understand the rule; it doesn't affect how the rule actually runs. ++ +.. Click **Add required field**, then select a field from the index patterns or data view you specified for the rule. You can also start typing a field's name to find it faster, or type in an entirely new custom field. +.. Enter the field's data type. +. (Optional) Add **Related integrations** to associate the rule with one or more {integrations-docs}[Elastic integrations]. This indicates the rule's dependency on specific integrations and the data they generate, and allows users to confirm each integration's <> when viewing the rule. ++ +.. Click **Add integration**, then select an integration from the list. You can also start typing an integration's name to find it faster. +.. Enter the version of the integration you want to associate with the rule, using https://semver.org/[semantic versioning]. For version ranges, you must use tilde or caret syntax. For example, `~1.2.3` is from 1.2.3 to any patch version less than 1.3.0, and `^1.2.3` is from 1.2.3 to any minor and patch version less than 2.0.0. +. Click **Continue** to <>. + +[discrete] +[[indicator-value-lists]] +=== Use value lists with indicator match rules + +While there are numerous ways you can add data into indicator indices, you can use value lists as the indicator match index in an indicator match rule. Take the following scenario, for example: + +You uploaded a value list of known ransomware domains, and you want to be notified if any of those domains matches a value contained in a domain field in your security event index pattern. + +. Upload a value list of indicators. +. Create an indicator match rule and fill in the following fields: ++ +.. **Index patterns**: The Elastic Security event indices on which the rule runs. +.. **Custom query**: The query and filters used to retrieve the required results from the Elastic Security event indices (e.g., `host.domain :*`). +.. **Indicator index patterns**: Value lists are stored in a hidden index called `.items-`. Enter the name of the {kib} space in which this rule will run in this field. +.. **Indicator index query**: Enter the value `list_id :`, followed by the name of the value list you want to use as your indicator index (uploaded in Step 1 above). +.. **Indicator mapping** ++ +*** **Field**: Enter the field from the Elastic Security event indices to be used for comparing values. +*** **Indicator index field**: Enter the type of value list you created (i.e., `keyword`, `text`, or `IP`). ++ +[TIP] +==== +If you don't remember this information, go to **Rules** → **Detection rules (SIEM)** → **Manage value lists**. Locate the appropriate value list and note the field in the corresponding `Type` column. (Examples include keyword, text, and IP.) +==== + +[role="screenshot"] +image::images/rules-ui-create/-detections-indicator_value_list.png[] + +[discrete] +[[create-new-terms-rule]] +== Create a new terms rule + +. Go to **Rules** → **Detection rules (SIEM)** → **Create new rule**. The **Create new rule** page displays. +. To create a rule that searches for each new term detected in source documents, select **New Terms**, then: ++ +.. Specify what data to search by entering individual {es} index patterns or selecting an existing data view. +.. Use the filter and query fields to create the criteria used for detecting +alerts. ++ +[NOTE] +==== +You can use saved queries (image:images/icons/filterInCircle.svg[Filter]) and queries from saved Timelines (**Import query from saved Timeline**) as rule conditions. +==== +.. Use the **Fields** menu to select a field to check for new terms. You can also select up to three fields to detect a combination of new terms (for example, a `host.ip` and `host.id` that have never been observed together before). ++ +[IMPORTANT] +==== +When checking multiple fields, each unique combination of values from those fields is evaluated separately. For example, a document with `host.name: ["host-1", "host-2", "host-3"]` and `user.name: ["user-1", "user-2", "user-3"]` has 9 (3x3) unique combinations of `host.name` and `user.name`. A document with 11 values in `host.name` and 10 values in `user.name` has 110 (11x10) unique combinations. The new terms rule only evaluates 100 unique combinations per document, so selecting fields with large arrays of values might cause incorrect results. +==== +.. Use the **History Window Size** menu to specify the time range to search in minutes, hours, or days to determine if a term is new. The history window size must be larger than the rule interval plus additional look-back time, because the rule will look for terms where the only time(s) the term appears within the history window is _also_ within the rule interval and additional look-back time. ++ +For example, if a rule has an interval of 5 minutes, no additional look-back time, and a history window size of 7 days, a term will be considered new only if the time it appears within the last 7 days is also within the last 5 minutes. Configure the rule interval and additional look-back time when you <>. +. (Optional) Use **Suppress alerts by** to reduce the number of repeated or duplicate alerts created by the rule. Refer to <> for more information. ++ +//// +/* The following steps are repeated across multiple rule types. If you change anything +in these steps or sub-steps, apply the change to the other rule types, too. */ +//// +. (Optional) Create a list of **Required fields** that the rule needs to function. This list is informational only, to help users understand the rule; it doesn't affect how the rule actually runs. ++ +.. Click **Add required field**, then select a field from the index patterns or data view you specified for the rule. You can also start typing a field's name to find it faster, or type in an entirely new custom field. +.. Enter the field's data type. +. (Optional) Add **Related integrations** to associate the rule with one or more {integrations-docs}[Elastic integrations]. This indicates the rule's dependency on specific integrations and the data they generate, and allows users to confirm each integration's <> when viewing the rule. ++ +.. Click **Add integration**, then select an integration from the list. You can also start typing an integration's name to find it faster. +.. Enter the version of the integration you want to associate with the rule, using https://semver.org/[semantic versioning]. For version ranges, you must use tilde or caret syntax. For example, `~1.2.3` is from 1.2.3 to any patch version less than 1.3.0, and `^1.2.3` is from 1.2.3 to any minor and patch version less than 2.0.0. +. Click **Continue** to <>. + +[discrete] +[[create-esql-rule]] +== Create an {esql} rule + +Use {ref}/esql.html[{esql}] to query your source events and aggregate event data. Query results are returned in a table with rows and columns. Each row becomes an alert. + +To create an {esql} rule: + +. Go to **Rules** → **Detection rules (SIEM)** → **Create new rule**. The **Create new rule** page appears. +. Select **{esql}**, then write a query. ++ +[NOTE] +==== +Refer to the sections below to learn more about <>, <>, and <>. +==== ++ +[TIP] +==== +Click the help icon (image:images/icons/iInCircle.svg[Click the ES|QL help icon]) to open the in-product reference documentation for all {esql} commands and functions. +==== +. (Optional) Use **Suppress alerts by** to reduce the number of repeated or duplicate alerts created by the rule. Refer to <> for more information. ++ +//// +/* The following steps are repeated across multiple rule types. If you change anything +in these steps or sub-steps, apply the change to the other rule types, too. */ +//// +. (Optional) Create a list of **Required fields** that the rule needs to function. This list is informational only, to help users understand the rule; it doesn't affect how the rule actually runs. ++ +.. Click **Add required field**, then select a field from the index patterns or data view you specified for the rule. You can also start typing a field's name to find it faster, or type in an entirely new custom field. +.. Enter the field's data type. +. (Optional) Add **Related integrations** to associate the rule with one or more {integrations-docs}[Elastic integrations]. This indicates the rule's dependency on specific integrations and the data they generate, and allows users to confirm each integration's <> when viewing the rule. ++ +.. Click **Add integration**, then select an integration from the list. You can also start typing an integration's name to find it faster. +.. Enter the version of the integration you want to associate with the rule, using https://semver.org/[semantic versioning]. For version ranges, you must use tilde or caret syntax. For example, `~1.2.3` is from 1.2.3 to any patch version less than 1.3.0, and `^1.2.3` is from 1.2.3 to any minor and patch version less than 2.0.0. +. Click **Continue** to <>. + +[discrete] +[[esql-rule-query-types]] +=== {esql} query types + +{esql} rule queries are loosely categorized into two types: aggregating and non-aggregating. + +[discrete] +[[esql-agg-query]] +==== Aggregating query + +Aggregating queries use {ref}/esql-functions-operators.html#esql-agg-functions[`STATS...BY`] functions to aggregate source event data. Alerts generated by a rule with an aggregating query only contain the fields that the {esql} query returns and any new fields that the query creates. + +[NOTE] +==== +A _new field_ is a field that doesn't exist in the query's source index and is instead created when the rule runs. You can access new fields in the details of any alerts that are generated by the rule. For example, if you use the `STATS...BY` function to create a column with aggregated values, the column is created when the rule runs and is added as a new field to any alerts that are generated by the rule. +==== + +Here is an example aggregating query: + +[source,esql] +---- +FROM logs-* +| STATS host_count = COUNT(host.name) BY host.name +| SORT host_count DESC +| WHERE host_count > 20 +---- + +* This query starts by searching logs from indices that match the pattern `logs-*`. +* The query then aggregates the count of events by `host.name`. +* Next, it sorts the result by `host_count` in descending order. +* Then, it filters for events where the `host_count` field appears more than 20 times during the specified rule interval. + +[NOTE] +==== +Rules that use aggregating queries might create duplicate alerts. This can happen when events that occur in the additional look-back time are aggregated both in the current rule execution and in a previous rule execution. +==== + +[discrete] +[[esql-non-agg-query]] +==== Non-aggregating query + +Non-aggregating queries don't use `STATS...BY` functions and don't aggregate source event data. Alerts generated by a non-aggregating query contain source event fields that the query returns, new fields the query creates, and all other fields in the source event document. + +[NOTE] +==== +A _new field_ is a field that doesn't exist in the query's source index and is instead created when the rule runs. You can access new fields in the details of any alerts that are generated by the rule. For example, if you use the {ref}/esql-commands.html#esql-eval[`EVAL`] command to append new columns with calculated values, the columns are created when the rule runs and are added as new fields to any alerts generated by the rule. +==== + +Here is an example non-aggregating query: + +[source,esql] +---- +FROM logs-* METADATA _id, _index, _version +| WHERE event.category == "process" AND event.id == "8a4f500d" +| LIMIT 10 +---- + +* This query starts by querying logs from indices that match the pattern `logs-*`. The `METADATA _id, _index, _version` operator allows <>. +* Next, the query filters events where the `event.category` is a process and the `event.id` is `8a4f500d`. +* Then, it limits the output to the top 10 results. + +[discrete] +[[esql-non-agg-query-dedupe]] +==== Turn on alert deduplication for rules using non-aggregating queries + +To deduplicate alerts, a query needs access to the `_id`, `_index`, and `_version` metadata fields of the queried source event documents. You can allow this by adding the `METADATA _id, _index, _version` operator after the `FROM` source command, for example: + +[source,esql] +---- +FROM logs-* METADATA _id, _index, _version +| WHERE event.category == "process" AND event.id == "8a4f500d" +| LIMIT 10 +---- + +When those metadata fields are provided, unique alert IDs are created for each alert generated by the query. + +When developing the query, make sure you don't {ref}/esql-commands.html#esql-drop[`DROP`] or filter out the `_id`, `_index`, or `_version` metadata fields. + +Here is an example of a query that fails to deduplicate alerts. It uses the `DROP` command to omit the `_id` property from the results table: + +[source,esql] +---- +FROM logs-* METADATA _id, _index, _version +| WHERE event.category == "process" AND event.id == "8a4f500d" +| DROP _id +| LIMIT 10 +---- + +Here is another example of an invalid query that uses the `KEEP` command to only return `event.*` fields in the results table: + +[source,esql] +---- +FROM logs-* METADATA _id, _index, _version +| WHERE event.category == "process" AND event.id == "8a4f500d" +| KEEP event.* +| LIMIT 10 +---- + +[discrete] +[[esql-query-design]] +=== Query design considerations + +When writing your query, consider the following: + +* The {ref}/esql-commands.html#esql-limit[`LIMIT`] command specifies the maximum number of rows an {esql} query returns and the maximum number of alerts created per rule run. Similarly, a detection rule's **Max alerts per run** setting specifies the maximum number of alerts it can create every time it runs. ++ +If the `LIMIT` value and **Max alerts per run** value are different, the rule uses the lower value to determine the maximum number of alerts the rule generates. +* When writing an aggregating query, use the {ref}/esql-commands.html#esql-stats-by[`STATS...BY`] command with fields that you want to search and filter for after alerts are created. For example, using the `host.name`, `user.name`, `process.name` fields with the `BY` operator of the `STATS...BY` command returns these fields in alert documents, and allows you to search and filter for them from the Alerts table. +* When configuring alert suppression on a non-aggregating query, we recommend sorting results by ascending `@timestamp` order. Doing so ensures that alerts are properly suppressed, especially if the number of alerts generated is higher than the **Max alerts per run** value. + +[discrete] +[[esql-rule-limitations]] +=== {esql} rule limitations + +If your {esql} query creates new fields that aren’t part of the ECS schema, they aren't mapped to the alerts index, so you can't search for or filter them in the Alerts table. As a workaround, create <>. + +[discrete] +[[custom-highlighted-esql-fields]] +=== Highlight fields returned by the {esql} rule query + +When configuring an {esql} rule's **<>**, you can specify any fields that the rule's aggregating or non-aggregating query return. This can help ensure that returned fields are visible in the alert details flyout while you're investigating alerts. + +[discrete] +[[rule-ui-basic-params]] +== Configure basic rule settings + +. In the **About rule** pane, fill in the following fields: ++ +.. **Name**: The rule's name. +.. **Description**: A description of what the rule does. +.. **Default severity**: Select the severity level of alerts created by the rule: ++ +*** **Low**: Alerts that are of interest but generally are not considered to be security incidents. Sometimes a combination of low severity alerts can indicate suspicious activity. +*** **Medium**: Alerts that require investigation. +*** **High**: Alerts that require an immediate investigation. +*** **Critical**: Alerts that indicate it is highly likely a security incident has occurred. +.. **Severity override** (optional): Select to use source event values to +override the **Default severity** in generated alerts. When selected, a UI +component is displayed where you can map the source event field values to +severity levels. The following example shows how to map severity levels to `host.name` +values: ++ +[role="screenshot"] +image::images/rules-ui-create/-detections-severity-mapping-ui.png[] ++ +[NOTE] +==== +For threshold rules, not all source event values can be used for overrides; only the fields that were aggregated over (the `Group by` fields) will contain data. Please also note that overrides are not supported for event correlation rules. +==== +.. **Default risk score**: A numerical value between 0 and 100 that indicates the risk of events detected by the rule. This setting changes to a default value when you change the **Severity** level, but you can adjust the risk score as needed. General guidelines are: ++ +*** `0` - `21` represents low severity. +*** `22` - `47` represents medium severity. +*** `48` - `73` represents high severity. +*** `74` - `100` represents critical severity. +.. **Risk score override** (optional): Select to use a source event value to +override the **Default risk score** in generated alerts. When selected, a UI +component is displayed to select the source field used for the risk +score. For example, if you want to use the source event's risk score in +alerts: ++ +[role="screenshot"] +image::images/rules-ui-create/-detections-risk-source-field-ui.png[] ++ +[NOTE] +==== +For threshold rules, not all source event values can be used for overrides; only the fields that were aggregated over (the `Group by` fields) will contain data. +==== +.. **Tags** (optional): Words and phrases used to categorize, filter, and search +the rule. +. Continue with **one** of the following: ++ +** <> +** <> + +[discrete] +[[rule-ui-advanced-params]] +== Configure advanced rule settings (optional) + +. Click **Advanced settings** and fill in the following fields where applicable: ++ +.. **Reference URLs** (optional): References to information that is relevant to +the rule. For example, links to background information. +.. **False positive examples** (optional): List of common scenarios that may produce +false-positive alerts. +.. **MITRE ATT&CKTM threats** (optional): Add relevant https://attack.mitre.org/[MITRE] framework tactics, techniques, and subtechniques. +.. **Custom highlighted fields** (optional): Specify highlighted fields for unique alert investigation flows. You can choose any fields that are available in the you selected for the rule's data source. ++ +After you create the rule, you can find all custom highlighted fields in the About section of the rule details page. If the rule has alerts, you can find custom highlighted fields in the <> section of the alert details flyout. +.. **Setup guide** (optional): Instructions on rule prerequisites such as required integrations, configuration steps, and anything else needed for the rule to work correctly. +.. **Investigation guide** (optional): Information for analysts investigating +alerts created by the rule. You can also add action buttons to <> or <> using alert data. +.. **Author** (optional): The rule's authors. +.. **License** (optional): The rule's license. +.. **Elastic endpoint exceptions** (optional): Adds all Elastic Endpoint Security +rule exceptions to this rule (refer to <> to learn more about adding endpoint exceptions). ++ +[NOTE] +==== +If you select this option, you can add <> on the Rule details page. Additionally, all future exceptions added to the Endpoint Security rule also affect this rule. +==== +.. **Building block** (optional): Select to create a building-block rule. By default, alerts generated from a building-block rule are not displayed in the UI. See <> for more information. +.. **Max alerts per run** (optional): Specify the maximum number of alerts the rule can create each time it runs. Default is 100. +.. **Indicator prefix override**: Define the location of indicator data within the structure of indicator documents. When the indicator match rule executes, it queries specified indicator indices and references this setting to locate fields with indicator data. This data is used to enrich indicator match alerts with metadata about matched threat indicators. The default value for this setting is `threat.indicator`. ++ +[IMPORTANT] +==== +If your threat indicator data is at a different location, update this setting accordingly to ensure alert enrichment can still be performed. +==== +.. **Rule name override** (optional): Select a source event field to use as the +rule name in the UI (Alerts table). This is useful for exposing, at a glance, +more information about an alert. For example, if the rule generates alerts from +Suricata, selecting `event.action` lets you see what action (Suricata category) +caused the event directly in the Alerts table. ++ +[NOTE] +==== +For threshold rules, not all source event values can be used for overrides; only the fields that were aggregated over (the `Group by` fields) will contain data. +==== +.. **Timestamp override** (optional): Select a source event timestamp field. When selected, the rule's query uses the selected field, instead of the default `@timestamp` field, to search for alerts. This can help reduce missing alerts due to network or server outages. Specifically, if your ingest pipeline adds a timestamp when events are sent to {es}, this avoids missing alerts due to ingestion delays. +However, if you know your data source has an inaccurate `@timestamp` value, it is recommended you select the **Do not use @timestamp as a fallback timestamp field** option to ignore the `@timestamp` field entirely. ++ +[TIP] +==== +The {filebeat-ref}/filebeat-module-microsoft.html[Microsoft] and +{filebeat-ref}/filebeat-module-google_workspace.html[Google Workspace] {filebeat} modules have an `event.ingested` timestamp field that can be used instead of the default `@timestamp` field. +==== +. Click **Continue**. The **Schedule rule** pane is displayed. ++ +[role="screenshot"] +image::images/rules-ui-create/-detections-schedule-rule.png[] +. Continue with <>. + +[discrete] +[[rule-schedule]] +== Set the rule's schedule + +. Select how often the rule runs. +. Optionally, add `Additional look-back time` to the rule. When defined, the +rule searches indices with the additional time. ++ +For example, if you set a rule to run every 5 minutes with an additional +look-back time of 1 minute, the rule runs every 5 minutes but analyzes the +documents added to indices during the last 6 minutes. ++ +[IMPORTANT] +==== +It is recommended to set the `Additional look-back time` to at +least 1 minute. This ensures there are no missing alerts when a rule does not +run exactly at its scheduled time. + +{elastic-sec} prevents duplication. Any duplicate alerts that are discovered during the +`Additional look-back time` are _not_ created. +==== +. Click **Continue**. The **Rule actions** pane is displayed. +. Do either of the following: ++ +** Continue onto <> and <> (optional). +** Create the rule (with or without activation). + +[discrete] +[[rule-notifications]] +== Set up rule actions (optional) + +Use actions to set up notifications sent via other systems when alerts are generated. + +[NOTE] +==== +To use actions for alert notifications, you need the appropriate user role. For more information, see <>. +==== + +. Select a connector type to determine how notifications are sent. For example, if you select the {jira} connector, notifications are sent to your {jira} system. ++ +[NOTE] +==== +Each action type requires a connector. Connectors store the +information required to send the notification from the external system. You can +configure connectors while creating the rule or in **Project settings** → **Management** → **{connectors-ui}**. For more +information, see {kibana-ref}/action-types.html[Action and connector types]. + +Some connectors that perform actions require less configuration. For example, you do not need to set the action frequency or variables for the {kibana-ref}/cases-action-type.html[Cases connector]. +==== +. After you select a connector, set its action frequency to define when notifications are sent: ++ +** **Summary of alerts**: Select this option to get a report that summarizes generated alerts, which you can review at your convenience. Alert summaries will be sent at the specified time intervals. ++ +[NOTE] +==== +When setting a custom notification frequency, do not choose a time that is shorter than the rule's execution schedule. +==== +** **For each alert**: Select this option to ensure notifications are sent every time new alerts are generated. +. (Optional) Specify additional conditions that need to be met for notifications to send. Click the toggle to enable a setting, then add the required details: ++ +** **If alert matches query**: Enter a KQL query that defines field-value pairs or query conditions that must be met for notifications to send. The query only searches alert documents in the indices specified for the rule. +** **If alert is generated during timeframe**: Set timeframe details. Notifications are only sent if alerts are generated within the timeframe you define. +. Complete the required connector type fields. Here is an example with {jira}: ++ +[role="screenshot"] +image::images/rules-ui-create/-detections-selected-action-type.png[] +. Use the default notification message or customize it. You can add more context to the message by clicking the icon above the message text box and selecting from a list of available <>. +. Create the rule with or without activation. ++ +[NOTE] +==== +When you activate a rule, it is queued, and its schedule is determined by +its initial run time. For example, if you activate a rule that runs every 5 +minutes at 14:03 but it does not run until 14:04, it will run again at 14:09. +==== + +[IMPORTANT] +==== +After you activate a rule, you can check if it is running as expected +using the <> on the Rules page. If you see +values in the `Gap` column, you can <>. + +When a rule fails to run, the {security-app} tries to rerun it at its next +scheduled run time. +==== + +[discrete] +[[rule-action-variables]] +=== Alert notification placeholders + +You can use http://mustache.github.io/[mustache syntax] to add variables to notification messages. The action frequency you choose determines the variables you can select from. + +The following variables can be passed for all rules: + +[NOTE] +==== +Refer to {kibana-ref}/rule-action-variables.html#alert-summary-action-variables[Action frequency: Summary of alerts] to learn about additional variables that can be passed if the rule's action frequency is **Summary of alerts**. +==== + +* `{{context.alerts}}`: Array of detected alerts +* `{{{context.results_link}}}`: URL to the alerts +* `{{context.rule.anomaly_threshold}}`: Anomaly threshold score above which +alerts are generated {(ml} rules only) +* `{{context.rule.description}}`: Rule description +* `{{context.rule.false_positives}}`: Rule false positives +* `{{context.rule.filters}}`: Rule filters (query rules only) +* `{{context.rule.id}}`: Unique rule ID returned after creating the rule +* `{{context.rule.index}}`: Indices rule runs on (query rules only) +* `{{context.rule.language}}`: Rule query language (query rules only) +* `{{context.rule.machine_learning_job_id}}`: ID of associated {ml} job {(ml} +rules only) +* `{{context.rule.max_signals}}`: Maximum allowed number of alerts per rule +execution +* `{{context.rule.name}}`: Rule name +* `{{context.rule.query}}`: Rule query (query rules only) +* `{{context.rule.references}}`: Rule references +* `{{context.rule.risk_score}}`: Default rule risk score ++ +[NOTE] +==== +This placeholder contains the rule's default values even when the **Risk score override** option is used. +==== +* `{{context.rule.rule_id}}`: Generated or user-defined rule ID that can be +used as an identifier across systems +* `{{context.rule.saved_id}}`: Saved search ID +* `{{context.rule.severity}}`: Default rule severity ++ +[NOTE] +==== +This placeholder contains the rule's default values even when the **Severity override** option is used. +==== +* `{{context.rule.threat}}`: Rule threat framework +* `{{context.rule.threshold}}`: Rule threshold values (threshold rules only) +* `{{context.rule.timeline_id}}`: Associated Timeline ID +* `{{context.rule.timeline_title}}`: Associated Timeline name +* `{{context.rule.type}}`: Rule type +* `{{context.rule.version}}`: Rule version +* `{{date}}`: Date the rule scheduled the action +* `{{kibanaBaseUrl}}`: Configured `server.publicBaseUrl` value, or empty string if not configured +* `{{rule.id}}`: ID of the rule +* `{{rule.name}}`: Name of the rule +* `{{rule.spaceId}}`: Space ID of the rule +* `{{rule.tags}}`: Tags of the rule +* `{{rule.type}}`: Type of rule +* `{{state.signals_count}}`: Number of alerts detected + +The following variables can only be passed if the rule’s action frequency is for each alert: + +* `{{alert.actionGroup}}`: Action group of the alert that scheduled actions for the rule +* `{{alert.actionGroupName}}`: Human-readable name of the action group of the alert that scheduled actions for the rule +* `{{alert.actionSubgroup}}`: Action subgroup of the alert that scheduled actions for the rule +* `{{alert.id}}`: ID of the alert that scheduled actions for the rule +* `{{alert.flapping}}`: A flag on the alert that indicates whether the alert status is changing repeatedly + +[discrete] +[[placeholder-examples]] +==== Alert placeholder examples + +To understand which fields to parse, see the {security-guide}/rule-api-overview.html[Detections API] to view the JSON representation of rules. + +// Link to classic docs until serverless API docs are available. + +Example using `{{context.rule.filters}}` to output a list of filters: + +[source,json] +---- +{{#context.rule.filters}} +{{^meta.disabled}}{{meta.key}} {{#meta.negate}}NOT {{/meta.negate}}{{meta.type}} {{^exists}}{{meta.value}}{{meta.params.query}}{{/exists}}{{/meta.disabled}} +{{/context.rule.filters}} +---- + +Example using `{{context.alerts}}` as an array, which contains each alert generated since the last time the action was executed: + +[source,json] +---- +{{#context.alerts}} +Detection alert for user: {{user.name}} +{{/context.alerts}} +---- + +Example using the mustache "current element" notation `{{.}}` to output all the rule references in the `signal.rule.references` array: + +[source,json] +---- +{{#signal.rule.references}} {{.}} {{/signal.rule.references}} +---- + +[discrete] +[[rule-response-action]] +=== Set up response actions (optional) + +Use response actions to set up additional functionality that will run whenever a rule executes: + +* **Osquery**: Include live Osquery queries with a custom query rule. When an alert is generated, Osquery automatically collects data on the system related to the alert. Refer to <> to learn more. +* **{elastic-defend}**: Automatically run response actions on an endpoint when rule conditions are met. For example, you can automatically isolate a host or terminate a process when specific activities or events are detected on the host. Refer to <> to learn more. + +[IMPORTANT] +==== +Host isolation involves quarantining a host from the network to prevent further spread of threats and limit potential damage. Be aware that automatic host isolation can cause unintended consequences, such as disrupting legitimate user activities or blocking critical business processes. +==== + +[discrete] +[[preview-rules]] +== Preview your rule (optional) + +You can preview any custom or prebuilt rule to find out how noisy it will be. For a custom rule, you can then adjust the rule's query or other settings. + +[NOTE] +==== +To preview rules, you must have the appropriate user role. Refer to <> for more information. +==== + +Click the **Rule preview** button while creating or editing a rule. The preview opens in a side panel, showing a histogram and table with the alerts you can expect, based on the defined rule settings and past events in your indices. + +[role="screenshot"] +image::images/rules-ui-create/-detections-preview-rule.png[Rule preview] + +The preview also includes the effects of rule exceptions and override fields. In the histogram, alerts are stacked by `event.category` (or `host.name` for machine learning rules), and alerts with multiple values are counted more than once. + +To interact with the rule preview: + +* Use the date and time picker to define the preview's time range. ++ +[TIP] +==== +Avoid setting long time ranges with short rule intervals, or the rule preview might time out. +==== +* Click **Refresh** to update the preview. ++ +** When you edit the rule's settings or the preview's time range, the button changes from blue to green to indicate that the rule has been edited since the last preview. +** For a relative time range (such as `Last 1 hour`), refresh the preview to check for the latest results. (Previews don't automatically refresh with new incoming data.) +* Click the **View details** icon (image:images/icons/expand.svg[View details]) in the alerts table to view the details of a particular alert. +* To resize the preview, hover between the rule settings and preview, then click and drag the border. You can also click the border, then the collapse icon (image:images/icons/menuRight.svg[Collapse menu]) to collapse and expand the preview. +* To close the preview, click the **Rule preview** button again. + +[discrete] +[[view-rule-es-queries]] +=== View your rule's {es} queries (optional) + +[NOTE] +==== +This option is only offered for {esql} and event correlation rules. +==== + +When previewing a rule, you can also learn about its {es} queries, which are submitted when the rule runs. This information can help you identify and troubleshoot potential rule issues. You can also use it to confirm that your rule is retrieving the expected data. + +To learn more about your rule's {es} queries, preview its results and do the following: + +. Select the **Show {es} requests, ran during rule executions** option below the preview's date and time picker. The **Preview logged results** section displays under the histogram and alerts table. +. Click the **Preview logged results** section to expand it. Within the section, each rule execution is shown on an individual row. +. Expand each row to learn more about the {es} queries that the rule submits each time it executes. The following details are provided: ++ +** When it started, and how long it took to complete +** A brief explanation of what the {es} queries do +** The actual {es} queries that the rule submits to indices containing events that are used during the rule execution ++ +[TIP] +==== +Run the queries in https://www.elastic.co/docs/current/serverless/devtools/run-api-requests-in-the-console[Console] to determine if your rule is retrieving the expected data. For example, to test your rule’s exceptions, run the rule’s {es} queries, which will also contain exceptions added to the rule. If your rule’s exceptions are working as intended, the query will not return events that should be ignored. +==== diff --git a/docs/serverless/rules/rules-ui-management.asciidoc b/docs/serverless/rules/rules-ui-management.asciidoc new file mode 100644 index 0000000000..df2e9f8e92 --- /dev/null +++ b/docs/serverless/rules/rules-ui-management.asciidoc @@ -0,0 +1,239 @@ +[[rules-ui-management]] += Manage detection rules + +:description: Manage your detection rules and enable Elastic prebuilt rules on the Rules page. +:keywords: serverless, security, how-to, manage + +preview:[] + +The Rules page allows you to view and manage all prebuilt and custom detection rules. + +[role="screenshot"] +image::images/rules-ui-management/-detections-all-rules.png[The Rules page] + +On the Rules page, you can: + +* <> +* <> +* <> +* <> +* <> +* <> +* <> +* <> +* <> + +[discrete] +[[sort-filter-rules]] +== Sort and filter the rules list + +To sort the rules list, click any column header. To sort in descending order, click the column header again. + +To filter the rules list, enter a search term in the search bar and press **Return**: + +* Rule name — Enter a word or phrase from a rule's name. +* Index pattern — Enter an index pattern (such as `filebeat-*`) to display all rules that use it. +* MITRE ATT&CK tactic or technique — Enter a MITRE ATT&CK tactic name (such as `Defense Evasion`) or technique number (such as `TA0005`) to display all associated rules. + +[NOTE] +==== +Searches for index patterns and MITRE ATT&CK tactics and techniques must match exactly, are case sensitive, and do _not_ support wildcards. For example, to find rules using the `filebeat-*` index pattern, the search term `filebeat-*` is valid, but `filebeat` and `file*` are not because they don't exactly match the index pattern. Likewise, the MITRE ATT&CK tactic `Defense Evasion` is valid, but `Defense`, `defense evasion`, and `Defense*` are not. +==== + +You can also filter the rules list by selecting the **Tags**, **Last response**, **Elastic rules**, **Custom rules**, **Enabled rules**, and **Disabled rules** filters next to the search bar. + +The rules list retains your sorting and filtering settings when you navigate away and return to the page. These settings are also preserved when you copy the page's URL and paste into another browser. Select **Clear filters** above the table to revert to the default view. + +[discrete] +[[rule-status]] +== Check the current status of rules + +The **Last response** column displays the current status of each rule, based on the most recent attempt to run the rule: + +* **Succeeded**: The rule completed its defined search. This doesn't necessarily mean it generated an alert, just that it ran without error. +* **Failed**: The rule encountered an error that prevented it from running. For example, a {ml} rule whose corresponding {ml} job wasn't running. +* **Warning**: Nothing prevented the rule from running, but it might have returned unexpected results. For example, a custom query rule tried to search an index pattern that couldn't be found in {es}. + +For {ml} rules, an indicator icon (image:images/icons/warning.svg[Error]) also appears in this column if a required {ml} job isn't running. Click the icon to list the affected jobs, then click **Visit rule details page to investigate** to open the rule's details page, where you can start the {ml} job. + +[discrete] +[[edit-rules-settings]] +== Modify existing rules settings + +You can edit an existing rule's settings, and can bulk edit settings for multiple rules at once. + +[NOTE] +==== +For prebuilt Elastic rules, you can't modify most settings. You can only edit <> and <>. If you try to bulk edit with both prebuilt and custom rules selected, the action will affect only the rules that can be modified. + +Similarly, rules will be skipped if they can't be modified by a bulk edit. For example, if you try to apply a tag to rules that already have that tag, or apply an index pattern to rules that use data views. +==== + +. Go to **Rules** → **Detection rules (SIEM)**. +. Do one of the following: ++ +** **Edit a single rule**: Select the **All actions** menu (image:images/icons/boxesHorizontal.svg[Actions menu]) on a rule, then select **Edit rule settings**. The **Edit rule settings** view opens, where you can modify the <>. +** **Bulk edit multiple rules**: Select the rules you want to edit, then select an action from the **Bulk actions** menu: ++ +*** **Index patterns**: Add or delete the index patterns used by all selected rules. +*** **Tags**: Add or delete tags on all selected rules. +*** **Custom highlighted fields**: Add custom highlighted fields on all selected rules. You can choose any fields that are available in the <>, or enter field names from other indices. To overwrite a rule's current set of custom highlighted fields, select the **Overwrite all selected rules' custom highlighted fields** option, then click **Save**. +*** **Add rule actions**: Add <> on all selected rules. If you add multiple actions, you can specify an action frequency for each of them. To overwrite the frequency of existing actions select the option to **Overwrite all selected rules actions**. ++ +[NOTE] +==== +Rule actions won't run during a {kibana-ref}/maintenance-windows.html[maintenance window]. They'll resume running after the maintenance window ends. +==== +** **Update rule schedules**: Update the <> and look-back times on all selected rules. +** **Apply Timeline template**: Apply a specified <> to the selected rules. You can also choose **None** to remove Timeline templates from the selected rules. +. On the page or flyout that opens, update the rule settings and actions. ++ +[TIP] +==== +To <> rule actions, go to the **Actions** tab and click the bell icon. +==== +. If available, select **Overwrite all selected _x_** to overwrite the settings on the rules. For example, if you're adding tags to multiple rules, selecting **Overwrite all selected rules tags** removes all the rules' original tags and replaces them with the tags you specify. +. Click **Save**. + +[discrete] +[[manage-rules-ui]] +== Manage rules + +You can duplicate, enable, disable, delete, and snooze actions for rules: + +[NOTE] +==== +When duplicating a rule with exceptions, you can choose to duplicate the rule and its exceptions (active and expired), the rule and active exceptions only, or only the rule. If you duplicate the rule and its exceptions, copies of the exceptions are created and added to the duplicated rule's <>. If the original rule used exceptions from a shared exception list, the duplicated rule will reference the same shared exception list. +==== + +. Go to **Rules** → **Detection rules (SIEM)**. +. Do one of the following: ++ +** Select the **All actions** menu (image:images/icons/boxesHorizontal.svg[Actions menu]) on a rule, then select an action. +** Select all the rules you want to modify, then select an action from the **Bulk actions** menu. +** To enable or disable a single rule, switch on the rule's **Enabled** toggle. +** To <> actions for rules, click the bell icon. + +[discrete] +[[manually-run-rules]] +== Run rules manually + +beta:[] + +Manually run enabled rules for a specfied period of time for testing purposes or additional rule coverage. + +[IMPORTANT] +==== +Before manually running rules, make sure you properly understand and plan for rule dependencies. Incorrect scheduling can lead to inconsistent rule results. +==== + +. Navigate to the detection rules page, and do one of the following: ++ +** Select the **All actions** menu (image:images/icons/boxesHorizontal.svg[Actions menu]) on a rule, then select **Manual run**. +** Select all the rules you want to manually run, select the **Bulk actions** menu, then select **Manual run**. +. Specify when the manual run starts and ends. The default selection is the current day starting three hours in the past. The rule will search for events during the selected time range. +. Click **Run** to manually run the rule. ++ +[NOTE] +==== +Manual runs can produce multiple rule executions. This is determined by the manual run's time range and the rule's execution schedule. +==== + +The manual run's details are shown in the <> table on the **Execution results** tab. Changes you make to the manual run or rule settings will display in the Manual runs table after the current run completes. + +[NOTE] +==== +Be mindful of the following: + +* Rule actions are not activated during manual runs. +* Except for threshold rules, duplicate alerts aren't created if you manually run a rule during a time range that was already covered by a scheduled run. +* Manual runs are executed with low priority and limited concurrency, meaning they might take longer to complete. This can be especially apparent for rules requiring multiple executions. +==== + +[discrete] +[[snooze-rule-actions]] +== Snooze rule actions + +Instead of turning rules off to stop alert notifications, you can snooze rule actions for a specified time period. When you snooze rule actions, the rule continues to run on its defined schedule, but won't perform any actions or send alert notifications. + +You can snooze notifications temporarily or indefinitely. When actions are snoozed, you can cancel or change the duration of the snoozed state. You can also schedule and manage recurring downtime for actions. + +You can snooze rule notifications from the **Installed Rules** tab, the rule details page, or the **Actions** tab when editing a rule. + +[role="screenshot"] +image::images/rules-ui-management/-detections-rule-snoozing.png[Rules snooze options] + +[discrete] +[[import-export-rules-ui]] +== Export and import rules + +You can export custom detection rules to an `.ndjson` file, which you can then import into another {elastic-sec} environment. + +[NOTE] +==== +You cannot export Elastic prebuilt rules, but you can duplicate a prebuilt rule, then export the duplicated rule. + +If you try to export with both prebuilt and custom rules selected, only the custom rules are exported. +==== + +The `.ndjson` file also includes any actions, connectors, and exception lists related to the exported rules. However, other configuration items require additional handling when exporting and importing rules: + +* **Data views**: For rules that use a {kib} data view as a data source, the exported file contains the associated `data_view_id`, but does _not_ include any other data view configuration. To export/import between {kib} spaces, first use the {kibana-ref}/managing-saved-objects.html#managing-saved-objects-share-to-space[Saved Objects] UI (**Project settings** → **Content** → **Saved Objects**) to share the data view with the destination space. + +To import into a different {stack} deployment, the destination cluster must include a data view with a matching data view ID (configured in the {kibana-ref}/data-views.html[data view's advanced settings]). Alternatively, after importing, you can manually reconfigure the rule to use an appropriate data view in the destination system. + +* **Actions and connectors**: Rule actions and connectors are included in the exported file, but sensitive information about the connector (such as authentication credentials) _is not_ included. You must re-add missing connector details after importing detection rules. ++ +[TIP] +==== +You can also use the {kibana-ref}/managing-saved-objects.html#managing-saved-objects-share-to-space[Saved Objects] UI (**Project settings** → **Content** → **Saved Objects**) to export and import necessary connectors before importing detection rules. +==== +* **Value lists**: Any value lists used for rule exceptions are _not_ included in rule exports or imports. Use the <> UI (**Rules** → **Detection rules (SIEM)** → **Manage value lists**) to export and import value lists separately. + +To export and import detection rules: + +. Go to **Rules** → **Detection rules (SIEM)**. +. To export rules: ++ +.. In the rules table, select the rules you want to export. +.. Select **Bulk actions** → **Export**, then save the exported file. +. To import rules: ++ +[NOTE] +==== +To import rules with and without actions, and to manage rule connectors, you must have the appropriate user role. Refer to <> for more information. +==== ++ +.. Click **Import rules**. +.. Drag and drop the file that contains the detection rules. ++ +[NOTE] +==== +Imported rules must be in an `.ndjson` file. +==== +.. (Optional) Select **Overwrite existing detection rules with conflicting "rule_id"** to update existing rules if they match the `rule_id` value of any rules in the import file. Configuration data included with the rules, such as actions, is also overwritten. +.. (Optional) Select **Overwrite existing exception lists with conflicting "list_id"** to replace existing exception lists with exception lists from the import file if they have a matching `list_id` value. +.. (Optional) Select **Overwrite existing connectors with conflicting action "id"** to update existing connectors if they match the `action id` value of any rule actions in the import file. Configuration data included with the actions is also overwritten. +.. Click **Import rule**. +.. (Optional) If a connector is missing sensitive information after the import, a warning displays and you're prompted to fix the connector. In the warning, click **Go to connector**. On the Connectors page, find the connector that needs to be updated, click **Fix**, then add the necessary details. + +[discrete] +[[rule-prerequisites]] +== Confirm rule prerequisites + +Many detection rules are designed to work with specific {integrations-docs}[Elastic integrations] and data fields. These prerequisites are identified in **Related integrations** and **Required fields** on a rule's details page (**Rules** → **Detection rules (SIEM)**, then click a rule's name). **Related integrations** also displays each integration's installation status and includes links for installing and configuring the listed integrations. + +Additionally, the **Setup guide** section provides guidance on setting up the rule's requirements. + +[role="screenshot"] +image::images/prebuilt-rules-management/-detections-rule-details-prerequisites.png[Rule details page with Related integrations, Required fields, and Setup guide highlighted] + +You can also check rules' related integrations in the **Installed Rules** and **Rule Monitoring** tables. Click the **integrations** badge to display the related integrations in a popup. + +[role="screenshot"] +image::images/prebuilt-rules-management/-detections-rules-table-related-integrations.png[Rules table with related integrations popup] + +[TIP] +==== +You can hide the **integrations** badge in the rules tables by turning off the `securitySolution:showRelatedIntegrations` advanced setting. +==== diff --git a/docs/serverless/rules/rules-ui-management.mdx b/docs/serverless/rules/rules-ui-management.mdx index bad9f97d9c..490fe6abfe 100644 --- a/docs/serverless/rules/rules-ui-management.mdx +++ b/docs/serverless/rules/rules-ui-management.mdx @@ -34,7 +34,7 @@ To sort the rules list, click any column header. To sort in descending order, cl To filter the rules list, enter a search term in the search bar and press **Return**: * Rule name — Enter a word or phrase from a rule's name. -* Index pattern — Enter an index pattern (such as `filebeat-*`) to display all rules that use it. +* Index pattern — Enter an index pattern (such as `filebeat-*`) to display all rules that use it. * MITRE ATT&CK tactic or technique — Enter a MITRE ATT&CK tactic name (such as `Defense Evasion`) or technique number (such as `TA0005`) to display all associated rules. @@ -55,7 +55,7 @@ The **Last response** column displays the current status of each rule, based on * **Failed**: The rule encountered an error that prevented it from running. For example, a ((ml)) rule whose corresponding ((ml)) job wasn't running. * **Warning**: Nothing prevented the rule from running, but it might have returned unexpected results. For example, a custom query rule tried to search an index pattern that couldn't be found in ((es)). -For ((ml)) rules, an indicator icon () also appears in this column if a required ((ml)) job isn't running. Click the icon to list the affected jobs, then click **Visit rule details page to investigate** to open the rule's details page, where you can start the ((ml)) job. +For ((ml)) rules, an indicator icon () also appears in this column if a required ((ml)) job isn't running. Click the icon to list the affected jobs, then click **Visit rule details page to investigate** to open the rule's details page, where you can start the ((ml)) job.
@@ -77,7 +77,7 @@ Similarly, rules will be skipped if they can't be modified by a bulk edit. For e * **Bulk edit multiple rules**: Select the rules you want to edit, then select an action from the **Bulk actions** menu: * **Index patterns**: Add or delete the index patterns used by all selected rules. * **Tags**: Add or delete tags on all selected rules. - * **Custom highlighted fields**: Add custom highlighted fields on all selected rules. You can choose any fields that are available in the default ((elastic-sec)) indices, or enter field names from other indices. To overwrite a rule's current set of custom highlighted fields, select the **Overwrite all selected rules' custom highlighted fields** option, then click **Save**. + * **Custom highlighted fields**: Add custom highlighted fields on all selected rules. You can choose any fields that are available in the default ((elastic-sec)) indices, or enter field names from other indices. To overwrite a rule's current set of custom highlighted fields, select the **Overwrite all selected rules' custom highlighted fields** option, then click **Save**. * **Add rule actions**: Add rule actions on all selected rules. If you add multiple actions, you can specify an action frequency for each of them. To overwrite the frequency of existing actions select the option to **Overwrite all selected rules actions**. @@ -86,7 +86,7 @@ Similarly, rules will be skipped if they can't be modified by a bulk edit. For e * **Update rule schedules**: Update the schedules and look-back times on all selected rules. * **Apply Timeline template**: Apply a specified Timeline template to the selected rules. You can also choose **None** to remove Timeline templates from the selected rules. -1. On the page or flyout that opens, update the rule settings and actions. +1. On the page or flyout that opens, update the rule settings and actions. To snooze rule actions, go to the **Actions** tab and click the bell icon. @@ -102,7 +102,7 @@ Similarly, rules will be skipped if they can't be modified by a bulk edit. For e You can duplicate, enable, disable, delete, and snooze actions for rules: -When duplicating a rule with exceptions, you can choose to duplicate the rule and its exceptions (active and expired), the rule and active exceptions only, or only the rule. If you duplicate the rule and its exceptions, copies of the exceptions are created and added to the duplicated rule's default rule list. If the original rule used exceptions from a shared exception list, the duplicated rule will reference the same shared exception list. +When duplicating a rule with exceptions, you can choose to duplicate the rule and its exceptions (active and expired), the rule and active exceptions only, or only the rule. If you duplicate the rule and its exceptions, copies of the exceptions are created and added to the duplicated rule's default rule list. If the original rule used exceptions from a shared exception list, the duplicated rule will reference the same shared exception list. 1. Go to **Rules** → **Detection rules (SIEM)**. @@ -137,7 +137,7 @@ The manual run's details are shown in the Be mindful of the following: -* Rule actions are not activated during manual runs. +* Rule actions are not activated during manual runs. * Except for threshold rules, duplicate alerts aren't created if you manually run a rule during a time range that was already covered by a scheduled run. * Manual runs are executed with low priority and limited concurrency, meaning they might take longer to complete. This can be especially apparent for rules requiring multiple executions. @@ -146,7 +146,7 @@ Be mindful of the following: ## Snooze rule actions -Instead of turning rules off to stop alert notifications, you can snooze rule actions for a specified time period. When you snooze rule actions, the rule continues to run on its defined schedule, but won't perform any actions or send alert notifications. +Instead of turning rules off to stop alert notifications, you can snooze rule actions for a specified time period. When you snooze rule actions, the rule continues to run on its defined schedule, but won't perform any actions or send alert notifications. You can snooze notifications temporarily or indefinitely. When actions are snoozed, you can cancel or change the duration of the snoozed state. You can also schedule and manage recurring downtime for actions. @@ -158,7 +158,7 @@ You can snooze rule notifications from the **Installed Rules** tab, the rule det ## Export and import rules -You can export custom detection rules to an `.ndjson` file, which you can then import into another ((elastic-sec)) environment. +You can export custom detection rules to an `.ndjson` file, which you can then import into another ((elastic-sec)) environment. @@ -205,13 +205,13 @@ To export and import detection rules: 1. (Optional) Select **Overwrite existing exception lists with conflicting "list_id"** to replace existing exception lists with exception lists from the import file if they have a matching `list_id` value. 1. (Optional) Select **Overwrite existing connectors with conflicting action "id"** to update existing connectors if they match the `action id` value of any rule actions in the import file. Configuration data included with the actions is also overwritten. 1. Click **Import rule**. - 1. (Optional) If a connector is missing sensitive information after the import, a warning displays and you're prompted to fix the connector. In the warning, click **Go to connector**. On the Connectors page, find the connector that needs to be updated, click **Fix**, then add the necessary details. + 1. (Optional) If a connector is missing sensitive information after the import, a warning displays and you're prompted to fix the connector. In the warning, click **Go to connector**. On the Connectors page, find the connector that needs to be updated, click **Fix**, then add the necessary details.
## Confirm rule prerequisites -Many detection rules are designed to work with specific [Elastic integrations](((integrations-docs))) and data fields. These prerequisites are identified in **Related integrations** and **Required fields** on a rule's details page (**Rules** → **Detection rules (SIEM)**, then click a rule's name). **Related integrations** also displays each integration's installation status and includes links for installing and configuring the listed integrations. +Many detection rules are designed to work with specific [Elastic integrations](((integrations-docs))) and data fields. These prerequisites are identified in **Related integrations** and **Required fields** on a rule's details page (**Rules** → **Detection rules (SIEM)**, then click a rule's name). **Related integrations** also displays each integration's installation status and includes links for installing and configuring the listed integrations. Additionally, the **Setup guide** section provides guidance on setting up the rule's requirements. diff --git a/docs/serverless/rules/shared-exception-lists.asciidoc b/docs/serverless/rules/shared-exception-lists.asciidoc new file mode 100644 index 0000000000..651ddec562 --- /dev/null +++ b/docs/serverless/rules/shared-exception-lists.asciidoc @@ -0,0 +1,143 @@ +[[shared-exception-lists]] += Create and manage shared exception lists + +:description: Learn how to create and manage shared exception lists. +:keywords: serverless, security, how-to + +preview:[] + +Shared exception lists allow you to group exceptions together and then apply them to multiple rules. Use the Shared Exception Lists page to set up shared exception lists. + +[role="screenshot"] +image::images/shared-exception-lists/-detections-rule-exceptions-page.png[Shared Exception Lists page] + +[discrete] +[[create-shared-exception-list]] +== Create shared exception lists + +Set up shared exception lists to contain exception items: + +. Go to **Rules** → **Shared exception lists**. +. Click **Create shared exception list** → **Create shared list**. +. Give the shared exception list a name. +. (Optional) Provide a description. +. Click **Create shared exception list**. + +[discrete] +[[add-exception-items]] +== Add exception items to shared exception lists + +Add exception items: + +. Go to **Rules** → **Shared exception lists**. +. Click **Create shared exception list** → **Create exception item**. ++ +[TIP] +==== +You can add exceptions to an empty shared exception list by expanding the list, or viewing its details page and clicking **Create rule exception**. After creating an exception, you can associate the shared exception list with rules. Refer to <> to learn more. +==== +. In the **Add rule exception** flyout, name the exception item and add conditions that define when the exception prevents alerts. When the exception's query conditions are met (the query evaluates to `true`), rules do not generate alerts even when other rule criteria are met. ++ +.. **Field**: Select a field to identify the event being filtered. +.. **Operator**: Select an operator to define the condition: ++ +*** `is` | `is not` — Must be an exact match of the defined value. +*** `is one of` | `is not one of` — Matches any of the defined values. +*** `exists` | `does not exist` — The field exists. +*** `is in list` | `is not in list` — Matches values in a value list. ++ +[NOTE] +==== +* An exception defined by a value list must use `is in list` or `is not in list` in all conditions. +* Wildcards are not supported in value lists. +* If a value list can't be used due to <>, it'll be unavailable in the **Value** menu. +==== +*** `matches` | `does not match` — Allows you to use wildcards in **Value**, such as `C:\path*\app.exe`. Available wildcards are `?` (match one character) and `*` (match zero or more characters). The selected **Field** data type must be {ref}/keyword.html#keyword-field-type[keyword], {ref}/text.html#text-field-type[text], or {ref}/keyword.html#wildcard-field-type[wildcard]. ++ +[IMPORTANT] +==== +Using wildcards can impact performance. To create a more efficient exception using wildcards, use multiple conditions and make them as specific as possible. For example, adding conditions using `process.name` or `file.name` can help limit the scope of wildcard matching. +==== +.. **Value**: Enter the value associated with the **Field**. To enter multiple values (when using `is one of` or `is not one of`), enter each value, then press **Return**. +. Click **AND** or **OR** to create multiple conditions and define their relationships. +. Click **Add nested condition** to create conditions using nested fields. This is only required for +<>. For all other fields, nested conditions should not be used. +. Choose to add the exception to shared exception lists. ++ +[NOTE] +==== +This option will be unavailable if a shared exception list doesn't exist. In addition, you can't add an endpoint exception item to the Endpoint Security Exception List from this UI. Refer to <> for instructions about creating endpoint exceptions. +==== +. (Optional) Enter a comment describing the exception. +. (Optional) Enter a future expiration date and time for the exception. +. (Optional) **Close all alerts that match this exception and were generated by this rule**: +Closes all alerts that match the exception's conditions and were generated only by the current rule. +. Click **Add rule exception**. + +[discrete] +[[link-shared-exception-lists]] +== Associate shared exception lists with rules + +Apply shared exception lists to rules: + +. Go to **Rules** → **Shared exception lists**. +. Do one of the following: ++ +** Select a shared exception list's name to open its details page, then click **Link rules**. +** Find the shared exception list you want to assign to rules, then from the **More actions** menu (image:images/icons/boxesHorizontal.svg[Actions menu]), select **Link rules**. +. Click the toggles in the **Link** column to select the rules you want to link to the exception list. ++ +[TIP] +==== +If you know a rule's name, you can enter it into the search bar. +==== +. Click **Save**. +. (Optional) To verify that the shared exception list was added to the rules you selected: ++ +.. Open a rule’s details page (**Rules** → **Detection rules (SIEM)** → **_Rule name_**). +.. Scroll down the page, and then select the **Rule exceptions** tab. +.. Navigate to the exception items that are included in the shared exception list. Click the **Affects shared list** link to view the associated shared exception lists. ++ +[role="screenshot"] +image::images/shared-exception-lists/-detections-associated-shared-exception-list.png[Associated shared exceptions] + +[discrete] +[[view-shared-exception-lists]] +== View and filter exception lists + +The Shared Exception Lists page displays each shared exception list on an individual row, with the most recently created list at the top. Each row contains these details about the shared exception list: + +* Shared exception list name +* Date the list was created +* Username of the user who created the list +* Number of exception items in the shared exception list +* Number of rules the shared exception list affects + +To view the details of an exception item within a shared exception list, expand a row. + +[role="screenshot"] +image::images/shared-exception-lists/-detections-view-filter-shared-exception.png[Associated shared exceptions] + +To filter exception lists by a specific value, enter a value in the search bar. You can search the following attributes: + +* `name` +* `list_id` +* `created_by` + +If no attribute is selected, the app searches the list name by default. + +[discrete] +[[manage-exception-lists]] +== Manage shared exception lists + +You can edit, export, import, duplicate, and delete shared exception lists from the Shared Exception Lists page. + +To export or delete an exception list, select the required action button on the appropriate list. Note the following: + +* Exception lists are exported to `.ndjson` files. +* Exception lists are also exported as part of any exported detection rules configured with exceptions. Refer to <>. +* If an exception list is linked to any rules, you'll get a warning asking you to confirm the deletion. +* If an exception list contains expired exceptions, you can choose whether to include them in the exported file. + +[role="screenshot"] +image::images/shared-exception-lists/-detections-actions-exception-list.png[Detail of Exception lists table with export and delete buttons highlighted] diff --git a/docs/serverless/rules/tuning-detection-signals.asciidoc b/docs/serverless/rules/tuning-detection-signals.asciidoc new file mode 100644 index 0000000000..810124121c --- /dev/null +++ b/docs/serverless/rules/tuning-detection-signals.asciidoc @@ -0,0 +1,203 @@ +[[tune-detection-signals]] += Tune detection rules + +:description: Tune prebuilt and custom detection rules to optimize alert generation. +:keywords: serverless, security, how-to + +preview:[] + +Using the {security-app}, you can tune prebuilt and custom detection rules to optimize alert generation. To reduce noise, you can: + +* Add <> to detection rules. ++ +[TIP] +==== +Using exceptions is recommended as this ensure excluded source event values +persist even after prebuilt rules are updated. +==== +* Disable detection rules that rarely produce actionable alerts because they +match expected local behavior, workflows, or policy exceptions. +* <> detection rule queries so they are +aligned with local policy exceptions. This reduces noise while retaining +actionable alerts. +* Clone and modify detection rule risk scores, and use branching logic to map +higher risk scores to higher priority workflows. +* Enable <> for custom query rules to reduce the number of repeated or duplicate alerts. + +For details about tuning rules for specific categories: + +* <> +* <> +* <> +* <> + +[discrete] +[[filter-rule-process]] +== Filter out uncommon application alerts + +Organizations frequently use uncommon and in-house applications. Occasionally, +these can trigger unwanted alerts. To stop a rule matching on an application, +add an exception for the required application. + +// Links to prebuilt rule pages temporarily removed for initial serverless docs. + +// NOTE: Links to prebuilt rules will break if the rule is deprecated. Link to a different rule or remove the broken link. + +For example, to prevent the **Unusual Process Execution Path - Alternate Data Stream** rule from +producing alerts for an in-house application named `myautomatedbuild`: + +. Go to **Rules** → **Detection rules (SIEM)**. +. Search for and then click on the **Unusual Process Execution Path - Alternate Data Stream** rule. ++ +The **Unusual Process Execution Path - Alternate Data Stream** rule details page is displayed. +[role="screenshot"] +image::images/tuning-detection-signals/-detections-prebuilt-rules-rule-details-page.png[Rule details page] +. Select the **Rule exceptions** tab, then click **Add rule exception**. +. Fill in these options: ++ +** **Field**: `process.name` +** **Operator**: `is` +** **Value**: `myautomatedbuild` ++ +[role="screenshot"] +image::images/tuning-detection-signals/-detections-prebuilt-rules-process-exception.png[Add Rule Exception UI] +. Click **Add rule exception**. + +[discrete] +[[tune-authorized-processes]] +== Tune rules detecting authorized processes + +Authorized security testing, system tools, management frameworks, and +administrative activity may trigger detection rules. These legitimate +activities include: + +* Authorized security research. +* System and software management processes running scripts, including scripts +that start child processes. +* Administrative and management frameworks that create users, schedule tasks, +make `psexec` connections, and run WMI commands. +* Legitimate scripts using the `whoami` command. +* Applications that work with file shares, such as backup programs, and use the +server message block (SMB) protocol. + +To reduce noise for authorized activity, you can do any of these: + +* Add an exception to the rules that exclude specific servers, such as +the relevant host names, agent names, or other common identifiers. +For example, `host.name is `. +* Add an exception to the rules that <>. +For example, `process.name is `. +* Add an exception to the rules that exclude a common user. +For example, `user.name is `. + +Another useful technique is to assign lower risk scores to rules triggered by +authorized activity. This enables detections while keeping the resulting alerts +out of high-priority workflows. Use these steps: + +. Before adding exceptions, duplicate the prebuilt rule. +. Add an exception to the original prebuilt rule that excludes the relevant user +or process name (`user.name is ` or `process.name is "process-name"`). +. Edit the duplicated rule as follows: ++ +** Lower the `Risk score` (**Edit rule settings** → **About** tab). +** Add an exception so the rule only matches the user or process name excluded +in original prebuilt rules. +(`user.name is not ` or `process.name is not `). ++ +[role="screenshot"] +image::images/tuning-detection-signals/-detections-prebuilt-rules-process-specific-exception.png[Example of is not exception in the Add Rule Exception UI] +. Click **Add rule exception**. + +[discrete] +[[tune-windows-rules]] +== Tune Windows child process and PowerShell rules + +Normal user activity may sometimes trigger one or more of these rules: + +// Links to prebuilt rule pages temporarily removed for initial serverless docs. + +// NOTE: Links to prebuilt rules will break if the rule is deprecated. Link to a different rule or remove the broken link. + +* **Suspicious MS Office Child Process** +* **Suspicious MS Outlook Child Process** +* **System Shells via Services** +* **Unusual Parent-Child Relationship** +* **Windows Script Executing PowerShell** + +While all rules can be adjusted as needed, use care when adding exceptions to +these rules. Exceptions could result in an undetected client-side execution, or +a persistence or malware threat going unnoticed. + +Examples of when these rules may create noise include: + +* Receiving and opening email-attached Microsoft Office files, which +include active content such as macros or scripts, from a trusted third-party +source. +* Authorized technical support personnel who provide remote workers with +scripts to gather troubleshooting information. + +In these cases, exceptions can be added to the rules using the relevant +`process.name`, `user.name`, and `host.name` conditions. Additionally, +you can create duplicate rules with lower risk scores. + +[discrete] +[[tune-network-rules]] +== Tune network rules + +The definition of normal network behavior varies widely across different +organizations. Different networks conform to different security policies, +standards, and regulations. When normal network activity triggers alerts, +network rules can be disabled or modified. For example: + +* To exclude a specific source, add a `source.ip` exception with the +relevant IP address, and a `destination.port` exception with the relevant port +number (`source.ip is 196.1.0.12` and `destination.port is 445`). +* To exclude source network traffic for an entire subnet, add a `source.ip` +exception with the relevant CIDR notation (`source.ip is 192.168.0.0/16`). +* To exclude a destination IP for a specific destination port, add a +`destination.ip` exception with the IP address, and a `destination.port` +exception with the port number +(`destination.ip is 38.160.150.31` and `destination.port is 445`) +* To exclude a destination subnet for a specific destination port, add a +`destination.ip` exception using CIDR notation, and a ‘destination.port’ +exception with the port number +(`destination.ip is 172.16.0.0/12` and `destination.port is 445`). + +[discrete] +[[tune-indicator-rules]] +== Tune indicator match rules + +Take the following steps to tune indicator match rules: + +* Specify a detailed query as part of the indicator index query. Results of the indicator index query are used by the detection engine to query the indices specified in your rule definition's index pattern. Using no query or the wildcard `***` query may result in your rule executing very large queries. +* Limit your rule's additional look-back time to as short a duration as possible, and no more than 24 hours. +* Avoid cluster performance issues by scheduling your rule to run in one-hour intervals or longer. For example, avoid scheduling an indicator match rule to check for indicators every five minutes. + +[NOTE] +==== +{elastic-sec} provides limited support for indicator match rules. Visit <> for more information. +==== + +[discrete] +[[tune-detection-signals-noise-from-common-cloud-based-network-traffic]] +=== Noise from common cloud-based network traffic + +In cloud-based organizations, remote workers sometimes access services over the +internet. The security policies of home networks probably differ from the +security policies of managed corporate networks, and these rules might need +tuning to reduce noise from legitimate administrative activities: + +// Links to prebuilt rule pages temporarily removed for initial serverless docs. + +// NOTE: Links to prebuilt rules will break if the rule is deprecated. Link to a different rule or remove the broken link. + +* **RDP (Remote Desktop Protocol) from the Internet** + +[TIP] +==== +If your organization is widely distributed and the workforce travels a +lot, use the `windows_anomalous_user_name_ecs`, +`linux_anomalous_user_name_ecs`, and `suspicious_login_activity_ecs` +<> jobs to detect suspicious authentication activity. +==== diff --git a/docs/serverless/rules/value-lists-exceptions.asciidoc b/docs/serverless/rules/value-lists-exceptions.asciidoc new file mode 100644 index 0000000000..c5a4d15692 --- /dev/null +++ b/docs/serverless/rules/value-lists-exceptions.asciidoc @@ -0,0 +1,105 @@ +[[value-lists-exceptions]] += Create and manage value lists + +:description: Make and manage value lists. +:keywords: serverless, security, how-to + +preview:[] + +Value lists hold multiple values of the same Elasticsearch data type, such as IP addresses, which are used to determine when an exception prevents an alert from being generated. You can use value lists to define exceptions for detection rules; however, you cannot use value lists to define endpoint rule exceptions. + +Value lists are lists of items with the same {es} {ref}/mapping-types.html[data type]. You can create value lists with these types: + +* `Keywords` (many {ecs-ref}/ecs-field-reference.html[ECS fields] are keywords) +* `IP Addresses` +* `IP Ranges` +* `Text` + +After creating value lists, you can use `is in list` and `is not in list` operators to <>. + +[TIP] +==== +You can also use a value list as the <> when creating an indicator match rule. +==== + +[discrete] +[[create-value-lists]] +== Create value lists + +When you create a value list for a rule exception, be mindful of the list's size and data type. All rule types support value list exceptions, but extremely large lists or certain data types have limitations. + +Custom query, machine learning, and indicator match rules support the following value list types and sizes: + +* **Keywords** or **IP addresses** list types with more than 65,536 values +* **IP ranges** list type with over 200 dash notation values (for example, `127.0.0.1-127.0.0.4` is one value) or more than 65,536 CIDR notation values + +To create a value list: + +. Prepare a `txt` or `csv` file with all the values you want to use for +determining exceptions from a single list. If you use a `txt` file, new lines +act as delimiters. ++ +[IMPORTANT] +==== +* All values in the file must be of the same {es} type. +* Wildcards are not supported in value lists. Values must be literal values. +* The maximum accepted file size is 9 million bytes. +==== +. Go to **Rules** → **Detection rules (SIEM)**. +. Click **Manage value lists**. The **Manage value lists** window opens. ++ +[role="screenshot"] +image:images/value-lists-exceptions/-detections-upload-lists-ui.png[Manage value lists flyout] +. Select the list type (**Keywords**, **IP addresses**, **IP ranges**, or **Text**) from the **Type of value list** drop-down. +. Drag or select the `csv` or `txt` file that contains the values. +. Click **Import value list**. + +[NOTE] +==== +If you import a file with a name that already exists, a new list is not created. The imported values are added to the existing list instead. +==== + +[discrete] +[[manage-value-lists]] +== Manage value lists + +You can edit, remove, or export existing value lists. + +[discrete] +[[edit-value-lists]] +=== Edit value lists + +. Go to **Rules** → **Detection rules (SIEM)**. +. Click **Manage value lists**. The **Manage value lists** window opens. +. In the **Value lists** table, click the value list you want to edit. +. Do any of the following: ++ +** **Filter items in the list**: Use the KQL search bar to find values in the list. Depending on your list's type, you can filter by the `keyword`, `ip_range`, `ip`, or `text` fields. For example, to filter by Gmail addresses in a value list of the `keyword` type, enter `keyword:*gmail.com` into the search bar. ++ +You can also filter by the `updated_by` field (for example, `updated_by:testuser`), or the `updated at` field (for example, `updated_at < now`). +** **Add individual items to the list**: Click **Create list item**, enter a value, then click **Add list item**. +** **Bulk upload list items**: Drag or select the `csv` or `txt` file that contains the values that you want to add, then click **Upload**. +** **Edit a value**: In the Value column, go to the value you want to edit and click the **Edit** button (image:images/icons/pencil.svg[Edit]). When you're done editing, click the **Save** button (image:images/icons/check.svg[Save]) to save your changes. Click the **Cancel** button (image:images/icons/cross.svg[Edit]) to revert your changes. +** **Remove a value**: Click the **Remove value** button (image:images/icons/trash.svg[Remove value list]) to delete a value from the list. ++ +[role="screenshot"] +image:images/value-lists-exceptions/-detections-edit-value-lists.png[Manage items in a value list] + +[TIP] +==== +You can also edit value lists while creating and managing exceptions that use value lists. +==== + +[discrete] +[[export-remove-value-lists]] +=== Export or remove value lists + +. Go to **Rules** → **Detection rules (SIEM)**. +. Click **Manage value lists**. The **Manage value lists** window opens. +. From the **Value lists** table, you can: ++ +** Click the **Export value list** button (image:images/icons/exportAction.svg[Export value list]) to export the value list. +** Click the **Remove value list** button (image:images/icons/trash.svg[Remove value list]) to delete the value list. + +[role="screenshot"] +image::images/value-lists-exceptions/-detections-manage-value-list.png[Import value list flyout with action buttons highlighted] diff --git a/docs/serverless/sec-requirements.asciidoc b/docs/serverless/sec-requirements.asciidoc new file mode 100644 index 0000000000..0e486f1878 --- /dev/null +++ b/docs/serverless/sec-requirements.asciidoc @@ -0,0 +1,63 @@ +[[requirements-overview]] += {elastic-sec} requirements + +:description: Requirements for using and configuring {elastic-sec}. +:keywords: serverless, security, how-to, manage + +preview:[] + +The https://www.elastic.co/support/matrix[Support Matrix] page lists officially +supported operating systems, platforms, and browsers on which components such as {beats}, {agent}, {elastic-defend}, and {elastic-endpoint} have been tested. + +[discrete] +[[requirements-overview-space-and-index-privileges]] +== Space and index privileges + +Provide access to {elastic-sec} by assigning a user the appropriate https://www.elastic.co/docs/current/serverless/general/assign-user-roles[predefined user role] or a https://www.elastic.co/docs/current/serverless/custom-roles[custom role] with specific privileges. + +To use {elastic-sec}, your role must have at least: + +* `Read` privilege for the `Security` feature in the {kibana-ref}/xpack-spaces.html[space]. This grants you `Read` access to all features in {elastic-sec} except cases. You need additional <> to use cases. +* `Read` and `view_index_metadata` privileges for all {elastic-sec} indices, such as +`filebeat-*`, `packetbeat-*`, `logs-*`, and `endgame-*` indices. + +[NOTE] +==== +<> describes how to modify {elastic-sec} indices. +==== + +For more information about index privileges, refer to {ref}/security-privileges.html[{es} security privileges]. + +[discrete] +[[requirements-overview-feature-specific-requirements]] +== Feature-specific requirements + +There are some additional requirements for specific features: + +* <> +* <> +* <> +* <> +* <> +* <> + +[discrete] +[[requirements-overview-advanced-configuration-and-ui-options]] +== Advanced configuration and UI options + +<> describes how to modify advanced settings, such as the +{elastic-sec} indices, default time intervals used in filters, and IP reputation +links. + +[discrete] +[[requirements-overview-third-party-collectors-mapped-to-ecs]] +== Third-party collectors mapped to ECS + +The {ecs-ref}[Elastic Common Schema (ECS)] defines a common set of fields to be used for storing event data in Elasticsearch. ECS helps users normalize their event data +to better analyze, visualize, and correlate the data represented in their +events. {elastic-sec} can ingest and normalize events from any ECS-compliant data source. + +[IMPORTANT] +==== +{elastic-sec} requires {ecs-ref}[ECS-compliant data]. If you use third-party data collectors to ship data to {es}, the data must be mapped to ECS. <> lists ECS fields used in {elastic-sec}. +==== diff --git a/docs/serverless/security-overview.asciidoc b/docs/serverless/security-overview.asciidoc new file mode 100644 index 0000000000..ca1d58a2a2 --- /dev/null +++ b/docs/serverless/security-overview.asciidoc @@ -0,0 +1,45 @@ +[[overview]] += {elastic-sec} overview + +:keywords: serverless, security, reference + +preview:[] + +{elastic-sec} combines threat detection analytics, cloud native security, and endpoint protection capabilities in a single solution, so you can quickly detect, investigate, and respond to threats and vulnerabilities across your environment. + +{elastic-sec} provides: + +* A detection engine that identifies a wide range of threats +* A workspace for event triage, investigation, and case management +* Interactive data visualization tools +* Integrations for collecting data from various sources + +[discrete] +[[siem-integration]] +== Learn more + +* <>: Navigate {elastic-sec}'s various tools and interfaces. +* <>: Use {elastic-sec}'s detection engine with custom and prebuilt rules. +* <>: Enable cloud native security capabilities such as Cloud and Kubernetes security posture management, cloud native vulnerability management, and cloud workload protection for Kubernetes and VMs. +* <>: Enable key endpoint protection capabilities like event collection and malicious activity prevention. +* https://www.elastic.co/products/stack/machine-learning[{ml-cap}]: Enable built-in {ml} tools to help you identify malicious behavior. +* <>: Leverage {elastic-sec}'s detection engine and {ml} capabilities to generate comprehensive risk analytics for hosts and users. +* <>: Ask AI Assistant questions about how to use {elastic-sec}, how to understand particular alerts and other documents, and how to write {esql} queries. + +[discrete] +[[elastic-search-and-kibana]] +== {es} and {kib} + +{elastic-sec} uses {es} for data storage, management, and search, and {kib} is its main user interface. Learn more: + +* https://www.elastic.co/products/elasticsearch[{es}]: A real-time, +distributed storage, search, and analytics engine. {elastic-sec} stores your data using {es}. +* https://www.elastic.co/products/kibana[{kib}]: An open-source analytics and +visualization platform designed to work with {es} and {elastic-sec}. {kib} allows you to search, +view, analyze and visualize data stored in {es} indices. + +[discrete] +[[self-protection]] +=== {elastic-endpoint} self-protection + +For information about {elastic-endpoint}'s tamper-protection features, refer to <>. diff --git a/docs/serverless/security-ui.asciidoc b/docs/serverless/security-ui.asciidoc new file mode 100644 index 0000000000..b04a7941ad --- /dev/null +++ b/docs/serverless/security-ui.asciidoc @@ -0,0 +1,290 @@ +[[security-ui]] += Elastic Security UI + +:keywords: serverless, security, reference + +preview:[] + +The {security-app} is a highly interactive workspace designed for security analysts that provides a clear overview of events and alerts from your environment. You can use the interactive UI to drill down into areas of interest. + +[discrete] +[[search-overview]] +== Search + +Filter for alerts, events, processes, and other important security data by entering {kibana-ref}/kuery-query.html[{kib} Query Language (KQL)] queries in the search bar, which appears at the top of each page throughout the app. A date/time filter set to `Today` is enabled by default, but can be changed to any time range. + +[role="screenshot"] +image::images/es-ui-overview/-getting-started-search-bar.png[] + +* To refine your search results, select **Add Filter** (image:images/icons/plusInCircleFilled.svg[Add]), then enter the field, operator (such as `is not` or `is between`), and value for your filter. +* To save the current KQL query and any applied filters, select **Saved query menu** (image:images/icons/filterInCircle.svg[Filter]), enter a name for the saved query, and select **Save saved query**. + +[discrete] +[[navigation-menu-overview]] +== Navigation menu + +The navigation menu contains direct links and expandable groups, identified by the group icon (image:images/icons/spaces.svg[Group]). + +* Click a top-level link to go directly to its landing page, which contains links and information for related pages. +* Click a group's icon (image:images/icons/spaces.svg[Group]) to open its flyout menu, which displays links to related pages within that group. Click a link in the flyout to navigate to its landing page. +* Click the **Collapse side navigation** icon (image:images/icons/menuLeft.svg[Move menu left]) to collapse and expand the main navigation menu. + +// Hiding this as short-term fix for serverless; consider creating a serverless version of the image? + +// ![Overview of the navigation menu](images/es-ui-overview/-getting-started-nav-overview.gif) + +[discrete] +[[visualization-actions]] +== Visualization actions + +Many {elastic-sec} histograms, graphs, and tables display an **Inspect** button (image:images/icons/inspect.svg[Inspect]) when you hover over them. Click to examine the {es} queries used to retrieve data throughout the app. + +[role="screenshot"] +image::images/es-ui-overview/-getting-started-inspect-icon-context.png[Inspect icon] + +Other visualizations display an options menu (image:images/icons/boxesHorizontal.svg[More actions]), which allows you to inspect the visualization's queries, add it to a new or existing case, or open it in Lens for customization. + +[role="screenshot"] +image::images/es-ui-overview/-getting-started-viz-options-menu-open.png[Options menu opened] + +[discrete] +[[inline-actions]] +== Inline actions for fields and values + +Throughout the {security-app}, you can hover over many data fields and values to display inline actions, which allow you to customize your view or investigate further based on that field or value. + +[role="screenshot"] +image::images/es-ui-overview/-detections-inline-actions-menu.png[Inline additional actions menu] + +In some visualizations, these actions are available in the legend by clicking a value's options icon (image:images/icons/boxesVertical.svg[More actions]). + +[role="screenshot"] +image::images/es-ui-overview/-getting-started-inline-actions-legend.png[Actions in a visualization legend] + +Inline actions include the following (some actions are unavailable in some contexts): + +* **Filter In**: Add a filter that includes the selected value. +* **Filter Out**: Add a filter that excludes the selected value. +* **Add to timeline**: Add a filter to Timeline for the selected value. +* **Toggle column in table**: Add or remove the selected field as a column in the alerts or events table. (This action is only available on an alert's or event's details flyout.) +* **Show top _x_**: Display a pop-up window that shows the selected field's top events or detection alerts. +* **Copy to Clipboard**: Copy the selected field-value pair to paste elsewhere. + +[discrete] +[[security-ui-security-app-pages]] +== {security-app} pages + +The {security-app} contains the following pages that enable analysts to view, analyze, and manage security data. + +[discrete] +[[security-ui-discover]] +=== Discover + +Use the https://www.elastic.co/docs/current/serverless/elasticsearch/explore-your-data-discover-your-data[Discover UI] to filter your data or learn about its structure. + +[discrete] +[[security-ui-dashboards]] +=== Dashboards + +Expand this section to access the Overview, Detection & Response, Kubernetes, Cloud Security Posture, Cloud Native Vulnerability Management, and Entity Analytics dashboards, which provide interactive visualizations that summarize your data. You can also create and view custom dashboards. Refer to <> for more information. + +[role="screenshot"] +image::images/es-ui-overview/-dashboards-dashboards-landing-page.png[The dashboards landing page, 75%] + +[discrete] +[[security-ui-rules]] +=== Rules + +Expand this section to access the following pages: + +* <>: Create and manage rules to monitor suspicious events. ++ +[role="screenshot"] +image::images/es-ui-overview/-detections-all-rules.png[Rules page] +* <>: View, enable, or disable benchmark rules. ++ +[role="screenshot"] +image::images/es-ui-overview/-cloud-native-security-benchmark-rules.png[Benchmark Rules page] +* <>: View and manage rule exceptions and shared exception lists. ++ +[role="screenshot"] +image::images/es-ui-overview/-detections-rule-exceptions-page.png[Shared Exception Lists page] +* <>: Review your coverage of MITRE ATT&CK® tactics and techniques, based on installed rules. ++ +[role="screenshot"] +image::images/es-ui-overview/-detections-rules-coverage.png[MITRE ATT&CK® coverage page] + +[discrete] +[[security-ui-alerts]] +=== Alerts + +View and manage alerts to monitor activity within your network. Refer to <> for more information. + +[role="screenshot"] +image::images/es-ui-overview/-detections-alert-page.png[] + +[discrete] +[[security-ui-findings]] +=== Findings + +Identify misconfigurations and vulnerabilities in your cloud infrastructure. For setup instructions, refer to <>, <>, or <>. + +[role="screenshot"] +image::images/findings-page/-cloud-native-security-findings-page.png[Findings page] + +[discrete] +[[security-ui-cases]] +=== Cases + +Open and track security issues. Refer to <> to learn more. + +[role="screenshot"] +image::images/es-ui-overview/-cases-cases-home-page.png[Cases page] + +[discrete] +[[security-ui-investigations]] +=== Investigations + +Expand this section to access the following pages: + +* <>: Investigate alerts and complex threats — such as lateral movement — in your network. Timelines are interactive and allow you to share your findings with other team members. ++ +[role="screenshot"] +image::images/es-ui-overview/-events-timeline-ui.png[Timeline page] ++ +[TIP] +==== +Click the **Timeline** button at the bottom of the {security-app} to start an investigation. +==== +* <>: Deploy Osquery with {agent}, then run and schedule queries. + +[discrete] +[[security-ui-intelligence]] +=== Intelligence + +The Intelligence section contains the Indicators page, which collects data from enabled threat intelligence feeds and provides a centralized view of indicators of compromise (IoCs). Refer to <> to learn more. + +[role="screenshot"] +image::images/es-ui-overview/-cases-indicators-table.png[Indicators page] + +[discrete] +[[security-ui-explore]] +=== Explore + +Expand this section to access the following pages: + +* <>: Examine key metrics for host-related security events using graphs, charts, and interactive data tables. ++ +[role="screenshot"] +image::images/es-ui-overview/-management-hosts-hosts-ov-pg.png[Hosts page] +* <>: Explore the interactive map to discover key network activity metrics and investigate network events further in Timeline. ++ +[role="screenshot"] +image::images/es-ui-overview/-getting-started-network-ui.png[Network page] +* <>: Access a comprehensive overview of user data to help you understand authentication and user behavior within your environment. ++ +[role="screenshot"] +image::images/es-ui-overview/-getting-started-users-users-page.png[Users page] + +[discrete] +[[security-ui-assets]] +=== Assets + +The Assets section allows you to manage the following features: + +* {fleet-guide}/manage-agents-in-fleet.html[{fleet}] +* {fleet-guide}/integrations.html[{integrations}] +* <> ++ +** <>: View and manage hosts running {elastic-defend}. +** <>: View and manage {elastic-defend} integration policies. +** <>: View and manage trusted Windows, macOS, and Linux applications. +** <>: View and manage event filters, which allow you to filter endpoint events you don't need to want stored in {es}. +** <>: View and manage host isolation exceptions, which specify IP addresses that can communicate with your hosts even when those hosts are blocked from your network. +** <>: View and manage the blocklist, which allows you to prevent specified applications from running on hosts, extending the list of processes that {elastic-defend} considers malicious. +** <>: Find the history of response actions performed on hosts. +* <> ++ +** <>: Identify and block unexpected system behavior in Kubernetes containers. + +[discrete] +[[security-ui-ml-cap]] +=== {ml-cap} + +Manage {ml} jobs and settings. Refer to {ml-docs}/ml-ad-overview.html[{ml-cap} docs] for more information. + +[discrete] +[[security-ui-get-started]] +=== Get started + +Quickly add security integrations that can ingest data and monitor your hosts. + +[discrete] +[[security-ui-project-settings]] +=== Project settings + +Configure project-wide settings related to users, billing, data management, and more. + +[discrete] +[[security-ui-dev-tools]] +=== Dev tools + +Use additional API and analysis tools to interact with your data. + +[discrete] +[[timeline-accessibility-features]] +== Accessibility features + +Accessibility features, such as keyboard focus and screen reader support, are built into the Elastic Security UI. These features offer additional ways to navigate the UI and interact with the application. + +[discrete] +[[draggable-timeline-elements]] +=== Interact with draggable elements + +Use your keyboard to interact with draggable elements in the Elastic Security UI: + +* Press the `Tab` key to apply keyboard focus to an element within a table. Or, use your mouse to click on an element and apply keyboard focus to it. + +[role="screenshot"] +image::images/es-ui-overview/-getting-started-timeline-accessiblity-keyboard-focus.gif[Demo that shows how to give a draggable element keyboard focus] + +* Press `Enter` on an element with keyboard focus to display its menu and press `Tab` to apply focus sequentially to menu options. The `f`, `o`, `a`, `t`, `c` hotkeys are automatically enabled during this process and offer an alternative way to interact with menu options. + +[role="screenshot"] +image::images/es-ui-overview/-getting-started-timeline-accessiblity-keyboard-focus-hotkeys.gif[Demo that shows how to display an element menu] + +* Press the spacebar once to begin dragging an element to a different location and press it a second time to drop it. Use the directional arrows to move the element around the UI. + +[role="screenshot"] +image::images/es-ui-overview/-getting-started-timeline-ui-accessiblity-drag-n-drop.gif[Demo that shows how to drag and drop an element to another location in the Elastic Security UI] + +* If an event has an event renderer, press the `Shift` key and the down directional arrow to apply keyboard focus to the event renderer and `Tab` or `Shift` + `Tab` to navigate between fields. To return to the cells in the current row, press the up directional arrow. To move to the next row, press the down directional arrow. + +[role="screenshot"] +image::images/es-ui-overview/-getting-started-timeline-accessiblity-event-renderers.gif[Demo that shows how to navigate an event renderer] + +[discrete] +[[timeline-tab]] +=== Navigate the Elastic Security UI + +Use your keyboard to navigate through rows, columns, and menu options in the Elastic Security UI: + +* Use the directional arrows to move keyboard focus right, left, up, and down in a table. + +[role="screenshot"] +image::images/es-ui-overview/-getting-started-timeline-accessiblity-directional-arrows.gif[] + +* Press the `Tab` key to navigate through a table cell with multiple elements, such as buttons, field names, and menus. Pressing the `Tab` key will sequentially apply keyboard focus to each element in the table cell. + +[role="screenshot"] +image::images/es-ui-overview/-getting-started-timeline-accessiblity-tab-keys.gif[Demo that shows how to use Tab to navigate through a cell with multiple elements] + +* Use `CTRL + Home` to shift keyboard focus to the first cell in a row. Likewise, use `CTRL + End` to move keyboard focus to the last cell in the row. + +[role="screenshot"] +image::images/es-ui-overview/-getting-started-timeline-accessiblity-shifting-keyboard-focus.gif[Demo that shows how to Demo that shows how to shift keyboard focus] + +* Use the `Page Up` and `Page Down` keys to scroll through the page. + +[role="screenshot"] +image::images/es-ui-overview/-getting-started-timeline-accessiblity-page-up-n-down.gif[Demo that shows how to to scroll through the page] diff --git a/docs/serverless/settings/advanced-settings.asciidoc b/docs/serverless/settings/advanced-settings.asciidoc new file mode 100644 index 0000000000..eb43624c38 --- /dev/null +++ b/docs/serverless/settings/advanced-settings.asciidoc @@ -0,0 +1,214 @@ +[[advanced-settings]] += Advanced settings + +:description: Update advanced {elastic-sec} settings. +:keywords: serverless, security, reference, manage + +preview:[] + +The advanced settings determine: + +* Which indices {elastic-sec} uses to retrieve data +* {ml-cap} anomaly score display threshold +* The navigation menu style used throughout the {security-app} +* Whether the news feed is displayed on the <> +* The default time interval used to filter {elastic-sec} pages +* The default {elastic-sec} pages refresh time +* Which IP reputation links appear on <> pages +* Whether cross-cluster search (CCS) privilege warnings are displayed +* Whether related integrations are displayed on the Rules page tables +* The options provided in the alert tag menu + +To change these settings, you need either the appropriate https://www.elastic.co/docs/current/serverless/general/assign-user-roles[predefined Security user role] or a https://www.elastic.co/docs/current/serverless/custom-roles[custom role] with `All` privileges for the **Advanced Settings** feature. + +[WARNING] +==== +Modifying advanced settings can affect performance and cause +problems that are difficult to diagnose. Setting a property value to a blank +field reverts to the default behavior, which might not be compatible with other +configuration settings. Deleting a custom setting removes it +permanently. +==== + +[discrete] +[[advanced-settings-access-advanced-settings]] +== Access advanced settings + +To access advanced settings, go to **Project Settings** → **Management** → **Advanced Settings**, then scroll down to **Security Solution** settings. + +[TIP] +==== +For more information on non-Security settings, refer to {kibana-ref}/advanced-options.html[Advanced Settings]. Some settings might not be available in {serverless-short} projects. +==== + +[role="screenshot"] +image::images/advanced-settings/-getting-started-solution-advanced-settings.png[] + +[discrete] +[[update-sec-indices]] +== Update default Elastic Security indices + +The `securitySolution:defaultIndex` field defines which {es} indices the +{security-app} uses to collect data. By default, index patterns are used to +match sets of {es} indices: + +* `apm-*-transaction*` +* `auditbeat-*` +* `endgame-*` +* `filebeat-*` +* `logs-*` +* `packetbeat-*` +* `winlogbeat-*` + +[NOTE] +==== +Index patterns use wildcards to specify a set of indices. For example, the +`filebeat-*` index pattern means all indices starting with `filebeat-` are +available in the {security-app}. +==== + +All of the default index patterns match {beats-ref}/beats-reference.html[{beats}] and +{fleet-guide}/fleet-overview.html[{agent}] indices. This means all +data shipped via {beats} and the {agent} is automatically added to the +{security-app}. + +You can add or remove any indices and index patterns as required, with a maximum of 50 items in the comma-delimited list. For background information on {es} indices, refer to {ref}/documents-indices.html[Data in: documents and indices]. + +[NOTE] +==== +If you leave the `-*elastic-cloud-logs-*` index pattern selected, all Elastic cloud logs are excluded from all queries in the {security-app} by default. This is to avoid adding data from cloud monitoring to the app. +==== + +[IMPORTANT] +==== +{elastic-sec} requires {ecs-ref}[ECS-compliant data]. If you use third-party data +collectors to ship data to {es}, the data must be mapped to ECS. +<> lists ECS fields used in {elastic-sec}. +==== + +[discrete] +[[update-threat-intel-indices]] +== Update default Elastic Security threat intelligence indices + +The `securitySolution:defaultThreatIndex` advanced setting specifies threat intelligence indices that {elastic-sec} features query for ingested threat indicators. This setting affects features that query threat intelligence indices, such as the Threat Intelligence view on the Overview page, indicator match rules, and the alert enrichment query. + +You can specify a maximum of 10 threat intelligence indices; multiple indices must be separated by commas. By default, only the `logs-ti*` index pattern is specified. Do not remove or overwrite this index pattern, as it is used by {agent} integrations. + +[IMPORTANT] +==== +Threat intelligence indices aren't required to be ECS-compatible for use in indicator match rules. However, we strongly recommend compatibility if you want your alerts to be enriched with relevant threat indicator information. When searching for threat indicator data, indicator match rules use the threat indicator path specified in the **Indicator prefix override** advanced setting. Visit <> for more information. +==== + +[discrete] +[[telemetry-settings]] +== Telemetry settings + +Elastic transmits certain information about Elastic Security when users interact with the {security-app}, detailed below. Elastic redacts or obfuscates personal data (IP addresses, host names, usernames, etc.) before transmitting messages. Security-specific telemetry events include: + +* **Detection rule security alerts:** Information about Elastic-authored prebuilt detection rules using the detection engine. Examples of alert data include machine learning job influencers, process names, and cloud audit events. +* **{elastic-endpoint} Security alerts:** Information about malicious activity detected using {elastic-endpoint} detection engines. Examples of alert data include malicious process names, digital signatures, and file names written by the malicious software. Examples of alert metadata include the time of the alert, the {elastic-endpoint} version and related detection engine versions. +* **Configuration data for {elastic-endpoint}:** Information about the configuration of {elastic-endpoint} deployments. Examples of configuration data include the Endpoint versions, operating system versions, and performance counters for Endpoint. +* **Exception list entries for Elastic rules:** Information about exceptions added for Elastic rules. Examples include trusted applications, detection exceptions, and rule exceptions. +* **Security alert activity records:** Information about actions taken on alerts generated in the {security-app}, such as acknowledged or closed. + +To learn more, refer to our https://www.elastic.co/legal/privacy-statement[Privacy Statement]. + +[discrete] +[[advanced-settings-set-machine-learning-score-threshold]] +== Set machine learning score threshold + +When security <> are enabled, this setting +determines the threshold above which anomaly scores appear in {elastic-sec}: + +* `securitySolution:defaultAnomalyScore` + +[discrete] +[[advanced-settings-modify-news-feed-settings]] +== Modify news feed settings + +You can change these settings, which affect the news feed displayed on the +{elastic-sec} **Overview** page: + +* `securitySolution:enableNewsFeed`: Enables the security news feed on the +Security **Overview** page. +* `securitySolution:newsFeedUrl`: The URL from which the security news feed content is +retrieved. + +[discrete] +[[advanced-settings-enable-asset-criticality-workflows]] +== Enable asset criticality workflows + +The `securitySolution:enableAssetCriticality` setting determines whether asset criticality is included as a risk input to entity risk scoring. This setting is turned off by default. Turn it on to enable asset criticality workflows and to use asset criticality as part of entity risk scoring. + +[discrete] +[[advanced-settings-exclude-cold-and-frozen-tier-data-from-analyzer-queries]] +== Exclude cold and frozen tier data from analyzer queries + +Including data from cold and frozen {ref}/data-tiers.html[data tiers] in <> queries may result in performance degradation. The `securitySolution:excludeColdAndFrozenTiersInAnalyzer` setting allows you to exclude this data from analyzer queries. This setting is turned off by default. + +[discrete] +[[advanced-settings-change-the-default-search-interval-and-data-refresh-time]] +== Change the default search interval and data refresh time + +These settings determine the default time interval and refresh rate {elastic-sec} +pages use to display data when you open the app: + +* `securitySolution:timeDefaults`: Default time interval +* `securitySolution:refreshIntervalDefaults`: Default refresh rate + +[NOTE] +==== +Refer to {ref}/common-options.html[Date Math] for information about the +syntax. The UI {kibana-ref}/set-time-filter.html[time filter] overrides the +default values. +==== + +[discrete] +[[ip-reputation-links]] +== Display reputation links on IP detail pages + +On IP details pages (**Network** → **_IP address_**), links to +external sites for verifying the IP address's reputation are displayed. By +default, links to these sites are listed: https://talosintelligence.com/[TALOS] +and https://www.virustotal.com/[VIRUSTOTAL]. + +The `securitySolution:ipReputationLinks` field determines which IP reputation +sites are listed. To modify the listed sites, edit the field's JSON array. These +fields must be defined in each array element: + +* `name`: The link's UI display name. +* `url_template`: The link's URL. It can include `{{ip}}`, which is placeholder +for the IP address you are viewing on the **IP detail** page. + +**Example** + +Adds a link to https://www.dnschecker.org[https://www.dnschecker.org] on **IP detail** pages: + +[source,json] +---- +[ + { "name": "virustotal.com", "url_template": "https://www.virustotal.com/gui/search/{{ip}}" }, + { "name": "dnschecker.org", "url_template": "https://www.dnschecker.org/ip-location.php?ip={{ip}}" }, + { "name": "talosIntelligence.com", "url_template": "https://talosintelligence.com/reputation_center/lookup?search={{ip}}" } +] +---- + +[discrete] +[[enable-ccs-warning]] +== Configure cross-cluster search privilege warnings + +Each time a detection rule runs using a remote cross-cluster search (CCS) index pattern, it will return a warning saying that the rule may not have the required `read` privileges to the remote index. Because privileges cannot be checked across remote indices, this warning displays even when the rule actually does have `read` privileges to the remote index. + +If you've ensured that your detection rules have the required privileges across your remote indices, you can use the `securitySolution:enableCcsWarning` setting to disable this warning and reduce noise. + +[discrete] +[[show-related-integrations]] +== Show/hide related integrations in Rules page tables + +By default, Elastic prebuilt rules in the **Rules** and **Rule Monitoring** tables include a badge showing how many related integrations have been installed. Turn off `securitySolution:showRelatedIntegrations` to hide this in the rules tables (related integrations will still appear on rule details pages). + +[discrete] +[[manage-alert-tags]] +== Manage alert tag options + +The `securitySolution:alertTags` field determines which options display in the alert tag menu. The default alert tag options are `Duplicate`, `False Positive`, and `Further investigation required`. You can update the alert tag menu by editing these options or adding more. To learn more about using alert tags, refer to <>. diff --git a/docs/serverless/settings/manage-settings.asciidoc b/docs/serverless/settings/manage-settings.asciidoc new file mode 100644 index 0000000000..e9fee37b69 --- /dev/null +++ b/docs/serverless/settings/manage-settings.asciidoc @@ -0,0 +1,12 @@ +[[manage-settings]] += Manage settings + +:keywords: serverless, security, overview + +preview:[] + +These pages explain how to manage settings in various areas of the {security-app}: + +* <>: Configure project-wide settings related to users, billing, data management, and more. +* <>: Update advanced {elastic-sec} settings. +* <>: Learn about requirements for specific features. diff --git a/docs/serverless/settings/project-settings.asciidoc b/docs/serverless/settings/project-settings.asciidoc new file mode 100644 index 0000000000..367998476f --- /dev/null +++ b/docs/serverless/settings/project-settings.asciidoc @@ -0,0 +1,9 @@ +[[project-settings]] += Project settings + +:description: Configure project-wide settings related to users, billing, data management, and more. +:keywords: serverless, security, overview, manage + +preview:[] + +Navigate to **Project settings** to configure project-wide settings related to users, billing, data management, and more. diff --git a/docs/serverless/technical-preview-limitations.asciidoc b/docs/serverless/technical-preview-limitations.asciidoc new file mode 100644 index 0000000000..9652ab966c --- /dev/null +++ b/docs/serverless/technical-preview-limitations.asciidoc @@ -0,0 +1,14 @@ +[[security-technical-preview-limitations]] += Technical preview limitations + +:description: Review the limitations that apply to Elastic Security projects in technical preview. +:keywords: serverless, security + +preview:[] + +Currently, workloads outside of the following ranges may experience higher latencies: + +* Data ingest rate, total of all data sources, greater than 500GB per day +* Number of {ml} jobs greater than 50 +* Searchable data size greater than 10TB +* Number of endpoints and Cloud assets for {fleet} and {agent} management greater than 40,000 diff --git a/docs/serverless/troubleshooting/troubleshoot-endpoints.asciidoc b/docs/serverless/troubleshooting/troubleshoot-endpoints.asciidoc new file mode 100644 index 0000000000..41203803cd --- /dev/null +++ b/docs/serverless/troubleshooting/troubleshoot-endpoints.asciidoc @@ -0,0 +1,225 @@ +[[troubleshoot-endpoints]] += Troubleshoot {elastic-defend} + +:keywords: serverless, security, troubleshooting + +++++ +Elastic Defend +++++ + +preview:[] + +This topic covers common troubleshooting issues when using {elastic-defend}'s <>. + +[discrete] +[[ts-endpoints]] +== Endpoints + +.Unhealthy {agent} status +[%collapsible] +===== +In some cases, an `Unhealthy` {agent} status may be caused by a failure in the {elastic-defend} integration policy. In this situation, the integration and any failing features are flagged on the agent details page in {fleet}. Expand each section and subsection to display individual responses from the agent. + +[TIP] +==== +Integration policy response information is also available from the **Endpoints** page in the {security-app} (**Assets** → **Endpoints**, then click the link in the **Policy status** column). +==== + +[role="screenshot"] +image::images/ts-management/-troubleshooting-unhealthy-agent-fleet.png[Agent details page in {fleet} with Unhealthy status and integration failures] + +Common causes of failure in the {elastic-defend} integration policy include missing prerequisites or unexpected system configuration. Consult the following topics to resolve a specific error: + +* <> (macOS) +* <> (macOS) +* <> (Linux) + +[TIP] +==== +If the {elastic-defend} integration policy is not the cause of the `Unhealthy` agent status, refer to {fleet-guide}/fleet-troubleshooting.html[{fleet} troubleshooting] for help with the {agent}. +==== +===== + +.Disabled to avoid potential system deadlock (Linux) +[%collapsible] +===== +If you have an `Unhealthy` {agent} status with the message `Disabled due to potential system deadlock`, that means malware protection was disabled on the {elastic-defend} integration policy due to errors while monitoring a Linux host. + +You can resolve the issue by configuring the policy's <> related to **fanotify**, a Linux feature that monitors file system events. By default, {elastic-defend} works with fanotify to monitor specific file system types that Elastic has tested for compatibility, and ignores other unknown file system types. + +If your network includes nonstandard, proprietary, or otherwise unrecognized Linux file systems that cause errors while being monitored, you can configure {elastic-defend} to ignore those file systems. This allows {elastic-defend} to resume monitoring and protecting the hosts on the integration policy. + +[CAUTION] +==== +Ignoring file systems can create gaps in your security coverage. Use additional security layers for any file systems ignored by {elastic-defend}. +==== + +To resolve the potential system deadlock error: + +. Go to **Assets** → **Policies**, then click a policy's name. +. Scroll to the bottom of the policy and click **Show advanced settings**. +. In the setting `linux.advanced.fanotify.ignored_filesystems`, enter a comma-separated list of file system names to ignore, as they appear in `/proc/filesystems` (for example: `ext4,tmpfs`). Refer to <> for more on determining the file system names. +. Click **Save**. ++ +Once you save the policy, malware protection is re-enabled. +===== + +.Required transform failed +[%collapsible] +===== +If you encounter a `“Required transform failed”` notice on the Endpoints page, you can usually resolve the issue by restarting the transform. Refer to {ref}/transforms.html[Transforming data] for more information about transforms. + +[role="screenshot"] +image::images/ts-management/-troubleshooting-endpoints-transform-failed.png[Endpoints page with Required transform failed notice] + +To restart a transform that’s not running: + +. Go to **Project settings** → **Management** → **Transforms**. +. Enter `endpoint.metadata` in the search box to find the transforms for {elastic-defend}. +. Click the **Actions** menu (image:images/icons/boxesHorizontal.svg[Actions menu icon]) and do one of the following for each transform, depending on the value in the **Status** column: ++ +** `stopped`: Select **Start** to restart the transform. +** `failed`: Select **Stop** to first stop the transform, and then select **Start** to restart it. ++ +[role="screenshot"] +image::images/ts-management/-troubleshooting-transforms-start.png[Transforms page with Start option selected] +. On the confirmation message that displays, click **Start** to restart the transform. +. The transform’s status changes to `started`. If it doesn't change, refresh the page. +===== + +.{agent} and Endpoint connection issues +[%collapsible] +===== +After {agent} installs Endpoint, Endpoint connects to {agent} over a local relay connection to report its health status and receive policy updates and response action requests. If that connection cannot be established, the {elastic-defend} integration will cause {agent} to be in an `Unhealthy` status, and Endpoint won't operate properly. + +[discrete] +[[troubleshoot-endpoints-identify-if-the-issue-is-happening]] +=== Identify if the issue is happening + +You can identify if this issue is happening in the following ways: + +* Run {agent}'s status command: ++ +** `sudo /opt/Elastic/Agent/elastic-agent status` (Linux) +** `sudo /Library/Elastic/Agent/elastic-agent status` (macOS) +** `c:\Program Files\Elastic\Agent\elastic-agent.exe status` (Windows) ++ +If the status result for `endpoint-security` says that Endpoint has missed check-ins or `localhost:6788` cannot be bound to, it might indicate this problem is occurring. +* If the problem starts happening right after installing Endpoint, check the value of `fleet.agent.id` in the following file: ++ +** `/opt/Elastic/Endpoint/elastic-endpoint.yaml` (Linux) +** `/Library/Elastic/Endpoint/elastic-endpoint.yaml` (macOS) +** `c:\Program Files\Elastic\Endpoint\elastic-endpoint.yaml` (Windows) ++ +If the value of `fleet.agent.id` is `00000000-0000-0000-0000-000000000000`, this indicates this problem is occurring. ++ +[NOTE] +==== +If this problem starts happening after Endpoint has already been installed and working properly, then this value will have changed even though the problem is happening. +==== + +[discrete] +[[troubleshoot-endpoints-examine-endpoint-logs]] +=== Examine Endpoint logs + +If you've confirmed that the issue is happening, you can look at Endpoint log messages to identify the cause: + +* `Failed to find connection to validate. Is Agent listening on 127.0.0.1:6788?` or `Failed to validate connection. Is Agent running as root/admin?` means that Endpoint is not able to create an initial connection to {agent} over port `6788`. +* `Unable to make GRPC connection in deadline(60s). Fetching connection info again` means that Endpoint's original connection to {agent} over port `6788` worked, but the connection over port `6789` is failing. + +[discrete] +[[troubleshoot-endpoints-resolve-the-issue]] +=== Resolve the issue + +To debug and resolve the issue, follow these steps: + +. Examine the Endpoint diagnostics file named `analysis.txt`, which contains information about what may cause this issue. {agent} diagnostics automatically include Endpoint diagnostics. +. Make sure nothing else on your device is listening on ports `6788` or `6789` by running: ++ +** `sudo netstat -anp --tcp` (Linux) +** `sudo netstat -an -f inet` (macOS) +** `netstat -an` (Windows) +. Make sure `localhost` can be resolved to `127.0.0.1` by running: ++ +** `ping -4 -c 1 localhost` (Linux) +** `ping -c 1 localhost` (macOS) +** `ping -4 localhost` (Windows) +===== + +.{elastic-defend} deployment issues +[%collapsible] +===== +After deploying {elastic-defend}, you might encounter warnings or errors in the endpoint's **Policy status** in {fleet} if your mobile device management (MDM) is misconfigured or certain permissions for {elastic-endpoint} aren't granted. The following sections explain issues that can cause warnings or failures in the endpoint's policy status. + +[discrete] +[[troubleshoot-endpoints-connect-kernel-has-failed]] +=== Connect Kernel has failed + +This means that the system extension or kernel extension was not approved. Consult the following topics for approving the system extension, either with MDM or without MDM: + +* <> +* <> + +You can validate the system extension is loaded by running + +[source] +---- +sudo systemextensionsctl list | grep co.elastic.systemextension +---- + +In the command output, the system extension should be marked as "active enabled". + +[discrete] +[[troubleshoot-endpoints-connect-kernel-has-failed-and-the-system-extension-is-loaded]] +=== Connect Kernel has failed and the system extension is loaded + +If the system extension is loaded and kernel connection still fails, this means that Full Disk Access was not granted. {elastic-endpoint} requires Full Disk Access to subscribe to system events via the {elastic-defend} framework, which is one of the primary sources of eventing information used by {elastic-endpoint}. Consult the following topics for granting Full Disk Access, either with MDM or without MDM: + +* <> +* <> + +You can validate that Full Disk Access is approved by running + +[source] +---- +sudo /Library/Elastic/Endpoint/elastic-endpoint test install +---- + +If the command output doesn't contain a message about enabling Full Disk Access, the approval was successful. + +[discrete] +[[troubleshoot-endpoints-detect-network-events-has-failed]] +=== Detect Network Events has failed + +This means that the network extension content filtering was not approved. Consult the following topics for approving network content filtering, either with MDM or without MDM: + +* <> +* <> + +You can validate that network content filtering is approved by running + +[source] +---- +sudo /Library/Elastic/Endpoint/elastic-endpoint test install +---- + +If the command output doesn't contain a message about approving network content filtering, the approval was successful. + +[discrete] +[[troubleshoot-endpoints-full-disk-access-has-a-warning]] +=== Full Disk Access has a warning + +This means that Full Disk Access was not granted for one or all {elastic-endpoint} components. Consult the following topics for granting Full Disk Access, either with MDM or without MDM: + +* <> +* <> + +You can validate that Full Disk Access is approved by running + +[source] +---- +sudo /Library/Elastic/Endpoint/elastic-endpoint test install +---- + +If the command output doesn't contain a message about enabling Full Disk Access, the approval was successful. +===== diff --git a/docs/serverless/troubleshooting/troubleshooting-intro.asciidoc b/docs/serverless/troubleshooting/troubleshooting-intro.asciidoc new file mode 100644 index 0000000000..3ef3f512e8 --- /dev/null +++ b/docs/serverless/troubleshooting/troubleshooting-intro.asciidoc @@ -0,0 +1,10 @@ +[[troubleshooting-ov]] += Troubleshooting + +:description: Resolve issues in {elastic-sec}. +:keywords: serverless, security, troubleshooting, overview + +This section covers common {elastic-sec} related issues and how to resolve them. + +* <> +* <> diff --git a/docs/serverless/troubleshooting/ts-detection-rules.asciidoc b/docs/serverless/troubleshooting/ts-detection-rules.asciidoc new file mode 100644 index 0000000000..160a749017 --- /dev/null +++ b/docs/serverless/troubleshooting/ts-detection-rules.asciidoc @@ -0,0 +1,113 @@ +[[ts-detection-rules]] += Troubleshoot detection rules + +:description: Covers common troubleshooting issues when creating or managing detection rules. +:keywords: serverless, security, troubleshooting, configure + +++++ +Detection rules +++++ + +preview:[] + +This topic covers common troubleshooting issues when creating or managing <>. + +[discrete] +[[ML-rules-ts]] +== {ml-cap} rules + +.{ml-cap} rule is failing and a required {ml} job is stopped +[%collapsible] +===== +If a {ml} rule is failing, check to make sure the required {ml} jobs are running and start any jobs that have stopped. + +. Go to **Rules** → **Detection rules (SIEM)**, then select the {ml} rule. The required {ml} jobs and their statuses are listed in the **Definition** section. ++ +[role="screenshot"] +image::images/ts-detection-rules/-troubleshooting-rules-ts-ml-job-stopped.png[Rule details page with ML job stopped] +. If a required {ml} job isn't running, turn on the **Run job** toggle next to it. +. Rerun the {ml} detection rule. +===== + +[discrete] +[[IM-match-rules-ts]] +== Indicator match rules + +.Rules are failing due to number of alerts +[%collapsible] +===== +If you receive the following rule failure: `"Bulk Indexing of signals failed: [parent] Data too large"`, this indicates that the alerts payload was too large to process. + +This can be caused by bad indicator data, a misconfigured rule, or too many event matches. Review your indicator data or rule query. If nothing obvious is misconfigured, try executing the rule against a subset of the original data and continue diagnosis. +===== + +.Indicator match rules are timing out +[%collapsible] +===== +If you receive the following rule failure: `"An error occurred during rule execution: message: "Request Timeout after 90000ms"`, this indicates that the query phase is timing out. Try refining the time frame or dividing the data defined in the query into multiple rules. +===== + +.Indicator match rules are failing because the `maxClauseCount` limit is too low +[%collapsible] +===== +If you receive the following rule failure: `Bulk Indexing of signals failed: index: ".index-name" reason: "maxClauseCount is set to 1024" type: "too_many_clauses"`, this indicates that the limit for the total number of clauses that a query tree can have is too low. To update your maximum clause count, {ref}/advanced-configuration.html#set-jvm-heap-size[increase the size of your {es} JVM heap memory]. 1 GB of {es} JVM heap size or more is sufficient. +===== + +.General slowness +[%collapsible] +===== +If you notice rule delays, review the suggestions above to troubleshoot, and also consider limiting the number of rules that run simultaneously, as this can cause noticeable performance implications. +===== + +[discrete] +[[rule-exceptions-ts]] +== Rule exceptions + +.No autocomplete suggestions +[%collapsible] +===== +When you're creating detection rule exceptions, autocomplete might not provide suggestions in the **Value** field if the values don't exist in the current page's time range. + +You can resolve this by expanding the time range, or by configuring the autocomplete feature to get suggestions from your full data set instead (turn off the `autocomplete:useTimeRange` advanced setting). + +// Will need to revisit this section since it mentions advanced settings, which aren't exposed yet. + +[CAUTION] +==== +Turning off `autocomplete:useTimeRange` could cause performance issues if the data set is especially large. +==== +===== + +.Warning about type conflicts and unmapped fields +[%collapsible] +===== +A warning icon (image:images/icons/warning.svg[Warning]) and message appear for fields with <> across multiple indices or fields that are <>. You can learn more about the conflict by clicking the warning message. + +[NOTE] +==== +A field can have type conflicts _and_ be unmapped in specified indices. +==== + +[role="screenshot"] +image:images/ts-detection-rules/-troubleshooting-warning-icon-message.png[Shows the warning icon and message] + +[discrete] +[[fields-with-conflicting-types]] +=== Fields with conflicting types + +Type conflicts occur when a field is mapped to different types across multiple indices. To resolve this issue, you can create new indices with matching field type mappings and {ref}/docs-reindex.html[reindex your data]. Otherwise, use the information about a field's type mappings to ensure you're entering compatible field values when defining exception conditions. + +In the following example, the selected field has been defined as different types across five indices. + +image:images/ts-detection-rules/-troubleshooting-warning-type-conflicts.png[Warning for fields with type conflicts] + +[discrete] +[[unmapped-field-conflict]] +=== Unmapped fields + +Unmapped fields are undefined within an index's mapping definition. Using unmapped fields to define an exception can prevent it from working as expected, and lead to false positives or unexpected alerts. To fix unmapped fields, {ref}/explicit-mapping.html#update-mapping[add them] to your indices' mapping definitions. + +In the following example, the selected field is unmapped across two indices. + +image:images/ts-detection-rules/-troubleshooting-warning-unmapped-fields.png[Warning for unmapped fields] +===== diff --git a/docs/serverless/what-is-security-serverless.asciidoc b/docs/serverless/what-is-security-serverless.asciidoc new file mode 100644 index 0000000000..a4e2bf4797 --- /dev/null +++ b/docs/serverless/what-is-security-serverless.asciidoc @@ -0,0 +1,77 @@ +[[what-is-security-serverless]] += {elastic-sec} + +:keywords: serverless, security, overview + +preview:[] + + + +Serverless projects provide you with the existing {elastic-sec} on-premise and Elastic Cloud deployment functionality, and the following new features and capabilities: + +* Continuous onboarding hub at the center of the **Get started** page +* Security-focused, single-level navigation +* **Osquery** availability within **Investigations** +* **Assets** management for {fleet}, endpoints, and Cloud +* Security-specific roles +* Machine learning nodes included, by default +* Developer tools for interacting with your data + + + + + +[[what-is-security-serverless-hello-world]] + diff --git a/docs/siem-apis.asciidoc b/docs/siem-apis.asciidoc index 3d3971fbf6..c639fb22a4 100644 --- a/docs/siem-apis.asciidoc +++ b/docs/siem-apis.asciidoc @@ -27,7 +27,7 @@ For more information on {kib} Actions, see {kibana-ref}/alerting-getting-started.html[Alerting and Actions] and https://github.com/elastic/kibana/tree/master/x-pack/plugins/actions[action plugins]. -[float] +[discrete] === API URLs For calls to the `Default` {kib} space, API endpoints are as follows: @@ -53,22 +53,22 @@ NOTE: You can find space URL identifiers on ) or by calling {kibana-ref}/spaces-api-get-all.html[`GET /api/spaces/space`]. -[float] +[discrete] === Authentication The {elastic-sec} APIs support key- and token-based authentication. -[float] +[discrete] ==== Key-based authentication To use key-based authentication, create an {kibana-ref}/api-keys.html[API key], then specify the key in the header of your API calls. -[float] +[discrete] ==== Token-based authentication For token-based authentication, use the same username and password that you use to log in to the {kib} UI. In a given HTTP tool, and when available, you can select to use its **Basic Authentication** option, which is where the username and password are stored in order to be passed as part of the call. -[float] +[discrete] === API calls All calls to APIs are stateless. Each call must include all the information diff --git a/docs/siem/installation.asciidoc b/docs/siem/installation.asciidoc index 5c36ee8f4b..0abc069b8f 100644 --- a/docs/siem/installation.asciidoc +++ b/docs/siem/installation.asciidoc @@ -2,12 +2,12 @@ [[install-siem]] = Get up and running -To use the {security-app}, you need an *Elasticsearch* cluster and *Kibana* +To use the {security-app}, you need an *Elasticsearch* cluster and *Kibana* (version 7.2 or later) with a basic license. See {stack-gs}/get-started-elastic-stack.html[Getting started with the {stack}]. There are some additional requirements for using the -<> feature. For more information, see +<> feature. For more information, see <>. [TIP] @@ -26,13 +26,13 @@ indices, see: (for on-premises {stack} deployments) * {cloud}/ec-enable-ccs.html[Enable cross-cluster search] (for hosted deployments) -[float] +[discrete] [[siem-ingest]] == Ingest data To ingest data, you can use: -* *{beats}* shippers (version 7.x or later) installed for each system you want +* *{beats}* shippers (version 7.x or later) installed for each system you want to monitor. * *https://www.elastic.co/products/endpoint-security[Elastic Endpoint Security]*, which ships events and security alerts directly to {es}. @@ -41,16 +41,16 @@ to monitor. [IMPORTANT] ============== -If you use a third-party collector to ship data to the {security-app}, you must -map its fields to the {ecs-ref}[Elastic Common Schema (ECS)]. Additionally, -you must add its index to the {elastic-sec} {es} indices (*{kib}* -> +If you use a third-party collector to ship data to the {security-app}, you must +map its fields to the {ecs-ref}[Elastic Common Schema (ECS)]. Additionally, +you must add its index to the {elastic-sec} {es} indices (*{kib}* -> *Management* -> *Advanced Settings* -> *`siem:defaultIndex`*). -{elastic-sec} uses the {ecs-ref}/ecs-host.html[`host.name`] ECS field as the +{elastic-sec} uses the {ecs-ref}/ecs-host.html[`host.name`] ECS field as the primary key for identifying hosts. ============== -[float] +[discrete] [[install-beats]] === Install {beats} shippers @@ -67,7 +67,7 @@ network activity You can install {beats} using a {kib}-based guide or directly from the command line. -[float] +[discrete] === Install {beats} using the {kib}-based guide Follow the instructions in the Add Data section of the {kib} home page. Click @@ -77,7 +77,7 @@ collect. [role="screenshot"] image::add-data.png[] -[float] +[discrete] === Download and install {beats} from the command line If your data source isn't in the list, or you want to install {beats} the old @@ -95,7 +95,7 @@ for the events you want to collect, see the * *Packetbeat.* See {packetbeat-ref}/packetbeat-installation-configuration.html[{packetbeat} quick start]. -[float] +[discrete] === Enable modules and configuration options No matter how you installed {beats}, you need to enable modules in {auditbeat} diff --git a/docs/siem/overview.asciidoc b/docs/siem/overview.asciidoc index f1ca07d4a5..36afd2fb2d 100644 --- a/docs/siem/overview.asciidoc +++ b/docs/siem/overview.asciidoc @@ -50,7 +50,7 @@ identify and investigate suspicious activity: * https://www.elastic.co/products/stack/alerting[Alerting] * https://www.elastic.co/products/stack/canvas[Canvas] -[float] +[discrete] [[data-sources]] == Data sources @@ -117,7 +117,7 @@ By default, the {security-app} monitors {apm-app-ref}/apm-getting-started.html[A index patterns in the `securitysolution:defaultIndex` setting ({kib} -> Management -> Advanced Settings -> `securitySolution:defaultIndex`). -[float] +[discrete] [[ecs]] === Elastic Common Schema (ECS) for normalizing data diff --git a/docs/troubleshooting/ts-detection-rules.asciidoc b/docs/troubleshooting/ts-detection-rules.asciidoc index 1910448303..549907813d 100644 --- a/docs/troubleshooting/ts-detection-rules.asciidoc +++ b/docs/troubleshooting/ts-detection-rules.asciidoc @@ -7,7 +7,7 @@ :frontmatter-description: Covers common troubleshooting issues when creating or managing detection rules. :frontmatter-tags-products: [security] :frontmatter-tags-content-type: [troubleshooting] -:frontmatter-tags-user-goals: [configure] +:frontmatter-tags-user-goals: [configure] This topic covers common troubleshooting issues when creating or managing <>. @@ -87,37 +87,37 @@ CAUTION: Turning off `autocomplete:useTimeRange` could cause performance issues [discrete] [[rule-exceptions-field-conflicts]] -.Warning about type conflicts and unmapped fields +.Warning about type conflicts and unmapped fields [%collapsible] ==== -A warning icon (image:images/field-warning-icon.png[Field conflict warning icon,13,13]) and message appear for fields with <> across multiple indices or fields that are <>. You can learn more about the conflict by clicking the warning message. +A warning icon (image:images/field-warning-icon.png[Field conflict warning icon,13,13]) and message appear for fields with <> across multiple indices or fields that are <>. You can learn more about the conflict by clicking the warning message. -NOTE: A field can have type conflicts _and_ be unmapped in specified indices. +NOTE: A field can have type conflicts _and_ be unmapped in specified indices. [role="screenshot"] image::images/warning-icon-message.png[Shows the warning icon and message,70%] -[float] +[discrete] [[fields-with-conflicting-types]] -==== Fields with conflicting types +==== Fields with conflicting types -Type conflicts occur when a field is mapped to different types across multiple indices. To resolve this issue, you can create new indices with matching field type mappings and {ref}/docs-reindex.html[reindex your data]. Otherwise, use the information about a field's type mappings to ensure you're entering compatible field values when defining exception conditions. +Type conflicts occur when a field is mapped to different types across multiple indices. To resolve this issue, you can create new indices with matching field type mappings and {ref}/docs-reindex.html[reindex your data]. Otherwise, use the information about a field's type mappings to ensure you're entering compatible field values when defining exception conditions. In the following example, the selected field has been defined as different types across five indices. [role="screenshot"] -image::images/warning-type-conflicts.png[Warning for fields with type conflicts,60%] +image::images/warning-type-conflicts.png[Warning for fields with type conflicts,60%] -[float] +[discrete] [[unmapped-field-conflict]] -==== Unmapped fields +==== Unmapped fields -Unmapped fields are undefined within an index's mapping definition. Using unmapped fields to define an exception can prevent it from working as expected, and lead to false positives or unexpected alerts. To fix unmapped fields, {ref}/explicit-mapping.html#update-mapping[add them] to your indices' mapping definitions. +Unmapped fields are undefined within an index's mapping definition. Using unmapped fields to define an exception can prevent it from working as expected, and lead to false positives or unexpected alerts. To fix unmapped fields, {ref}/explicit-mapping.html#update-mapping[add them] to your indices' mapping definitions. -In the following example, the selected field is unmapped across two indices. +In the following example, the selected field is unmapped across two indices. [role="screenshot"] -image::images/warning-unmapped-fields.png[Warning for unmapped fields,60%] +image::images/warning-unmapped-fields.png[Warning for unmapped fields,60%] ==== \ No newline at end of file diff --git a/docs/troubleshooting/ts-management.asciidoc b/docs/troubleshooting/ts-management.asciidoc index 596b4827f5..4c541e1440 100644 --- a/docs/troubleshooting/ts-management.asciidoc +++ b/docs/troubleshooting/ts-management.asciidoc @@ -52,7 +52,7 @@ To resolve the potential system deadlock error: . In the setting `linux.advanced.fanotify.ignored_filesystems`, enter a comma-separated list of file system names to ignore, as they appear in `/proc/filesystems` (for example: `ext4,tmpfs`). Refer to <> for more on determining the file system names. -. Click *Save*. +. Click *Save*. + Once you save the policy, malware protection is re-enabled. ==== @@ -72,7 +72,7 @@ To restart a transform that’s not running: . Go to *Kibana* -> *Stack Management* -> *Data* -> *Transforms*. . Enter `endpoint.metadata` in the search box to find the transforms for {elastic-defend}. . Click the *Actions* menu (*...*) and do one of the following for each transform, depending on the value in the *Status* column: -* `stopped`: Select *Start* to restart the transform. +* `stopped`: Select *Start* to restart the transform. * `failed`: Select *Stop* to first stop the transform, and then select *Start* to restart it. + [role="screenshot"] @@ -90,7 +90,7 @@ image::images/transforms-start.png[Transforms page with Start option selected] After {agent} installs Endpoint, Endpoint connects to {agent} over a local relay connection to report its health status and receive policy updates and response action requests. If that connection cannot be established, the {elastic-defend} integration will cause {agent} to be in an `Unhealthy` status, and Endpoint won't operate properly. -[float] +[discrete] ==== Identify if the issue is happening You can identify if this issue is happening in the following ways: @@ -117,7 +117,7 @@ If the value of `fleet.agent.id` is `00000000-0000-0000-0000-000000000000`, this + NOTE: If this problem starts happening after Endpoint has already been installed and working properly, then this value will have changed even though the problem is happening. -[float] +[discrete] ==== Examine Endpoint logs If you've confirmed that the issue is happening, you can look at Endpoint log messages to identify the cause: @@ -126,7 +126,7 @@ If you've confirmed that the issue is happening, you can look at Endpoint log me * `Unable to make GRPC connection in deadline(60s). Fetching connection info again` means that Endpoint's original connection to {agent} over port `6788` worked, but the connection over port `6789` is failing. -[float] +[discrete] ==== Resolve the issue To debug and resolve the issue, follow these steps: @@ -155,7 +155,7 @@ To debug and resolve the issue, follow these steps: After deploying {elastic-defend}, you might encounter warnings or errors in the endpoint's **Policy status** in {fleet} if your mobile device management (MDM) is misconfigured or certain permissions for {elastic-endpoint} aren't granted. The following sections explain issues that can cause warnings or failures in the endpoint's policy status. -[float] +[discrete] ==== Connect Kernel has failed This means that the system extension or kernel extension was not approved. Consult the following topics for approving the system extension with or without MDM: @@ -172,7 +172,7 @@ sudo systemextensionsctl list | grep co.elastic.systemextension In the command output, the system extension should be marked as "active enabled". -[float] +[discrete] ==== Connect Kernel has failed and the system extension is loaded If the system extension is loaded and kernel connection still fails, this means that Full Disk Access was not granted. {elastic-endpoint} requires Full Disk Access to subscribe to system events through the {elastic-defend} framework, which is one of the primary sources of eventing information used by {elastic-endpoint}. Consult the following topics for granting Full Disk Access with or without MDM: @@ -189,7 +189,7 @@ sudo /Library/Elastic/Endpoint/elastic-endpoint test install If the command output doesn't contain a message about enabling Full Disk Access, the approval was successful. -[float] +[discrete] ==== Detect Network Events has failed This means that the network extension content filtering was not approved. Consult the following topics for approving network content filtering with or without MDM: @@ -205,7 +205,7 @@ sudo /Library/Elastic/Endpoint/elastic-endpoint test install ---------------------------------- If the command output doesn't contain a message about approving network content filtering, the approval was successful. -[float] +[discrete] ==== Full Disk Access has a warning This means that Full Disk Access was not granted for one or all {elastic-endpoint} components. Consult the following topics for granting Full Disk Access with or without MDM: diff --git a/docs/upgrade/upgrade-7.17-8.x.asciidoc b/docs/upgrade/upgrade-7.17-8.x.asciidoc index 3e51e3648e..c9295e63ef 100644 --- a/docs/upgrade/upgrade-7.17-8.x.asciidoc +++ b/docs/upgrade/upgrade-7.17-8.x.asciidoc @@ -1,12 +1,12 @@ [[upgrade-7.17-8x]] == Upgrade from 7.17 to an 8.x version -[float] +[discrete] === Why it's important to upgrade -Upgrading provides you access to {elastic-sec}'s latest features, enhancements, and bug fixes, many of which enable you to save your organization money, respond faster to potential threats, and improve the tools you use to investigate and analyze your data. For more benefits, check out our blog, https://www.elastic.co/blog/top-5-reasons-to-upgrade-elastic-security[Top 5 reasons to upgrade Elastic Security]. Also, it's important to ensure that your deployment is fully maintained and supported. For more information, refer to https://www.elastic.co/support/eol[Elastic's Product End of Life Dates]. +Upgrading provides you access to {elastic-sec}'s latest features, enhancements, and bug fixes, many of which enable you to save your organization money, respond faster to potential threats, and improve the tools you use to investigate and analyze your data. For more benefits, check out our blog, https://www.elastic.co/blog/top-5-reasons-to-upgrade-elastic-security[Top 5 reasons to upgrade Elastic Security]. Also, it's important to ensure that your deployment is fully maintained and supported. For more information, refer to https://www.elastic.co/support/eol[Elastic's Product End of Life Dates]. -[float] +[discrete] === Plan for your upgrade Before upgrading to {elastic-sec} 8.x, consider the following recommendations: @@ -15,26 +15,26 @@ Before upgrading to {elastic-sec} 8.x, consider the following recommendations: * Open a https://support.elastic.co[support case] with Elastic to alert our Elastic Support team of your system change. If you need additional assistance, https://www.elastic.co/consulting[Elastic Consulting Services] provides the technical expertise and step-by-step approach for upgrading your Elastic deployment. -* Choose a version to upgrade to. We recommend the latest minor and patch version. Be sure to upgrade your development or non-production deployment to the same version as your production deployment. +* Choose a version to upgrade to. We recommend the latest minor and patch version. Be sure to upgrade your development or non-production deployment to the same version as your production deployment. -* Ensure that you have {kibana-ref}/xpack-monitoring.html[stack monitoring] enabled in {kib}. Take note of your current index and search rate. +* Ensure that you have {kibana-ref}/xpack-monitoring.html[stack monitoring] enabled in {kib}. Take note of your current index and search rate. * Review your selected version's features, Elastic connectors, integrations, and detection rules to determine if you can replace any customized content with out-of-the-box functionality. This can help reduce your workload and the complexity of your upgrade. * If your organization sends alerts (formerly known as signals) to an external SOAR (security orchestration, automation, and response) platform, you may need to change your workflows to accommodate the new <> used in 8.x. -* Review release notes, deprecations, and breaking changes for {security-guide}/release-notes.html[{elastic-sec}], {ref}/es-release-notes.html[{es}], {kibana-ref}/release-notes.html[{kib}], and, if applicable, {fleet-guide}/release-notes.html[{fleet} and {agent}], {beats-ref}/release-notes.html[{beats}], and {logstash-ref}/releasenotes.html[{ls}]. Identify any issues that might affect your deployment. Work with your Elastic team on any questions you may have. Start with breaking changes for your solution and platform components, such as {es} and {kib}. +* Review release notes, deprecations, and breaking changes for {security-guide}/release-notes.html[{elastic-sec}], {ref}/es-release-notes.html[{es}], {kibana-ref}/release-notes.html[{kib}], and, if applicable, {fleet-guide}/release-notes.html[{fleet} and {agent}], {beats-ref}/release-notes.html[{beats}], and {logstash-ref}/releasenotes.html[{ls}]. Identify any issues that might affect your deployment. Work with your Elastic team on any questions you may have. Start with breaking changes for your solution and platform components, such as {es} and {kib}. * Schedule a system maintenance window within your organization. -[float] +[discrete] === Pre-upgrade steps To prepare for the upgrade process, follow these steps before you start: -. Do a software version inventory across your entire Elastic deployment, including {es}, {kib}, {agent}, {beats}, and {ls}. +. Do a software version inventory across your entire Elastic deployment, including {es}, {kib}, {agent}, {beats}, and {ls}. -. If you're running any versions earlier than 7.17, you must first upgrade them all to the latest 7.17.x patch release before upgrading to 8.x. This enables you to use the Upgrade Assistant to upgrade to 8.x. +. If you're running any versions earlier than 7.17, you must first upgrade them all to the latest 7.17.x patch release before upgrading to 8.x. This enables you to use the Upgrade Assistant to upgrade to 8.x. + NOTE: If you're managing your deployments using {ece-ref}/ece-upgrade.html[{ece}] (ECE) or {eck-ref}/k8s-upgrading-eck.html[{eck}] (ECK), you may need to upgrade the system clusters first. @@ -50,7 +50,7 @@ To run the Upgrade Assistant, you must have the `superuser` role on the cluster. . If you're not using {ref}/snapshots-take-snapshot.html#automate-snapshots-slm[{slm} (SLM)], you must set up and configure a policy, then run the policy to create at least one {ref}/snapshot-restore.html[snapshot] -- a backup of indices taken from a running cluster. If you need to roll back during the upgrade process, use a recent snapshot to avoid data loss. Snapshots are {ref}/snapshot-restore.html#how-snapshots-work[incremental] -- depending on the cluster size and the input/output rate, the initial snapshot may take several hours to complete. If you're using SLM, {ref}/snapshots-take-snapshot.html#check-slm-history[check the SLM history] to ensure that snapshots are completing successfully. -[float] +[discrete] === Perform an 8.x upgrade on a deployment IMPORTANT: We strongly recommend performing the following steps on a non-production deployment first to address any potential issues before upgrading your production deployments. If you're using a cross-cluster search environment, upgrade your remote deployments first. @@ -59,15 +59,15 @@ IMPORTANT: We strongly recommend performing the following steps on a non-product . We recommend you <> in case there are issues with the detection engine after the upgrade. -. Upgrade {es}. -** If you're using {ecloud}, we recommend upgrades with no downtime. Refer to {cloud}/ec-upgrade-deployment.html[these instructions]. -** If you're using {ece} (ECE), refer to {ece-ref}/ece-upgrade-deployment.html[these instructions]. -** If you're using {eck} (ECK), refer to {eck-ref}/k8s-upgrading-stack.html[these instructions]. +. Upgrade {es}. +** If you're using {ecloud}, we recommend upgrades with no downtime. Refer to {cloud}/ec-upgrade-deployment.html[these instructions]. +** If you're using {ece} (ECE), refer to {ece-ref}/ece-upgrade-deployment.html[these instructions]. +** If you're using {eck} (ECK), refer to {eck-ref}/k8s-upgrading-stack.html[these instructions]. ** If you're upgrading a self-orchestrated deployment, refer to {stack-ref}/upgrading-elasticsearch.html[these instructions] and upgrade the data nodes tier by tier in this order: ... Frozen tier -... Cold tier +... Cold tier ... Warm tier -... Hot tier +... Hot tier ... Any other nodes not in a tier ... All remaining nodes that are neither master-eligible nor data nodes ... Master-eligible nodes @@ -76,15 +76,15 @@ IMPORTANT: We strongly recommend performing the following steps on a non-product + NOTE: If you're using Elastic Cloud Hosted or {ece}, this is already included in the {es} upgrade. -. Validate that {es} and {kib} are operating as expected by completing the following checks: +. Validate that {es} and {kib} are operating as expected by completing the following checks: .. For {es}: ... Check the status of your clusters and ensure that they're green by running a `GET _cat/health` API request. For more information, refer to the {ref}/cat-health.html[cat health API documentation]. ... Ensure that the index and search rate are close to what they were before upgrading. Go to **Stack Monitoring** -> **{es}** -> **Overview**. + TIP: You can also check the index document count using the {ref}/cat-indices.html[cat index API]. -... Verify that {slm} SLM is taking snapshots by {ref}/snapshots-take-snapshot.html#check-slm-history[checking the SLM history]. -... If you use {ml}, ensure that it is up and running. -.. For {kib}: +... Verify that {slm} SLM is taking snapshots by {ref}/snapshots-take-snapshot.html#check-slm-history[checking the SLM history]. +... If you use {ml}, ensure that it is up and running. +.. For {kib}: ... Ensure that you and your users can successfully log in to {kib} and access desired pages. ... Check {kibana-ref}/discover.html[Discover] and verify that the index patterns you typically use are available. ... Verify that your commonly used {kibana-ref}/dashboard.html[dashboards] are available and working properly. @@ -93,22 +93,22 @@ TIP: You can also check the index document count using the {ref}/cat-indices.htm . Upgrade your ingest components (such as {ls}, {fleet} and {agent}, {beats}, etc.). For details, refer to the {stack-ref}/upgrading-elastic-stack.html[Elastic Stack upgrade docs]. . Validate that ingest is operating correctly. -.. Open *Discover*, go through data views for each of your expected ingest data streams, and ensure that data is being ingested in the expected format and volume. +.. Open *Discover*, go through data views for each of your expected ingest data streams, and ensure that data is being ingested in the expected format and volume. . Validate that {elastic-sec} is operating correctly. .. On the **Rules** page, re-enable your desired SIEM detection rules (**Rule Management** tab), and ensure that enabled rules are running without errors or warnings (**Rule Monitoring** tab). .. Ensure that any SOAR workflows that consume alerts are working. .. Verify that any custom dashboards your team has created are working properly, especially if they operate on alert documents. -. If you performed these steps on a non-production deployment, repeat these same steps on your production environment. If you're using a cross-cluster search environment and performed these steps on your remote clusters, repeat these same steps on your other deployments. +. If you performed these steps on a non-production deployment, repeat these same steps on your production environment. If you're using a cross-cluster search environment and performed these steps on your remote clusters, repeat these same steps on your other deployments. . Confirm with your appropriate stakeholders that the upgrade process has been successful. -[float] +[discrete] === Post-upgrade steps The following sections describe procedures to complete after upgrading {elastic-sec} to 8.x. -[float] +[discrete] [[reenable-rules-upgrade]] ==== Re-enable disabled rules @@ -121,25 +121,25 @@ Any active rules when you upgrade from 7.17 to 8.0.1 or newer are automatically Alternatively, you can use the <> API to re-enable rules. -[float] +[discrete] [[fda-upgrade]] ==== Full Disk Access (FDA) approval for {elastic-endpoint} When you manually install {elastic-endpoint}, you must approve a system extension, kernel extension, and enable Full Disk Access (FDA). There is a new FDA requirement in 8.x. Refer to <> to review the required permissions. -[float] +[discrete] [[data-views-upgrade]] ==== Requirements to display Data views in the {security-app} -To make the *Data view* option appear in an environment with legacy alerts, a user with elevated role privileges must visit the {security-app}, open a page that displays alert data (at least one alert must be present), and then refresh the page. The user's role privileges must allow them to enable the detections feature in a {kib} space. For more information, refer to <>. +To make the *Data view* option appear in an environment with legacy alerts, a user with elevated role privileges must visit the {security-app}, open a page that displays alert data (at least one alert must be present), and then refresh the page. The user's role privileges must allow them to enable the detections feature in a {kib} space. For more information, refer to <>. -[float] +[discrete] [[alert-schema-upgrade]] ==== New alert schema The system index for detection alerts has been renamed from `.siem-signals-` to `.alerts-security.alerts-` and is now a hidden index. Therefore, the schema used for alert documents in {elastic-sec} has changed. Users that access documents in the `.siem-signals` indices using the {elastic-sec} API must modify their API queries and scripts to operate properly on the new 8.x alert documents. Refer to <> and review the new <>. -[float] +[discrete] [[preview-upgrade]] ==== New privileges required to view alerts and preview rules @@ -147,7 +147,7 @@ The system index for detection alerts has been renamed from `.siem-signals->, users need `read` access to the new `.preview.alerts-security.alerts` index. Refer to <> for more information. -[float] +[discrete] [[im-rules-upgrade]] ==== Updates to indicator match rules diff --git a/docs/upgrade/upgrade-security.asciidoc b/docs/upgrade/upgrade-security.asciidoc index 8cab48dd6a..66759712a6 100644 --- a/docs/upgrade/upgrade-security.asciidoc +++ b/docs/upgrade/upgrade-security.asciidoc @@ -20,7 +20,7 @@ earlier version of {kib}. To roll back, you **must** have a state. By default, snapshots include the `kibana` feature state. ==== -[float] +[discrete] == Upgrading multiple {kib} instances When upgrading several {kib} instances connected to the same {es} cluster, ensure that all outdated instances are shut down before starting the upgrade. @@ -36,22 +36,22 @@ IMPORTANT: You can upgrade to pre-release versions for testing, but upgrading from a pre-release to the Generally Available version is unsupported. You should use pre-release versions only for testing in a temporary environment. -[float] +[discrete] === Ensure that all {kib} instances are the same When you perform an upgrade migration of different {kib} versions, the migration can fail. Ensure that all {kib} instances are running the same version, configuration, and plugins. -[float] +[discrete] == Support for Elastic prebuilt detection rule automatic updates <> are supported for the current {elastic-sec} version and the latest three previous minor releases. For example, if you’re upgrading to {elastic-sec} 8.10, you’ll be able to use the Rules UI to update your prebuilt rules until {elastic-sec} 8.14 is released. After that point, you can still manually download and install updated prebuilt rules, but you must upgrade to the latest {elastic-sec} version to receive automatic updates. -[float] +[discrete] [[upgrade-8x-8x]] == Upgrade from an 8.x to an 8.x version Follow this guide to upgrade from an earlier 8.x version to a later 8.x version. -[float] +[discrete] === Plan for your upgrade Before upgrading from an earlier 8.x version, consider the following recommendations: @@ -60,26 +60,26 @@ Before upgrading from an earlier 8.x version, consider the following recommendat * Open a https://support.elastic.co[support case] with Elastic to alert our Elastic Support team of your system change. If you need additional assistance, https://www.elastic.co/consulting[Elastic Consulting Services] provides the technical expertise and step-by-step approach for upgrading your Elastic deployment. -* Choose a version to upgrade to. We recommend the latest minor and patch version. Be sure to upgrade your development or non-production deployment to the same version as your production deployment. +* Choose a version to upgrade to. We recommend the latest minor and patch version. Be sure to upgrade your development or non-production deployment to the same version as your production deployment. -* Ensure that you have {kibana-ref}/xpack-monitoring.html[stack monitoring] enabled in {kib}. Take note of your current index and search rate. +* Ensure that you have {kibana-ref}/xpack-monitoring.html[stack monitoring] enabled in {kib}. Take note of your current index and search rate. * Review your selected version's features, Elastic connectors, integrations, and detection rules to determine if you can replace any customized content with out-of-the-box functionality. This can help reduce your workload and the complexity of your upgrade. -* Review release notes, deprecations, and breaking changes for {security-guide}/release-notes.html[{elastic-sec}], {ref}/es-release-notes.html[{es}], {kibana-ref}/release-notes.html[{kib}], and, if applicable, {fleet-guide}/release-notes.html[{fleet} and {agent}], {beats-ref}/release-notes.html[{beats}], and {logstash-ref}/releasenotes.html[{ls}]. Identify any issues that might affect your deployment. Work with your Elastic team on any questions you may have. Start with breaking changes for your solution and platform components, such as {es} and {kib}. +* Review release notes, deprecations, and breaking changes for {security-guide}/release-notes.html[{elastic-sec}], {ref}/es-release-notes.html[{es}], {kibana-ref}/release-notes.html[{kib}], and, if applicable, {fleet-guide}/release-notes.html[{fleet} and {agent}], {beats-ref}/release-notes.html[{beats}], and {logstash-ref}/releasenotes.html[{ls}]. Identify any issues that might affect your deployment. Work with your Elastic team on any questions you may have. Start with breaking changes for your solution and platform components, such as {es} and {kib}. * Schedule a system maintenance window within your organization. -[float] +[discrete] === Pre-upgrade steps To prepare for the upgrade process, follow these steps before you start: -. Do a software version inventory across your entire Elastic deployment, including {es}, {kib}, {agent}, {beats}, and {ls}. +. Do a software version inventory across your entire Elastic deployment, including {es}, {kib}, {agent}, {beats}, and {ls}. . If you're not using {ref}/snapshots-take-snapshot.html#automate-snapshots-slm[{slm} (SLM)], you must set up and configure a policy, then run the policy to create at least one {ref}/snapshot-restore.html[snapshot]—a backup of indices taken from a running cluster. If you need to roll back during the upgrade process, use a recent snapshot to avoid data loss. Snapshots are {ref}/snapshot-restore.html#how-snapshots-work[incremental]—depending on the cluster size and the input/output rate, the initial snapshot may take several hours to complete. If you're using SLM, {ref}/snapshots-take-snapshot.html#check-slm-history[check the SLM history] to ensure that snapshots are completing successfully. -[float] +[discrete] === Perform an 8.x to 8.x upgrade on a deployment IMPORTANT: We strongly recommend performing the following steps on a non-production deployment first to address any potential issues before upgrading your production deployments. If you're using a cross-cluster search environment, upgrade your remote deployments first. @@ -88,15 +88,15 @@ IMPORTANT: We strongly recommend performing the following steps on a non-product . We recommend you <> in case there are issues with the detection engine after the upgrade. -. Upgrade {es}. -** If you're using {ecloud}, we recommend upgrades with no downtime. Refer to {cloud}/ec-upgrade-deployment.html[these instructions]. -** If you're using {ece} (ECE), refer to {ece-ref}/ece-upgrade-deployment.html[these instructions]. -** If you're using {eck} (ECK), refer to {eck-ref}/k8s-upgrading-stack.html[these instructions]. +. Upgrade {es}. +** If you're using {ecloud}, we recommend upgrades with no downtime. Refer to {cloud}/ec-upgrade-deployment.html[these instructions]. +** If you're using {ece} (ECE), refer to {ece-ref}/ece-upgrade-deployment.html[these instructions]. +** If you're using {eck} (ECK), refer to {eck-ref}/k8s-upgrading-stack.html[these instructions]. ** If you're upgrading a self-orchestrated deployment, refer to {stack-ref}/upgrading-elasticsearch.html[these instructions] and upgrade the data nodes tier by tier in this order: ... Frozen tier -... Cold tier +... Cold tier ... Warm tier -... Hot tier +... Hot tier ... Any other nodes not in a tier ... All remaining nodes that are neither master-eligible nor data nodes ... Master-eligible nodes @@ -105,15 +105,15 @@ IMPORTANT: We strongly recommend performing the following steps on a non-product + NOTE: If you're using Elastic Cloud Hosted or {ece}, this is already included in the {es} upgrade. -. Validate that {es} and {kib} are operating as expected by completing the following checks: +. Validate that {es} and {kib} are operating as expected by completing the following checks: .. For {es}: ... Check the status of your clusters and ensure that they're green by running a `GET _cat/health` API request. For more information, refer to the {ref}/cat-health.html[cat health API documentation]. ... Ensure that the index and search rate are close to what they were before upgrading. Go to **Stack Monitoring** -> **{es}** -> **Overview**. + TIP: You can also check the index document count using the {ref}/cat-indices.html[cat index API]. -... Verify that {slm} (SLM) is taking snapshots by {ref}/snapshots-take-snapshot.html#check-slm-history[checking the SLM history]. -... If you use {ml}, ensure that it is up and running. -.. For {kib}: +... Verify that {slm} (SLM) is taking snapshots by {ref}/snapshots-take-snapshot.html#check-slm-history[checking the SLM history]. +... If you use {ml}, ensure that it is up and running. +.. For {kib}: ... Ensure that you and your users can successfully log in to {kib} and access desired pages. ... Check {kibana-ref}/discover.html[Discover] and verify that the index patterns you typically use are available. ... Verify that your commonly used {kibana-ref}/dashboard.html[dashboards] are available and working properly. @@ -122,27 +122,27 @@ TIP: You can also check the index document count using the {ref}/cat-indices.htm . Upgrade your ingest components (such as {ls}, {fleet} and {agent}, {beats}, etc.). For details, refer to the {stack-ref}/upgrading-elastic-stack.html[Elastic Stack upgrade docs]. . Validate that ingest is operating correctly. -.. Open *Discover*, go through data views for each of your expected ingest data streams, and ensure that data is being ingested in the expected format and volume. +.. Open *Discover*, go through data views for each of your expected ingest data streams, and ensure that data is being ingested in the expected format and volume. . Validate that {elastic-sec} is operating correctly. .. On the **Rules** page, re-enable your desired SIEM detection rules (**Rule Management** tab), and ensure that enabled rules are running without errors or warnings (**Rule Monitoring** tab). .. Ensure that any SOAR workflows that consume alerts are working. .. Verify that any custom dashboards your team has created are working properly, especially if they operate on alert documents. -. If you performed these steps on a non-production deployment, repeat these same steps on your production environment. If you're using a cross-cluster search environment and performed these steps on your remote clusters, repeat these same steps on your other deployments. +. If you performed these steps on a non-production deployment, repeat these same steps on your production environment. If you're using a cross-cluster search environment and performed these steps on your remote clusters, repeat these same steps on your other deployments. . Confirm with your appropriate stakeholders that the upgrade process has been successful. -[float] +[discrete] [[upgrade-notes-8.8]] === Considerations when upgrading to 8.8 or later -After you upgrade to 8.8 or later, frequency settings for <> created in 8.7 or earlier are automatically moved from the rule level to the action level. The action schedules remain the same and will continue to run on their previously specified frequency (`On each rule execution`, `Hourly`, `Daily`, or `Weekly`). +After you upgrade to 8.8 or later, frequency settings for <> created in 8.7 or earlier are automatically moved from the rule level to the action level. The action schedules remain the same and will continue to run on their previously specified frequency (`On each rule execution`, `Hourly`, `Daily`, or `Weekly`). -[float] +[discrete] [[upgrade-7.16-8.x]] == Upgrade from 7.16 or earlier to an 8.x version -To upgrade from 7.16.0 or earlier to {version}, you must first upgrade your {stack} and {agent}s to 7.17 (refer to {fleet-guide}/upgrade-elastic-agent.html[Upgrade Fleet-managed Elastic Agents]). This enables you to use the {kibana-ref}/upgrade-assistant.html[Upgrade Assistant] to prepare for the upgrade. Before you upgrade, you must resolve all critical issues identified by the Upgrade Assistant. Afterwards, you can <>. +To upgrade from 7.16.0 or earlier to {version}, you must first upgrade your {stack} and {agent}s to 7.17 (refer to {fleet-guide}/upgrade-elastic-agent.html[Upgrade Fleet-managed Elastic Agents]). This enables you to use the {kibana-ref}/upgrade-assistant.html[Upgrade Assistant] to prepare for the upgrade. Before you upgrade, you must resolve all critical issues identified by the Upgrade Assistant. Afterwards, you can <>. Initially, {agent}s will be version 7.17. This is fine because {elastic-sec} 8.x supports the last minor release in 7.x (7.17) and any subsequent {elastic-endpoint} versions in 8.x. After the {stack} upgrade, you can decide whether to upgrade {agent}s to 8.x, which is recommended to ensure you get the latest features. diff --git a/docs/whats-new.asciidoc b/docs/whats-new.asciidoc index d38bdd5da4..ba0f98e175 100644 --- a/docs/whats-new.asciidoc +++ b/docs/whats-new.asciidoc @@ -10,15 +10,15 @@ Other versions: {security-guide-all}/8.14/whats-new.html[8.14] | {security-guide // NOTE: The notable-highlights tagged regions are re-used in the Installation and Upgrade Guide. Full URL links are required in tagged regions. // tag::notable-highlights[] -[float] +[discrete] == Generative AI enhancements -[float] +[discrete] === Manage Elastic AI Assistant using API -You can now interact with and manage {security-guide}/security-assistant.html[Elastic AI Assistant] using the {security-guide}/assistant-api-overview.html[Elastic AI Assistant API]. +You can now interact with and manage {security-guide}/security-assistant.html[Elastic AI Assistant] using the {security-guide}/assistant-api-overview.html[Elastic AI Assistant API]. -[float] +[discrete] === Create new third-party data integrations using Automatic Import preview:[] {security-guide}/automatic-import.html[Automatic Import] uses AI to create integrations for your custom data sources. @@ -26,23 +26,23 @@ preview:[] {security-guide}/automatic-import.html[Automatic Import] uses AI to c [role="screenshot"] image::whats-new/images/8.15/auto-import-success-message.png[Automatic Import success message, 80%] -[float] +[discrete] == Entity Analytics enhancements -[float] +[discrete] === Automatic recalculation of entity risk score {security-guide}/entity-risk-scoring.html[Entity risk score] is now automatically recalculated when you assign, change, or unassign an individual entity's {security-guide}/asset-criticality.html[asset criticality] level. -[float] +[discrete] === Manage asset criticality using API You can now manage {security-guide}/asset-criticality.html[asset criticality] using the {security-guide}/asset-criticality-api-overview.html[asset criticality API]. -[float] +[discrete] == Detection rules and alerts enhancements -[float] +[discrete] === Edit fields for detection rules You can now edit these fields for user-created {security-guide}/rules-ui-create.html[custom rules]: @@ -59,35 +59,35 @@ image::whats-new/images/8.15/max-alerts-per-run.png[The Max alerts per run field [role="screenshot"] image::whats-new/images/8.15/required-fields-related-integrations.png[The Required fields and Related integrations fields highlighted in the Create new rule UI] -[float] +[discrete] === Suppress alerts for {ml} and {esql} rules {security-guide}/alert-suppression.html[Alert suppression] now supports the {ml} and {esql} rule types. You can use it to reduce the number of repeated or duplicate detection alerts generated from {ml} and {esql} rules. -[float] +[discrete] === Use AI Assistant when writing rule queries When creating rules, you can now use AI Assistant to improve rule queries or to quickly correct them. -[float] +[discrete] === Bulk update custom highlighted fields for rules Bulk add or remove {security-guide}/rules-ui-create.html#rule-ui-advanced-params[custom highlighted fields] for multiple detection rules. -[float] +[discrete] === Preview entities and alerts in the alert details flyout You can now preview host and user details from the **Insights** tab of the {security-guide}/view-alert-details.html[alert details flyout] instead of going to the **Hosts** or **Users** pages for more information. From the **Correlations** tab in the flyout, you can also preview alerts that are related to each other instead of leaving the flyout to access them. -[float] +[discrete] === Expandable alert details flyout enabled by default The expandable alert details flyout is now enabled by default in multiple places throughout the {security-app}. -[float] -== Improvements to the Timeline data exploration experience +[discrete] +== Improvements to the Timeline data exploration experience -Several improvements have been made to enhance your data exploration experience in Timeline: +Several improvements have been made to enhance your data exploration experience in Timeline: - Multiple components from Discover have been incorporated, such as the sidebar and table, which allow you to quickly find fields of interest. + @@ -104,15 +104,15 @@ image::whats-new/images/8.15/timeline-ui-renderer.png[Example Timeline with the [role="screenshot"] image::whats-new/images/8.15/timeline-notes-flyout.png[Example Timeline with the notes flyout highlighted] -[float] +[discrete] == Response actions enhancements -[float] +[discrete] === Scan files and folders for malware {elastic-defend}'s new {security-guide}/response-actions.html#_scan[`scan` response action] lets you perform on-demand malware scans of a specific file or directory on a host. Scans are based on the malware protection settings configured in your {elastic-defend} integration policy. -[float] +[discrete] === Isolate and release CrowdStrike-enrolled hosts Using Elastic's CrowdStrike integration and connector, you can now perform {security-guide}/third-party-actions.html#crowdstrike-response-actions[response actions] on hosts enrolled in CrowdStrike's endpoint protection system. These actions are available in this release: @@ -120,12 +120,12 @@ Using Elastic's CrowdStrike integration and connector, you can now perform {secu * Isolate a host from the network * Release an isolated host -[float] +[discrete] === Retrieve files from SentinelOne-enrolled hosts Using Elastic's SentinelOne integration and connector, you can now {security-guide}/third-party-actions.html#sentinelone-response-actions[retrieve files] from SentinelOne-enrolled hosts and download them through {elastic-sec}. -[float] +[discrete] == Filter out process descendants Create an {security-guide}/event-filters.html[event filter] that excludes the descendant events of a specific process, but still includes the primary process itself. This can help you limit the amount of events ingested into {elastic-sec}. @@ -133,10 +133,10 @@ Create an {security-guide}/event-filters.html[event filter] that excludes the de [role="screenshot"] image::whats-new/images/8.15/event-filter-process-descendants.png[Add event filter flyout, 70%] -[float] +[discrete] == Cases enhancements -[float] +[discrete] === Introducing case templates preview:[] {kib} cases offer a new powerful capability to enhance your analyst teams' efficiency with {security-guide}/cases-manage-settings.html#cases-templates[templates]. You can manage multiple templates, each of which can be used to auto-populate values in a case with pre-defined knowledge. This streamlines the investigative process and significantly reduces resolution time. @@ -144,7 +144,7 @@ preview:[] {kib} cases offer a new powerful capability to enhance your analyst t [role="screenshot"] image::whats-new/images/8.15/cases-add-template.png[Add a template in case settings, 80%] -[float] +[discrete] === Case custom fields generally available In 8.11, {security-guide}/cases-manage-settings.html#cases-ui-custom-fields[custom fields] were added to cases, and they are now moving from technical preview to general availability. You can set custom field values in your templates to enhance consistency across cases. From 7fb3f636095ed11d982f8a0fb3cf0ee858f41f18 Mon Sep 17 00:00:00 2001 From: Colleen McGinnis Date: Tue, 29 Oct 2024 16:21:18 -0500 Subject: [PATCH 02/14] clean up landing page --- docs/serverless/index.asciidoc | 189 ------------------ .../what-is-security-serverless.asciidoc | 72 ++----- 2 files changed, 13 insertions(+), 248 deletions(-) delete mode 100644 docs/serverless/index.asciidoc diff --git a/docs/serverless/index.asciidoc b/docs/serverless/index.asciidoc deleted file mode 100644 index c0e5f67d08..0000000000 --- a/docs/serverless/index.asciidoc +++ /dev/null @@ -1,189 +0,0 @@ -:doctype: book - -include::{docs-root}/shared/versions/stack/{source_branch}.asciidoc[] -include::{docs-root}/shared/attributes.asciidoc[] - -= Elastic Security - -include::./security-overview.asciidoc[leveloffset=+1] - -include::./billing.asciidoc[leveloffset=+1] - -include::./projects-create/create-project.asciidoc[leveloffset=+1] - -include::./sec-requirements.asciidoc[leveloffset=+1] - -include::./security-ui.asciidoc[leveloffset=+1] - -include::./AI-for-security/ai-for-security-landing-pg.asciidoc[leveloffset=+1] -include::./AI-for-security/ai-assistant.asciidoc[leveloffset=+2] -include::./AI-for-security/attack-discovery.asciidoc[leveloffset=+2] -include::./AI-for-security/llm-connector-guides.asciidoc[leveloffset=+2] -include::./AI-for-security/llm-performance-matrix.asciidoc[leveloffset=+3] -include::./AI-for-security/connect-to-azure-openai.asciidoc[leveloffset=+3] -include::./AI-for-security/connect-to-bedrock.asciidoc[leveloffset=+3] -include::./AI-for-security/connect-to-openai.asciidoc[leveloffset=+3] -include::./AI-for-security/connect-to-vertex.asciidoc[leveloffset=+3] -include::./AI-for-security/connect-to-byo-llm.asciidoc[leveloffset=+3] -include::./AI-for-security/ai-use-cases.asciidoc[leveloffset=+2] -include::./AI-for-security/usecase-attack-disc-ai-assistant-incident-reporting.asciidoc[leveloffset=+3] -include::./AI-for-security/ai-assistant-alert-triage.asciidoc[leveloffset=+3] -include::./AI-for-security/ai-assistant-esql-queries.asciidoc[leveloffset=+3] - -include::./ingest/ingest-data.asciidoc[leveloffset=+1] -include::./ingest/threat-intelligence.asciidoc[leveloffset=+2] -include::./ingest/auto-import.asciidoc[leveloffset=+2] - -include::./edr-install-config/endpoint-protection-intro.asciidoc[leveloffset=+1] -include::./edr-install-config/deploy-endpoint-reqs.asciidoc[leveloffset=+2] -include::./edr-install-config/install-elastic-defend.asciidoc[leveloffset=+2] -include::./edr-install-config/deploy-endpoint-macos-cat-mont.asciidoc[leveloffset=+3] -include::./edr-install-config/deploy-endpoint-macos-ven.asciidoc[leveloffset=+3] -include::./edr-install-config/deploy-with-mdm.asciidoc[leveloffset=+3] -include::./edr-install-config/agent-tamper-protection.asciidoc[leveloffset=+3] -include::./edr-install-config/defend-feature-privs.asciidoc[leveloffset=+2] -include::./edr-install-config/configure-endpoint-integration-policy.asciidoc[leveloffset=+2] -include::./edr-install-config/artifact-control.asciidoc[leveloffset=+3] -include::./edr-install-config/endpoint-diagnostic-data.asciidoc[leveloffset=+3] -include::./edr-install-config/self-healing-rollback.asciidoc[leveloffset=+3] -include::./edr-install-config/linux-file-monitoring.asciidoc[leveloffset=+3] -include::./edr-install-config/endpoint-data-volume.asciidoc[leveloffset=+3] -include::./edr-install-config/uninstall-agent.asciidoc[leveloffset=+2] - -include::./edr-manage/manage-endpoint-protection.asciidoc[leveloffset=+1] -include::./edr-manage/endpoints-page.asciidoc[leveloffset=+2] -include::./edr-manage/policies-page-ov.asciidoc[leveloffset=+2] -include::./edr-manage/trusted-apps-ov.asciidoc[leveloffset=+2] -include::./edr-manage/event-filters.asciidoc[leveloffset=+2] -include::./edr-manage/host-isolation-exceptions.asciidoc[leveloffset=+2] -include::./edr-manage/blocklist.asciidoc[leveloffset=+2] -include::./edr-manage/optimize-edr.asciidoc[leveloffset=+2] -include::./edr-manage/endpoint-event-capture.asciidoc[leveloffset=+2] -include::./edr-manage/allowlist-endpoint-3rd-party-av.asciidoc[leveloffset=+2] -include::./edr-manage/endpoint-self-protection.asciidoc[leveloffset=+2] -include::./edr-manage/endpoint-command-ref.asciidoc[leveloffset=+2] - -include::./endpoint-response-actions/response-actions.asciidoc[leveloffset=+1] -include::./endpoint-response-actions/automated-response-actions.asciidoc[leveloffset=+2] -include::./endpoint-response-actions/host-isolation-ov.asciidoc[leveloffset=+2] -include::./endpoint-response-actions/response-actions-history.asciidoc[leveloffset=+2] -include::./endpoint-response-actions/third-party-actions.asciidoc[leveloffset=+2] -include::./endpoint-response-actions/response-actions-config.asciidoc[leveloffset=+2] - -include::./cloud-native-security/cloud-native-security-overview.asciidoc[leveloffset=+1] -include::./cloud-native-security/security-posture-management.asciidoc[leveloffset=+2] -include::./cloud-native-security/enable-cloudsec.asciidoc[leveloffset=+2] -include::./cloud-native-security/cspm.asciidoc[leveloffset=+2] -include::./cloud-native-security/cspm-get-started.asciidoc[leveloffset=+3] -include::./cloud-native-security/cspm-get-started-gcp.asciidoc[leveloffset=+3] -include::./cloud-native-security/cspm-get-started-azure.asciidoc[leveloffset=+3] -include::./cloud-native-security/cspm-findings-page.asciidoc[leveloffset=+3] -include::./cloud-native-security/benchmark-rules.asciidoc[leveloffset=+3] -include::./dashboards/cloud-posture-dashboard-dash.asciidoc[leveloffset=+3] -include::./cloud-native-security/cspm-security-posture-faq.asciidoc[leveloffset=+3] -include::./cloud-native-security/kspm.asciidoc[leveloffset=+2] -include::./cloud-native-security/get-started-with-kspm.asciidoc[leveloffset=+3] -// include::./cloud-native-security/cspm-findings-page.asciidoc[leveloffset=+3] -// include::./cloud-native-security/benchmark-rules.asciidoc[leveloffset=+3] -// include::./dashboards/cloud-posture-dashboard-dash.asciidoc[leveloffset=+3] -include::./cloud-native-security/security-posture-faq.asciidoc[leveloffset=+3] -include::./cloud-native-security/vuln-management-overview.asciidoc[leveloffset=+2] -include::./cloud-native-security/vuln-management-get-started.asciidoc[leveloffset=+3] -include::./cloud-native-security/vuln-management-findings.asciidoc[leveloffset=+3] -// include::./dashboards/vuln-management-dashboard-dash.asciidoc[leveloffset=+3] -include::./cloud-native-security/vuln-management-faq.asciidoc[leveloffset=+3] -include::./cloud-native-security/d4c-overview.asciidoc[leveloffset=+2] -include::./cloud-native-security/d4c-get-started.asciidoc[leveloffset=+3] -include::./cloud-native-security/d4c-policy-guide.asciidoc[leveloffset=+3] -// include::./dashboards/kubernetes-dashboard-dash.asciidoc[leveloffset=+3] -include::./cloud-native-security/cloud-workload-protection.asciidoc[leveloffset=+2] -include::./cloud-native-security/environment-variable-capture.asciidoc[leveloffset=+3] - -include::./explore/explore-your-data.asciidoc[leveloffset=+1] -include::./explore/hosts-overview.asciidoc[leveloffset=+2] -include::./explore/network-page-overview.asciidoc[leveloffset=+2] -include::./explore/conf-map-ui.asciidoc[leveloffset=+3] -include::./explore/users-page.asciidoc[leveloffset=+2] -include::./explore/data-views-in-sec.asciidoc[leveloffset=+2] -include::./explore/runtime-fields.asciidoc[leveloffset=+2] -include::./explore/siem-field-reference.asciidoc[leveloffset=+2] - -include::./dashboards/dashboards-overview.asciidoc[leveloffset=+1] -include::./dashboards/overview-dashboard.asciidoc[leveloffset=+2] -include::./dashboards/detection-response-dashboard.asciidoc[leveloffset=+2] -include::./dashboards/kubernetes-dashboard-dash.asciidoc[leveloffset=+2] -// include::./dashboards/cloud-posture-dashboard-dash.asciidoc[leveloffset=+2] -include::./dashboards/detection-entity-dashboard.asciidoc[leveloffset=+2] -include::./dashboards/data-quality-dash.asciidoc[leveloffset=+2] -include::./dashboards/vuln-management-dashboard-dash.asciidoc[leveloffset=+2] -include::./dashboards/rule-monitoring-dashboard.asciidoc[leveloffset=+2] - -include::./rules/detection-engine-overview.asciidoc[leveloffset=+1] -include::./rules/detections-permissions-section.asciidoc[leveloffset=+2] - -include::./rules/about-rules.asciidoc[leveloffset=+1] -include::./rules/rules-ui-create.asciidoc[leveloffset=+2] -include::./rules/interactive-investigation-guides.asciidoc[leveloffset=+3] -include::./rules/building-block-rule.asciidoc[leveloffset=+3] -include::./rules/prebuilt-rules/prebuilt-rules-management.asciidoc[leveloffset=+2] -include::./rules/rules-ui-management.asciidoc[leveloffset=+2] -include::./rules/alerts-ui-monitor.asciidoc[leveloffset=+2] -include::./rules/detections-ui-exceptions.asciidoc[leveloffset=+2] -include::./rules/value-lists-exceptions.asciidoc[leveloffset=+3] -include::./rules/add-exceptions.asciidoc[leveloffset=+3] -include::./rules/shared-exception-lists.asciidoc[leveloffset=+3] -include::./rules/rules-coverage.asciidoc[leveloffset=+2] -include::./rules/tuning-detection-signals.asciidoc[leveloffset=+2] -include::./rules/prebuilt-rules/prebuilt-rules.asciidoc[leveloffset=+2] - -include::./alerts/alerts-ui-manage.asciidoc[leveloffset=+1] -include::./alerts/visualize-alerts.asciidoc[leveloffset=+2] -include::./alerts/view-alert-details.asciidoc[leveloffset=+2] -include::./alerts/signals-to-cases.asciidoc[leveloffset=+2] -include::./alerts/alert-suppression.asciidoc[leveloffset=+2] -include::./alerts/reduce-notifications-alerts.asciidoc[leveloffset=+2] -include::./alerts/query-alert-indices.asciidoc[leveloffset=+2] -include::./alerts/alert-schema.asciidoc[leveloffset=+2] - -include::./advanced-entity-analytics/advanced-entity-analytics-overview.asciidoc[leveloffset=+1] -include::./advanced-entity-analytics/entity-risk-scoring.asciidoc[leveloffset=+2] -include::./advanced-entity-analytics/ers-req.asciidoc[leveloffset=+3] -include::./advanced-entity-analytics/asset-criticality.asciidoc[leveloffset=+3] -include::./advanced-entity-analytics/turn-on-risk-engine.asciidoc[leveloffset=+3] -include::./advanced-entity-analytics/analyze-risk-score-data.asciidoc[leveloffset=+3] -include::./advanced-entity-analytics/advanced-behavioral-detections.asciidoc[leveloffset=+2] -include::./advanced-entity-analytics/ml-requirements.asciidoc[leveloffset=+3] -include::./advanced-entity-analytics/machine-learning.asciidoc[leveloffset=+3] -include::./advanced-entity-analytics/tuning-anomaly-results.asciidoc[leveloffset=+3] -include::./advanced-entity-analytics/behavioral-detection-use-cases.asciidoc[leveloffset=+3] -include::./advanced-entity-analytics/prebuilt-ml-jobs.asciidoc[leveloffset=+3] - -include::./investigate/investigate-events.asciidoc[leveloffset=+1] -include::./investigate/timelines-ui.asciidoc[leveloffset=+2] -include::./investigate/timeline-templates-ui.asciidoc[leveloffset=+3] -include::./investigate/timeline-object-schema.asciidoc[leveloffset=+3] -include::./alerts/visual-event-analyzer.asciidoc[leveloffset=+2] -include::./cloud-native-security/session-view.asciidoc[leveloffset=+2] -include::./osquery/use-osquery.asciidoc[leveloffset=+2] -include::./osquery/osquery-response-action.asciidoc[leveloffset=+3] -include::./osquery/invest-guide-run-osquery.asciidoc[leveloffset=+3] -include::./osquery/alerts-run-osquery.asciidoc[leveloffset=+3] -include::./osquery/view-osquery-results.asciidoc[leveloffset=+3] -include::./osquery/osquery-placeholder-fields.asciidoc[leveloffset=+3] -include::./investigate/indicators-of-compromise.asciidoc[leveloffset=+2] -include::./investigate/cases-overview.asciidoc[leveloffset=+2] -include::./investigate/case-permissions.asciidoc[leveloffset=+3] -include::./investigate/cases-open-manage.asciidoc[leveloffset=+3] -include::./investigate/cases-settings.asciidoc[leveloffset=+3] - -include::./assets/asset-management.asciidoc[leveloffset=+1] - -include::./settings/manage-settings.asciidoc[leveloffset=+1] -include::./settings/project-settings.asciidoc[leveloffset=+2] -include::./settings/advanced-settings.asciidoc[leveloffset=+2] - -include::./troubleshooting/troubleshooting-intro.asciidoc[leveloffset=+1] -include::./troubleshooting/ts-detection-rules.asciidoc[leveloffset=+2] -include::./troubleshooting/troubleshoot-endpoints.asciidoc[leveloffset=+2] - -include::./technical-preview-limitations.asciidoc[leveloffset=+1] diff --git a/docs/serverless/what-is-security-serverless.asciidoc b/docs/serverless/what-is-security-serverless.asciidoc index a4e2bf4797..884f8b349b 100644 --- a/docs/serverless/what-is-security-serverless.asciidoc +++ b/docs/serverless/what-is-security-serverless.asciidoc @@ -1,11 +1,8 @@ -[[what-is-security-serverless]] -= {elastic-sec} - :keywords: serverless, security, overview preview:[] - +{elastic-sec} combines threat detection analytics, cloud native security, and endpoint protection in a single solution, so you can quickly detect, investigate, and respond to threats and vulnerabilities across your environment. Serverless projects provide you with the existing {elastic-sec} on-premise and Elastic Cloud deployment functionality, and the following new features and capabilities: @@ -17,61 +14,18 @@ Serverless projects provide you with the existing {elastic-sec} on-premise and E * Machine learning nodes included, by default * Developer tools for interacting with your data - +[discrete] +== Get started - +* <>: Create your first {serverless-short} Security project. +* <>: Learn how to add your own data to {elastic-sec}. -[[what-is-security-serverless-hello-world]] +[discrete] +== How to +* <>: Activate prebuilt rules from Elastic, and create your own custom rules. +* <>: Install and configure real-time endpoint protection with {elastic-defend}. +* <>: Improve cloud security posture, scan for vulnerabilities, and monitor workloads. +* <>: Analyze potential threats and launch investigations. +* <>: Query security event data and hunt for threats. +* <>: Use prebuilt dashboards and create your own visualizations. From 11b03c613d9f92040d84f4a4e93ec4d917691629 Mon Sep 17 00:00:00 2001 From: Colleen McGinnis Date: Tue, 29 Oct 2024 17:32:53 -0500 Subject: [PATCH 03/14] remove duplicate ids --- .../advanced-behavioral-detections.asciidoc | 2 +- .../advanced-entity-analytics/machine-learning.asciidoc | 2 +- docs/serverless/explore/network-page-overview.asciidoc | 2 +- docs/serverless/investigate/cases-open-manage.asciidoc | 2 +- docs/serverless/rules/about-rules.asciidoc | 2 +- docs/serverless/rules/tuning-detection-signals.asciidoc | 2 +- docs/serverless/settings/advanced-settings.asciidoc | 2 +- docs/serverless/settings/manage-settings.asciidoc | 2 +- docs/serverless/settings/project-settings.asciidoc | 2 +- 9 files changed, 9 insertions(+), 9 deletions(-) diff --git a/docs/serverless/advanced-entity-analytics/advanced-behavioral-detections.asciidoc b/docs/serverless/advanced-entity-analytics/advanced-behavioral-detections.asciidoc index 85d3f033a4..b8feacddca 100644 --- a/docs/serverless/advanced-entity-analytics/advanced-behavioral-detections.asciidoc +++ b/docs/serverless/advanced-entity-analytics/advanced-behavioral-detections.asciidoc @@ -10,5 +10,5 @@ Elastic's {ml} capabilities and advanced correlation, scoring, and visualization Advanced behavioral detections includes two key capabilities: -* <> +* <> * <> diff --git a/docs/serverless/advanced-entity-analytics/machine-learning.asciidoc b/docs/serverless/advanced-entity-analytics/machine-learning.asciidoc index fb2ab27b07..3de7412be6 100644 --- a/docs/serverless/advanced-entity-analytics/machine-learning.asciidoc +++ b/docs/serverless/advanced-entity-analytics/machine-learning.asciidoc @@ -1,4 +1,4 @@ -[[machine-learning]] +[[security-machine-learning]] = Detect anomalies :description: Use the power of machine learning to detect outliers and suspicious events. diff --git a/docs/serverless/explore/network-page-overview.asciidoc b/docs/serverless/explore/network-page-overview.asciidoc index 8f6d5e1e2a..443939698d 100644 --- a/docs/serverless/explore/network-page-overview.asciidoc +++ b/docs/serverless/explore/network-page-overview.asciidoc @@ -59,7 +59,7 @@ The Events table includes inline actions and several customization options. To l * **HTTP**: Received HTTP requests (HTTP requests for applications using {apm-app-ref}/apm-getting-started.html[Elastic APM] are monitored by default). * **TLS**: Handshake details. -* **Anomalies**: Anomalies discovered by <>. +* **Anomalies**: Anomalies discovered by <>. [discrete] [[ip-details-page]] diff --git a/docs/serverless/investigate/cases-open-manage.asciidoc b/docs/serverless/investigate/cases-open-manage.asciidoc index d0eafeb4be..abd0f966ff 100644 --- a/docs/serverless/investigate/cases-open-manage.asciidoc +++ b/docs/serverless/investigate/cases-open-manage.asciidoc @@ -227,7 +227,7 @@ image::images/cases-open-manage/-cases-cases-copy-case-id.png[Copy Case ID optio [[cases-export-import]] == Export and import cases -Cases can be <> and <> as saved objects using the Saved Objects <> UI. +Cases can be <> and <> as saved objects using the Saved Objects <> UI. [IMPORTANT] ==== diff --git a/docs/serverless/rules/about-rules.asciidoc b/docs/serverless/rules/about-rules.asciidoc index 5bc8596309..3e377e48b7 100644 --- a/docs/serverless/rules/about-rules.asciidoc +++ b/docs/serverless/rules/about-rules.asciidoc @@ -21,7 +21,7 @@ You can create the following types of rules: * <>: Query-based rule, which searches the defined indices and creates an alert when one or more documents match the rule's query. * <>: {ml-cap} rule, which creates an alert when a {ml} job -discovers an anomaly above the defined threshold (see <>). +discovers an anomaly above the defined threshold (see <>). + For {ml} rules, the associated {ml} job must be running. If the {ml} job isn't running, the rule will: diff --git a/docs/serverless/rules/tuning-detection-signals.asciidoc b/docs/serverless/rules/tuning-detection-signals.asciidoc index 810124121c..5747497219 100644 --- a/docs/serverless/rules/tuning-detection-signals.asciidoc +++ b/docs/serverless/rules/tuning-detection-signals.asciidoc @@ -199,5 +199,5 @@ tuning to reduce noise from legitimate administrative activities: If your organization is widely distributed and the workforce travels a lot, use the `windows_anomalous_user_name_ecs`, `linux_anomalous_user_name_ecs`, and `suspicious_login_activity_ecs` -<> jobs to detect suspicious authentication activity. +<> jobs to detect suspicious authentication activity. ==== diff --git a/docs/serverless/settings/advanced-settings.asciidoc b/docs/serverless/settings/advanced-settings.asciidoc index eb43624c38..1c15e82c0c 100644 --- a/docs/serverless/settings/advanced-settings.asciidoc +++ b/docs/serverless/settings/advanced-settings.asciidoc @@ -117,7 +117,7 @@ To learn more, refer to our https://www.elastic.co/legal/privacy-statement[Priva [[advanced-settings-set-machine-learning-score-threshold]] == Set machine learning score threshold -When security <> are enabled, this setting +When security <> are enabled, this setting determines the threshold above which anomaly scores appear in {elastic-sec}: * `securitySolution:defaultAnomalyScore` diff --git a/docs/serverless/settings/manage-settings.asciidoc b/docs/serverless/settings/manage-settings.asciidoc index e9fee37b69..6b52cfc82c 100644 --- a/docs/serverless/settings/manage-settings.asciidoc +++ b/docs/serverless/settings/manage-settings.asciidoc @@ -7,6 +7,6 @@ preview:[] These pages explain how to manage settings in various areas of the {security-app}: -* <>: Configure project-wide settings related to users, billing, data management, and more. +* <>: Configure project-wide settings related to users, billing, data management, and more. * <>: Update advanced {elastic-sec} settings. * <>: Learn about requirements for specific features. diff --git a/docs/serverless/settings/project-settings.asciidoc b/docs/serverless/settings/project-settings.asciidoc index 367998476f..e34a4af891 100644 --- a/docs/serverless/settings/project-settings.asciidoc +++ b/docs/serverless/settings/project-settings.asciidoc @@ -1,4 +1,4 @@ -[[project-settings]] +[[security-project-settings]] = Project settings :description: Configure project-wide settings related to users, billing, data management, and more. From fa002a0664447bc50d783c101fc7640c69317006 Mon Sep 17 00:00:00 2001 From: Colleen McGinnis Date: Tue, 29 Oct 2024 19:14:01 -0500 Subject: [PATCH 04/14] clean up links --- .../ai-assistant-alert-triage.asciidoc | 2 +- .../ai-assistant-esql-queries.asciidoc | 2 +- .../AI-for-security/ai-assistant.asciidoc | 20 ++-- .../ai-for-security-landing-pg.asciidoc | 4 +- .../AI-for-security/ai-use-cases.asciidoc | 8 +- .../AI-for-security/attack-discovery.asciidoc | 2 +- .../connect-to-azure-openai.asciidoc | 16 +-- .../connect-to-bedrock.asciidoc | 16 +-- .../connect-to-byo-llm.asciidoc | 20 ++-- .../connect-to-openai.asciidoc | 14 +-- .../connect-to-vertex.asciidoc | 10 +- .../llm-connector-guides.asciidoc | 14 +-- .../llm-performance-matrix.asciidoc | 4 +- ...c-ai-assistant-incident-reporting.asciidoc | 10 +- .../advanced-behavioral-detections.asciidoc | 4 +- ...dvanced-entity-analytics-overview.asciidoc | 6 +- .../analyze-risk-score-data.asciidoc | 32 +++--- .../asset-criticality.asciidoc | 34 +++---- .../behavioral-detection-use-cases.asciidoc | 6 +- .../entity-risk-scoring.asciidoc | 18 ++-- .../ers-req.asciidoc | 14 +-- .../machine-learning.asciidoc | 10 +- .../ml-requirements.asciidoc | 4 +- .../prebuilt-ml-jobs.asciidoc | 2 +- .../tuning-anomaly-results.asciidoc | 2 +- .../turn-on-risk-engine.asciidoc | 8 +- docs/serverless/alerts/alert-schema.asciidoc | 2 +- .../alerts/alert-suppression.asciidoc | 12 +-- .../alerts/alerts-ui-manage.asciidoc | 30 +++--- .../alerts/query-alert-indices.asciidoc | 8 +- .../reduce-notifications-alerts.asciidoc | 10 +- .../alerts/signals-to-cases.asciidoc | 4 +- .../alerts/view-alert-details.asciidoc | 10 +- .../alerts/visual-event-analyzer.asciidoc | 6 +- .../alerts/visualize-alerts.asciidoc | 10 +- .../assets/asset-management.asciidoc | 6 +- docs/serverless/billing.asciidoc | 8 +- .../benchmark-rules.asciidoc | 12 +-- .../cloud-native-security-overview.asciidoc | 22 ++--- .../cloud-workload-protection.asciidoc | 14 +-- .../cspm-findings-page.asciidoc | 8 +- .../cspm-get-started-azure.asciidoc | 2 +- .../cspm-get-started-gcp.asciidoc | 2 +- .../cspm-get-started.asciidoc | 2 +- .../cspm-security-posture-faq.asciidoc | 11 ++- .../cloud-native-security/cspm.asciidoc | 6 +- .../d4c-get-started.asciidoc | 8 +- .../d4c-overview.asciidoc | 14 +-- .../d4c-policy-guide.asciidoc | 12 +-- .../enable-cloudsec.asciidoc | 2 +- .../environment-variable-capture.asciidoc | 2 +- .../get-started-with-kspm.asciidoc | 10 +- .../cloud-native-security/kspm.asciidoc | 12 +-- .../security-posture-faq.asciidoc | 2 +- .../security-posture-management.asciidoc | 6 +- .../session-view.asciidoc | 4 +- .../vuln-management-faq.asciidoc | 2 +- .../vuln-management-findings.asciidoc | 14 +-- .../vuln-management-get-started.asciidoc | 4 +- .../vuln-management-overview.asciidoc | 6 +- .../cloud-posture-dashboard-dash.asciidoc | 6 +- .../dashboards/dashboards-overview.asciidoc | 2 +- .../dashboards/data-quality-dash.asciidoc | 14 +-- .../detection-entity-dashboard.asciidoc | 8 +- .../detection-response-dashboard.asciidoc | 2 +- .../kubernetes-dashboard-dash.asciidoc | 14 +-- .../dashboards/overview-dashboard.asciidoc | 12 +-- .../rule-monitoring-dashboard.asciidoc | 2 +- .../vuln-management-dashboard-dash.asciidoc | 6 +- .../agent-tamper-protection.asciidoc | 4 +- .../artifact-control.asciidoc | 2 +- ...igure-endpoint-integration-policy.asciidoc | 18 ++-- .../defend-feature-privs.asciidoc | 26 ++--- .../deploy-endpoint-macos-cat-mont.asciidoc | 6 +- .../deploy-endpoint-macos-ven.asciidoc | 6 +- .../deploy-endpoint-reqs.asciidoc | 8 +- .../deploy-with-mdm.asciidoc | 20 ++-- .../endpoint-data-volume.asciidoc | 2 +- .../endpoint-diagnostic-data.asciidoc | 2 +- .../endpoint-protection-intro.asciidoc | 2 +- .../install-elastic-defend.asciidoc | 12 +-- .../linux-file-monitoring.asciidoc | 2 +- .../self-healing-rollback.asciidoc | 2 +- .../uninstall-agent.asciidoc | 4 +- .../allowlist-endpoint-3rd-party-av.asciidoc | 10 +- docs/serverless/edr-manage/blocklist.asciidoc | 4 +- .../edr-manage/endpoint-command-ref.asciidoc | 98 +++++++++---------- .../endpoint-event-capture.asciidoc | 14 +-- .../endpoint-self-protection.asciidoc | 2 +- .../edr-manage/endpoints-page.asciidoc | 16 +-- .../edr-manage/event-filters.asciidoc | 4 +- .../host-isolation-exceptions.asciidoc | 4 +- .../manage-endpoint-protection.asciidoc | 2 +- .../edr-manage/optimize-edr.asciidoc | 8 +- .../edr-manage/policies-page-ov.asciidoc | 4 +- .../edr-manage/trusted-apps-ov.asciidoc | 8 +- .../automated-response-actions.asciidoc | 6 +- .../host-isolation-ov.asciidoc | 6 +- .../response-actions-config.asciidoc | 8 +- .../response-actions-history.asciidoc | 4 +- .../response-actions.asciidoc | 34 +++---- .../third-party-actions.asciidoc | 10 +- docs/serverless/explore/conf-map-ui.asciidoc | 4 +- .../explore/data-views-in-sec.asciidoc | 8 +- .../explore/explore-your-data.asciidoc | 12 +-- .../explore/hosts-overview.asciidoc | 30 +++--- .../explore/network-page-overview.asciidoc | 6 +- .../explore/runtime-fields.asciidoc | 4 +- .../explore/siem-field-reference.asciidoc | 16 +-- docs/serverless/explore/users-page.asciidoc | 34 +++---- docs/serverless/ingest/auto-import.asciidoc | 10 +- docs/serverless/ingest/ingest-data.asciidoc | 10 +- .../ingest/threat-intelligence.asciidoc | 6 +- .../investigate/case-permissions.asciidoc | 2 +- .../investigate/cases-open-manage.asciidoc | 16 +-- .../investigate/cases-overview.asciidoc | 4 +- .../investigate/cases-settings.asciidoc | 14 +-- .../indicators-of-compromise.asciidoc | 10 +- .../investigate/investigate-events.asciidoc | 10 +- .../timeline-object-schema.asciidoc | 44 ++++----- .../timeline-templates-ui.asciidoc | 4 +- .../investigate/timelines-ui.asciidoc | 16 +-- .../osquery/alerts-run-osquery.asciidoc | 6 +- .../osquery/invest-guide-run-osquery.asciidoc | 6 +- .../osquery-placeholder-fields.asciidoc | 8 +- .../osquery/osquery-response-action.asciidoc | 6 +- docs/serverless/osquery/use-osquery.asciidoc | 8 +- .../osquery/view-osquery-results.asciidoc | 2 +- .../projects-create/create-project.asciidoc | 4 +- docs/serverless/rules/about-rules.asciidoc | 6 +- docs/serverless/rules/add-exceptions.asciidoc | 12 +-- .../rules/alerts-ui-monitor.asciidoc | 8 +- .../rules/building-block-rule.asciidoc | 6 +- .../rules/detection-engine-overview.asciidoc | 20 ++-- .../detections-permissions-section.asciidoc | 14 +-- .../rules/detections-ui-exceptions.asciidoc | 8 +- .../interactive-investigation-guides.asciidoc | 12 +-- .../prebuilt-rules-management.asciidoc | 6 +- .../prebuilt-rules/prebuilt-rules.asciidoc | 2 +- docs/serverless/rules/rules-coverage.asciidoc | 10 +- .../serverless/rules/rules-ui-create.asciidoc | 40 ++++---- .../rules/rules-ui-management.asciidoc | 12 +-- .../rules/shared-exception-lists.asciidoc | 4 +- .../rules/tuning-detection-signals.asciidoc | 8 +- .../rules/value-lists-exceptions.asciidoc | 4 +- docs/serverless/sec-requirements.asciidoc | 30 +++--- docs/serverless/security-overview.asciidoc | 12 +-- docs/serverless/security-ui.asciidoc | 46 ++++----- .../settings/advanced-settings.asciidoc | 22 ++--- .../settings/manage-settings.asciidoc | 6 +- .../troubleshoot-endpoints.asciidoc | 30 +++--- .../troubleshooting-intro.asciidoc | 6 +- .../ts-detection-rules.asciidoc | 4 +- .../what-is-security-serverless.asciidoc | 16 +-- 154 files changed, 817 insertions(+), 816 deletions(-) diff --git a/docs/serverless/AI-for-security/ai-assistant-alert-triage.asciidoc b/docs/serverless/AI-for-security/ai-assistant-alert-triage.asciidoc index 1b725a6a41..b1e92f3b71 100644 --- a/docs/serverless/AI-for-security/ai-assistant-alert-triage.asciidoc +++ b/docs/serverless/AI-for-security/ai-assistant-alert-triage.asciidoc @@ -1,4 +1,4 @@ -[[triage-alerts-with-elastic-ai-assistant]] +[[security-triage-alerts-with-elastic-ai-assistant]] = Triage alerts :description: Elastic AI Assistant can help you enhance and streamline your alert triage workflows. diff --git a/docs/serverless/AI-for-security/ai-assistant-esql-queries.asciidoc b/docs/serverless/AI-for-security/ai-assistant-esql-queries.asciidoc index 590077db2e..b0ec85cbc8 100644 --- a/docs/serverless/AI-for-security/ai-assistant-esql-queries.asciidoc +++ b/docs/serverless/AI-for-security/ai-assistant-esql-queries.asciidoc @@ -1,4 +1,4 @@ -[[ai-assistant-esql-queries]] +[[security-ai-assistant-esql-queries]] = Generate, customize, and learn about {esql} queries :description: AI Assistant has specialized {esql} capabilities. diff --git a/docs/serverless/AI-for-security/ai-assistant.asciidoc b/docs/serverless/AI-for-security/ai-assistant.asciidoc index dc6e46b3a3..db73fbebe0 100644 --- a/docs/serverless/AI-for-security/ai-assistant.asciidoc +++ b/docs/serverless/AI-for-security/ai-assistant.asciidoc @@ -40,12 +40,12 @@ Elastic can automatically anonymize event data that you provide to AI Assistant [[set-up-ai-assistant]] == Set up AI Assistant -You must create a generative AI connector before you can use AI Assistant. AI Assistant can connect to multiple large language model (LLM) providers so you can select the best model for your needs. To set up a connector, refer to <>. +You must create a generative AI connector before you can use AI Assistant. AI Assistant can connect to multiple large language model (LLM) providers so you can select the best model for your needs. To set up a connector, refer to <>. .Recommended models [NOTE] ==== -While AI Assistant is compatible with many different models, refer to the <> to select models that perform well with your desired use cases. +While AI Assistant is compatible with many different models, refer to the <> to select models that perform well with your desired use cases. ==== [discrete] @@ -61,10 +61,10 @@ This opens the **Welcome** chat interface, where you can ask general questions a You can also chat with AI Assistant from several particular pages in {elastic-sec} where you can easily send context-specific data and prompts to AI Assistant. -* <> or Event details flyout: Click **Chat** while viewing the details of an alert or event. -* <>: Use AI Assistant to help create or correct rule queries. -* <>: Select the **Incompatible fields** tab, then click **Chat**. (This is only available for fields marked red, indicating they’re incompatible). -* <>: Select the **Security Assistant** tab. +* <> or Event details flyout: Click **Chat** while viewing the details of an alert or event. +* <>: Use AI Assistant to help create or correct rule queries. +* <>: Select the **Incompatible fields** tab, then click **Chat**. (This is only available for fields marked red, indicating they’re incompatible). +* <>: Select the **Security Assistant** tab. [NOTE] ==== @@ -144,10 +144,10 @@ When you include a particular event as context, such as an alert from the Alerts beta::[] -The **Knowledge base** tab of the AI Assistant settings menu allows you to enable AI Assistant to answer questions about the Elastic Search Query Language {(esql}), and about alerts in your environment. To use it, you must <>, +The **Knowledge base** tab of the AI Assistant settings menu allows you to enable AI Assistant to answer questions about the Elastic Search Query Language ({esql}), and about alerts in your environment. To use it, you must <>, [discrete] -[[ai-assistant-knowledge-base-for-esql]] +[[security-ai-assistant-knowledge-base-for-esql]] === Knowledge base for {esql} [IMPORTANT] @@ -166,7 +166,7 @@ AI Assistant's knowledge base gets additional context from {ml-docs}/ml-nlp-else ==== [discrete] -[[ai-assistant-knowledge-base-for-alerts]] +[[security-ai-assistant-knowledge-base-for-alerts]] === Knowledge base for alerts When this feature is enabled, AI Assistant will receive multiple alerts as context for each of your prompts. It will receive alerts from the last 24 hours that have a status of `open` or `acknowledged`, ordered first by risk score, then by recency. Building block alerts are excluded. This enables it to answer questions about multiple alerts in your environment, rather than just the individual alerts you choose to include as context. @@ -185,7 +185,7 @@ Including a large number of alerts may cause your request to exceed the maximum ==== [discrete] -[[ai-assistant-get-the-most-from-your-queries]] +[[security-ai-assistant-get-the-most-from-your-queries]] === Get the most from your queries Elastic AI Assistant helps you take full advantage of the Elastic Security platform to improve your security operations. Its ability to assist you depends on the specificity and detail of your questions. The more context and detail you provide, the more tailored and useful its responses will be. diff --git a/docs/serverless/AI-for-security/ai-for-security-landing-pg.asciidoc b/docs/serverless/AI-for-security/ai-for-security-landing-pg.asciidoc index 7314fa4963..1e633e86e9 100644 --- a/docs/serverless/AI-for-security/ai-for-security-landing-pg.asciidoc +++ b/docs/serverless/AI-for-security/ai-for-security-landing-pg.asciidoc @@ -1,7 +1,7 @@ -[[ai-for-security]] +[[security-ai-for-security]] = AI for security :description: Learn about Elastic's native AI security tools. :keywords: serverless, security, overview, LLM, artificial intelligence -You can use {elastic-sec}’s built-in AI tools to speed up your work and augment your team’s capabilities. The pages in this section describe <>, which answers questions and enhances your workflows throughout Elastic Security, and <>, which speeds up the triage process by finding patterns and identifying attacks spanning multiple alerts. +You can use {elastic-sec}’s built-in AI tools to speed up your work and augment your team’s capabilities. The pages in this section describe <>, which answers questions and enhances your workflows throughout Elastic Security, and <>, which speeds up the triage process by finding patterns and identifying attacks spanning multiple alerts. diff --git a/docs/serverless/AI-for-security/ai-use-cases.asciidoc b/docs/serverless/AI-for-security/ai-use-cases.asciidoc index 6fbefc8657..dde55c8c0b 100644 --- a/docs/serverless/AI-for-security/ai-use-cases.asciidoc +++ b/docs/serverless/AI-for-security/ai-use-cases.asciidoc @@ -1,4 +1,4 @@ -[[ai-use-cases]] +[[security-ai-use-cases]] = Use cases :description: Learn about use cases for AI in {elastic-sec}. @@ -6,6 +6,6 @@ The guides in this section describe use cases for AI Assistant and Attack discovery. Refer to them for examples of each tool's individual capabilities, and of what they can do together. -* <> -* <> -* <> +* <> +* <> +* <> diff --git a/docs/serverless/AI-for-security/attack-discovery.asciidoc b/docs/serverless/AI-for-security/attack-discovery.asciidoc index cb79289be1..e07afb28a5 100644 --- a/docs/serverless/AI-for-security/attack-discovery.asciidoc +++ b/docs/serverless/AI-for-security/attack-discovery.asciidoc @@ -1,4 +1,4 @@ -[[attack-discovery]] +[[security-attack-discovery]] = Attack discovery :description: Accelerate threat identification by triaging alerts with a large language model. diff --git a/docs/serverless/AI-for-security/connect-to-azure-openai.asciidoc b/docs/serverless/AI-for-security/connect-to-azure-openai.asciidoc index 45703c60d1..ab94776e5d 100644 --- a/docs/serverless/AI-for-security/connect-to-azure-openai.asciidoc +++ b/docs/serverless/AI-for-security/connect-to-azure-openai.asciidoc @@ -1,21 +1,21 @@ -[[connect-to-azure-openai]] +[[security-connect-to-azure-openai]] = Connect to Azure OpenAI :description: Set up an Azure OpenAI LLM connector. :keywords: security, overview, get-started [discrete] -[[connect-to-azure-openai-connect-to-azure-openai]] +[[security-connect-to-azure-openai-connect-to-azure-openai]] = Connect to Azure OpenAI This page provides step-by-step instructions for setting up an Azure OpenAI connector for the first time. This connector type enables you to leverage large language models (LLMs) within {kib}. You'll first need to configure Azure, then configure the connector in {kib}. [discrete] -[[connect-to-azure-openai-configure-azure]] +[[security-connect-to-azure-openai-configure-azure]] == Configure Azure [discrete] -[[connect-to-azure-openai-configure-a-deployment]] +[[security-connect-to-azure-openai-configure-a-deployment]] === Configure a deployment First, set up an Azure OpenAI deployment: @@ -40,7 +40,7 @@ The following video demonstrates these steps. ++++ [discrete] -[[connect-to-azure-openai-configure-keys]] +[[security-connect-to-azure-openai-configure-keys]] === Configure keys Next, create access keys for the deployment: @@ -60,7 +60,7 @@ The following video demonstrates these steps. ++++ [discrete] -[[connect-to-azure-openai-configure-a-model]] +[[security-connect-to-azure-openai-configure-a-model]] === Configure a model Now, set up the Azure OpenAI model: @@ -76,7 +76,7 @@ Now, set up the Azure OpenAI model: [IMPORTANT] ==== -The models available to you will depend on https://learn.microsoft.com/en-us/azure/ai-services/openai/concepts/models#model-summary-table-and-region-availability[region availability]. For best results, use `GPT-4o 2024-05-13` with the maximum Tokens-Per-Minute (TPM) capacity. For more information on how different models perform for different tasks, refer to the <>. +The models available to you will depend on https://learn.microsoft.com/en-us/azure/ai-services/openai/concepts/models#model-summary-table-and-region-availability[region availability]. For best results, use `GPT-4o 2024-05-13` with the maximum Tokens-Per-Minute (TPM) capacity. For more information on how different models perform for different tasks, refer to the <>. ==== The following video demonstrates these steps. @@ -91,7 +91,7 @@ The following video demonstrates these steps. ++++ [discrete] -[[connect-to-azure-openai-configure-elastic-ai-assistant]] +[[security-connect-to-azure-openai-configure-elastic-ai-assistant]] == Configure Elastic AI Assistant Finally, configure the connector in {kib}: diff --git a/docs/serverless/AI-for-security/connect-to-bedrock.asciidoc b/docs/serverless/AI-for-security/connect-to-bedrock.asciidoc index 54cc72207f..3072cbbaac 100644 --- a/docs/serverless/AI-for-security/connect-to-bedrock.asciidoc +++ b/docs/serverless/AI-for-security/connect-to-bedrock.asciidoc @@ -1,11 +1,11 @@ -[[connect-to-bedrock]] +[[security-connect-to-bedrock]] = Connect to Amazon Bedrock :description: Set up an Amazon Bedrock LLM connector. :keywords: security, overview, get-started [discrete] -[[connect-to-bedrock-connect-to-amazon-bedrock]] +[[security-connect-to-bedrock-connect-to-amazon-bedrock]] = Connect to Amazon Bedrock This page provides step-by-step instructions for setting up an Amazon Bedrock connector for the first time. This connector type enables you to leverage large language models (LLMs) within {kib}. You'll first need to configure AWS, then configure the connector in {kib}. @@ -16,11 +16,11 @@ Only Amazon Bedrock's `Anthropic` models are supported: `Claude` and `Claude ins ==== [discrete] -[[connect-to-bedrock-configure-aws]] +[[security-connect-to-bedrock-configure-aws]] == Configure AWS [discrete] -[[connect-to-bedrock-configure-an-iam-policy]] +[[security-connect-to-bedrock-configure-an-iam-policy]] === Configure an IAM policy First, configure an IAM policy with the necessary permissions: @@ -66,7 +66,7 @@ The following video demonstrates these steps. ++++ [discrete] -[[connect-to-bedrock-configure-an-iam-user]] +[[security-connect-to-bedrock-configure-an-iam-user]] === Configure an IAM User Next, assign the policy you just created to a new user: @@ -89,7 +89,7 @@ The following video demonstrates these steps. ++++ [discrete] -[[connect-to-bedrock-create-an-access-key]] +[[security-connect-to-bedrock-create-an-access-key]] === Create an access key Create the access keys that will authenticate your Elastic connector: @@ -113,7 +113,7 @@ The following video demonstrates these steps. ++++ [discrete] -[[connect-to-bedrock-enable-model-access]] +[[security-connect-to-bedrock-enable-model-access]] === Enable model access Make sure the supported Amazon Bedrock LLMs are enabled: @@ -136,7 +136,7 @@ The following video demonstrates these steps. ++++ [discrete] -[[connect-to-bedrock-configure-the-amazon-bedrock-connector]] +[[security-connect-to-bedrock-configure-the-amazon-bedrock-connector]] == Configure the Amazon Bedrock connector Finally, configure the connector in {kib}: diff --git a/docs/serverless/AI-for-security/connect-to-byo-llm.asciidoc b/docs/serverless/AI-for-security/connect-to-byo-llm.asciidoc index 86faa9c137..ca31fee9bf 100644 --- a/docs/serverless/AI-for-security/connect-to-byo-llm.asciidoc +++ b/docs/serverless/AI-for-security/connect-to-byo-llm.asciidoc @@ -1,4 +1,4 @@ -[[connect-to-byo-llm]] +[[security-connect-to-byo-llm]] = Connect to your own local LLM :description: Set up a connector to LM Studio so you can use a local model with AI Assistant. @@ -20,7 +20,7 @@ For testing, you can use alternatives to Nginx such as https://learn.microsoft.c ==== [discrete] -[[connect-to-byo-llm-configure-your-reverse-proxy]] +[[security-connect-to-byo-llm-configure-your-reverse-proxy]] == Configure your reverse proxy [NOTE] @@ -88,13 +88,13 @@ server { ==== [discrete] -[[connect-to-byo-llm-optional-set-up-performance-monitoring-for-your-reverse-proxy]] +[[security-connect-to-byo-llm-optional-set-up-performance-monitoring-for-your-reverse-proxy]] === (Optional) Set up performance monitoring for your reverse proxy You can use Elastic's https://www.elastic.co/docs/current/integrations/nginx[Nginx integration] to monitor performance and populate monitoring dashboards in the {security-app}. [discrete] -[[connect-to-byo-llm-configure-lm-studio-and-download-a-model]] +[[security-connect-to-byo-llm-configure-lm-studio-and-download-a-model]] == Configure LM Studio and download a model First, install https://lmstudio.ai/[LM Studio]. LM Studio supports the OpenAI SDK, which makes it compatible with Elastic's OpenAI connector, allowing you to connect to any model available in the LM Studio marketplace. @@ -137,13 +137,13 @@ In this example we used https://huggingface.co/TheBloke/Mixtral-8x7B-Instruct-v0 |=== [discrete] -[[connect-to-byo-llm-load-a-model-in-lm-studio]] +[[security-connect-to-byo-llm-load-a-model-in-lm-studio]] == Load a model in LM Studio After downloading a model, load it in LM Studio using the GUI or LM Studio's https://lmstudio.ai/blog/lms[CLI tool]. [discrete] -[[connect-to-byo-llm-option-1-load-a-model-using-the-cli-recommended]] +[[security-connect-to-byo-llm-option-1-load-a-model-using-the-cli-recommended]] === Option 1: load a model using the CLI (Recommended) It is a best practice to download models from the marketplace using the GUI, and then load or unload them using the CLI. The GUI allows you to search for models, whereas the CLI only allows you to import specific paths, but the CLI provides a good interface for loading and unloading. @@ -171,7 +171,7 @@ image::images/lms-ps-command.png[The CLI message that appears after running lms If your model uses NVIDIA drivers, you can check the GPU performance with the `sudo nvidia-smi` command. [discrete] -[[connect-to-byo-llm-option-2-load-a-model-using-the-gui]] +[[security-connect-to-byo-llm-option-2-load-a-model-using-the-gui]] === Option 2: load a model using the GUI Refer to the following video to see how to load a model using LM Studio's GUI. You can change the **port** setting, which is referenced in the Nginx configuration file. Note that the **GPU offload** was set to **Max**. @@ -189,7 +189,7 @@ Refer to the following video to see how to load a model using LM Studio's GUI. Y ++++ [discrete] -[[connect-to-byo-llm-optional-collect-logs-using-elastics-custom-logs-integration]] +[[security-connect-to-byo-llm-optional-collect-logs-using-elastics-custom-logs-integration]] == (Optional) Collect logs using Elastic's Custom Logs integration You can monitor the performance of the host running LM Studio using Elastic's https://www.elastic.co/docs/current/integrations/log[Custom Logs integration]. This can also help with troubleshooting. Note that the default path for LM Studio logs is `/tmp/lmstudio-server-log.txt`, as in the following screenshot: @@ -198,7 +198,7 @@ You can monitor the performance of the host running LM Studio using Elastic's ht image::images/lms-custom-logs-config.png[The configuration window for the custom logs integration] [discrete] -[[connect-to-byo-llm-configure-the-connector-in-elastic-sec]] +[[security-connect-to-byo-llm-configure-the-connector-in-elastic-sec]] == Configure the connector in {elastic-sec} Finally, configure the connector in your Security project: @@ -219,5 +219,5 @@ Setup is now complete. You can use the model you've loaded in LM Studio to power [NOTE] ==== -While local models work well for <>, we recommend you use one of <> for interacting with <>. As local models become more performant over time, this is likely to change. +While local models work well for <>, we recommend you use one of <> for interacting with <>. As local models become more performant over time, this is likely to change. ==== diff --git a/docs/serverless/AI-for-security/connect-to-openai.asciidoc b/docs/serverless/AI-for-security/connect-to-openai.asciidoc index 704502951d..83559b3944 100644 --- a/docs/serverless/AI-for-security/connect-to-openai.asciidoc +++ b/docs/serverless/AI-for-security/connect-to-openai.asciidoc @@ -1,32 +1,32 @@ -[[connect-to-openai]] +[[security-connect-to-openai]] = Connect to OpenAI :description: Set up an OpenAI LLM connector. :keywords: security, overview, get-started [discrete] -[[connect-to-openai-connect-to-openai]] +[[security-connect-to-openai-connect-to-openai]] = Connect to OpenAI This page provides step-by-step instructions for setting up an OpenAI connector for the first time. This connector type enables you to leverage OpenAI's large language models (LLMs) within {kib}. You'll first need to create an OpenAI API key, then configure the connector in {kib}. [discrete] -[[connect-to-openai-configure-openai]] +[[security-connect-to-openai-configure-openai]] == Configure OpenAI [discrete] -[[connect-to-openai-select-a-model]] +[[security-connect-to-openai-select-a-model]] === Select a model Before creating an API key, you must choose a model. Refer to the https://platform.openai.com/docs/models/gpt-4-turbo-and-gpt-4[OpenAI docs] to select a model. Take note of the specific model name (for example `gpt-4-turbo`); you'll need it when configuring {kib}. [NOTE] ==== -`GPT-4o` offers increased performance over previous versions. For more information on how different models perform for different tasks, refer to the <>. +`GPT-4o` offers increased performance over previous versions. For more information on how different models perform for different tasks, refer to the <>. ==== [discrete] -[[connect-to-openai-create-an-api-key]] +[[security-connect-to-openai-create-an-api-key]] === Create an API key To generate an API key: @@ -48,7 +48,7 @@ The following video demonstrates these steps. ++++ [discrete] -[[connect-to-openai-configure-the-openai-connector]] +[[security-connect-to-openai-configure-the-openai-connector]] == Configure the OpenAI connector Finally, configure the connector in {kib}: diff --git a/docs/serverless/AI-for-security/connect-to-vertex.asciidoc b/docs/serverless/AI-for-security/connect-to-vertex.asciidoc index 72dc06a7d2..5e82611c16 100644 --- a/docs/serverless/AI-for-security/connect-to-vertex.asciidoc +++ b/docs/serverless/AI-for-security/connect-to-vertex.asciidoc @@ -1,4 +1,4 @@ -[[connect-to-google-vertex]] +[[security-connect-to-google-vertex]] = Connect to Google Vertex AI :description: Set up a Google Vertex LLM connector. @@ -12,7 +12,7 @@ Before continuing, you should have an active project in one of Google Vertex AI' ==== [discrete] -[[connect-to-google-vertex-enable-the-vertex-ai-api]] +[[security-connect-to-google-vertex-enable-the-vertex-ai-api]] == Enable the Vertex AI API . Log in to the GCP console and navigate to **Vertex AI → Vertex AI Studio → Overview**. @@ -38,7 +38,7 @@ For more information about enabling the Vertex AI API, refer to https://cloud.go ==== [discrete] -[[connect-to-google-vertex-create-a-vertex-ai-service-account]] +[[security-connect-to-google-vertex-create-a-vertex-ai-service-account]] == Create a Vertex AI service account . In the GCP console, navigate to **APIs & Services → Library**. @@ -63,7 +63,7 @@ The following video demonstrates these steps. ++++ [discrete] -[[connect-to-google-vertex-generate-an-api-key]] +[[security-connect-to-google-vertex-generate-an-api-key]] == Generate an API key . Return to Vertex AI's **Credentials** menu and click **Manage service accounts**. @@ -86,7 +86,7 @@ The following video demonstrates these steps. ++++ [discrete] -[[connect-to-google-vertex-configure-the-google-gemini-connector]] +[[security-connect-to-google-vertex-configure-the-google-gemini-connector]] == Configure the Google Gemini connector Finally, configure the connector in {kib}: diff --git a/docs/serverless/AI-for-security/llm-connector-guides.asciidoc b/docs/serverless/AI-for-security/llm-connector-guides.asciidoc index 9a4fc5eacb..25759defcc 100644 --- a/docs/serverless/AI-for-security/llm-connector-guides.asciidoc +++ b/docs/serverless/AI-for-security/llm-connector-guides.asciidoc @@ -1,15 +1,15 @@ -[[llm-connector-guides]] +[[security-llm-connector-guides]] = LLM connector guides :description: Set up LLM connectors to enable AI features in {elastic-sec} :keywords: security, overview, get-started -This section contains instructions for setting up connectors for LLMs so you can use <> and <>. +This section contains instructions for setting up connectors for LLMs so you can use <> and <>. Setup guides are available for the following LLM providers: -* <> -* <> -* <> -* <> -* <> +* <> +* <> +* <> +* <> +* <> diff --git a/docs/serverless/AI-for-security/llm-performance-matrix.asciidoc b/docs/serverless/AI-for-security/llm-performance-matrix.asciidoc index eb1058db5b..b6f4881de7 100644 --- a/docs/serverless/AI-for-security/llm-performance-matrix.asciidoc +++ b/docs/serverless/AI-for-security/llm-performance-matrix.asciidoc @@ -1,10 +1,10 @@ -[[llm-performance-matrix]] +[[security-llm-performance-matrix]] = Large language model performance matrix :description: Learn how different models perform on different tasks in {elastic-sec}. :keywords: security, overview, get-started -This table describes the performance of various large language models (LLMs) for different use cases in {elastic-sec}, based on our internal testing. To learn more about these use cases, refer to <> or <>. +This table describes the performance of various large language models (LLMs) for different use cases in {elastic-sec}, based on our internal testing. To learn more about these use cases, refer to <> or <>. |=== | **Feature**| **Model**| | | | | | diff --git a/docs/serverless/AI-for-security/usecase-attack-disc-ai-assistant-incident-reporting.asciidoc b/docs/serverless/AI-for-security/usecase-attack-disc-ai-assistant-incident-reporting.asciidoc index 488967cca3..a02c828988 100644 --- a/docs/serverless/AI-for-security/usecase-attack-disc-ai-assistant-incident-reporting.asciidoc +++ b/docs/serverless/AI-for-security/usecase-attack-disc-ai-assistant-incident-reporting.asciidoc @@ -1,10 +1,10 @@ -[[ai-usecase-incident-reporting]] +[[security-ai-usecase-incident-reporting]] = Identify, investigate, and document threats :description: Use Attack discovery and AI Assistant to manage threats. :keywords: security, overview, get-started -Together, <> and <> can help you identify and mitigate threats, investigate incidents, and generate incident reports in various languages so you can monitor and protect your environment. +Together, <> and <> can help you identify and mitigate threats, investigate incidents, and generate incident reports in various languages so you can monitor and protect your environment. In this guide, you'll learn how to: @@ -17,7 +17,7 @@ In this guide, you'll learn how to: [[use-case-incident-reporting-use-attack-discovery-to-identify-threats]] == Use Attack discovery to identify threats -Attack discovery can detect a wide range of threats by finding relationships among alerts that may indicate a coordinated attack. This enables you to comprehend how threats move through and affect your systems. Attack discovery generates a detailed summary of each potential threat, which can serve as the basis for further analysis. Learn how to <>. +Attack discovery can detect a wide range of threats by finding relationships among alerts that may indicate a coordinated attack. This enables you to comprehend how threats move through and affect your systems. Attack discovery generates a detailed summary of each potential threat, which can serve as the basis for further analysis. Learn how to <>. [role="screenshot"] image::images/attck-disc-11-alerts-disc.png[An Attack discovery card showing an attack with 11 related alerts] @@ -40,7 +40,7 @@ AI Assistant can quickly compile essential data and provide suggestions to help [role="screenshot"] image::images/attck-disc-esql-query-gen-example.png[An AI Assistant dialogue in which the user asks for a purpose-built ES|QL query] -The image above shows an {esql} query generated by AI Assistant in response to a user prompt. Learn more about <>. +The image above shows an {esql} query generated by AI Assistant in response to a user prompt. Learn more about <>. At any point in a conversation with AI Assistant, you can add data, narrative summaries, and other information from its responses to {elastic-sec}'s case management system to generate incident reports. @@ -48,7 +48,7 @@ At any point in a conversation with AI Assistant, you can add data, narrative su [[use-case-incident-reporting-create-a-case-using-ai-assistant]] == Generate reports -From the AI Assistant dialog window, click **Add to case** (image:images/icons/addDataApp.svg[Add data]) next to a message to add the information in that message to a <>. Cases help centralize relevant details in one place for easy sharing with stakeholders. +From the AI Assistant dialog window, click **Add to case** (image:images/icons/addDataApp.svg[Add data]) next to a message to add the information in that message to a <>. Cases help centralize relevant details in one place for easy sharing with stakeholders. If you add a message that contains a discovery to a case, AI Assistant automatically adds the attack summary and all associated alerts to the case. You can also add AI Assistant messages that contain remediation steps and relevant data to the case. diff --git a/docs/serverless/advanced-entity-analytics/advanced-behavioral-detections.asciidoc b/docs/serverless/advanced-entity-analytics/advanced-behavioral-detections.asciidoc index b8feacddca..6f39ca9ae6 100644 --- a/docs/serverless/advanced-entity-analytics/advanced-behavioral-detections.asciidoc +++ b/docs/serverless/advanced-entity-analytics/advanced-behavioral-detections.asciidoc @@ -1,4 +1,4 @@ -[[advanced-behavioral-detections]] +[[security-advanced-behavioral-detections]] = Advanced behavioral detections :description: Learn about advanced behavioral detections and its capabilities. @@ -11,4 +11,4 @@ Elastic's {ml} capabilities and advanced correlation, scoring, and visualization Advanced behavioral detections includes two key capabilities: * <> -* <> +* <> diff --git a/docs/serverless/advanced-entity-analytics/advanced-entity-analytics-overview.asciidoc b/docs/serverless/advanced-entity-analytics/advanced-entity-analytics-overview.asciidoc index ec85a6e3eb..abdd9272db 100644 --- a/docs/serverless/advanced-entity-analytics/advanced-entity-analytics-overview.asciidoc +++ b/docs/serverless/advanced-entity-analytics/advanced-entity-analytics-overview.asciidoc @@ -1,4 +1,4 @@ -[[advanced-entity-analytics]] +[[security-advanced-entity-analytics]] = Advanced Entity Analytics :description: Learn about Advanced Entity Analytics and its capabilities. @@ -10,5 +10,5 @@ Advanced Entity Analytics generates a set of threat detection and risk analytics Advanced Entity Analytics provides two key capabilities: -* <> -* <> +* <> +* <> diff --git a/docs/serverless/advanced-entity-analytics/analyze-risk-score-data.asciidoc b/docs/serverless/advanced-entity-analytics/analyze-risk-score-data.asciidoc index e65d2b2bf1..cbb69fd414 100644 --- a/docs/serverless/advanced-entity-analytics/analyze-risk-score-data.asciidoc +++ b/docs/serverless/advanced-entity-analytics/analyze-risk-score-data.asciidoc @@ -1,4 +1,4 @@ -[[analyze-risk-score-data]] +[[security-analyze-risk-score-data]] = View and analyze risk score data :description: Monitor risk score changes of hosts and users in your environment. @@ -12,20 +12,20 @@ preview:[] The {security-app} provides several options to monitor the change in the risk posture of hosts and users from your environment. Use the following places in the {security-app} to view and analyze risk score data: -* <> -* <> -* <> -* <> -* <> -* <> +* <> +* <> +* <> +* <> +* <> +* <> [TIP] ==== -We recommend that you prioritize <> to identify anomalies or abnormal behavior patterns. +We recommend that you prioritize <> to identify anomalies or abnormal behavior patterns. ==== [discrete] -[[analyze-risk-score-data-entity-analytics-dashboard]] +[[security-analyze-risk-score-data-entity-analytics-dashboard]] == Entity Analytics dashboard From the Entity Analytics dashboard, you can access entity key performance indicators (KPIs), risk scores, and levels. You can also click the number link in the **Alerts** column to investigate and analyze the alerts on the Alerts page. @@ -34,13 +34,13 @@ From the Entity Analytics dashboard, you can access entity key performance indic image::images/detection-entity-dashboard/-dashboards-entity-dashboard.png[Entity Analytics dashboard] [discrete] -[[analyze-risk-score-data-alert-triaging]] +[[security-analyze-risk-score-data-alert-triaging]] == Alert triaging You can prioritize alert triaging to analyze alerts associated with risky or business-critical entities using the following features in the {security-app}. [discrete] -[[analyze-risk-score-data-alerts-page]] +[[security-analyze-risk-score-data-alerts-page]] === Alerts page Use the Alerts table to investigate and analyze: @@ -61,7 +61,7 @@ Learn more about <>. image::images/analyze-risk-score-data/alerts-table-rs.png[Risk scores in the Alerts table] [discrete] -[[analyze-risk-score-data-triage-alerts-associated-with-high-risk-or-business-critical-entities]] +[[security-analyze-risk-score-data-triage-alerts-associated-with-high-risk-or-business-critical-entities]] ==== Triage alerts associated with high-risk or business-critical entities To analyze alerts associated with high-risk or business-critical entities, you can filter or group them by entity risk level or asset criticality level. @@ -105,7 +105,7 @@ image::images/analyze-risk-score-data/group-by-asset-criticality.png[Alerts grou image::images/analyze-risk-score-data/hrl-sort-by-host-risk-score.png[High-risk alerts sorted by host risk score] [discrete] -[[analyze-risk-score-data-alert-details-flyout]] +[[security-analyze-risk-score-data-alert-details-flyout]] === Alert details flyout To access risk score data in the alert details flyout, select **Insights** → **Entities** on the **Overview** tab: @@ -114,7 +114,7 @@ To access risk score data in the alert details flyout, select **Insights** → * image::images/analyze-risk-score-data/alerts-flyout-rs.png[Risk scores in the Alerts flyout] [discrete] -[[analyze-risk-score-data-hosts-and-users-pages]] +[[security-analyze-risk-score-data-hosts-and-users-pages]] === Hosts and Users pages On the Hosts and Users pages, you can access the risk score data: @@ -129,7 +129,7 @@ image::images/analyze-risk-score-data/hosts-hr-level.png[Host risk level data on image::images/analyze-risk-score-data/hosts-hr-data.png[Host risk data on the Host risk tab of the Hosts page] [discrete] -[[analyze-risk-score-data-host-and-user-details-pages]] +[[security-analyze-risk-score-data-host-and-user-details-pages]] === Host and user details pages On the host details and user details pages, you can access the risk score data: @@ -144,7 +144,7 @@ image::images/analyze-risk-score-data/host-details-overview.png[Host risk data i image::images/analyze-risk-score-data/host-details-hr-tab.png[Host risk data on the Host risk tab of the host details page] [discrete] -[[analyze-risk-score-data-host-and-user-details-flyouts]] +[[security-analyze-risk-score-data-host-and-user-details-flyouts]] === Host and user details flyouts In the host details and user details flyouts, you can access the risk score data in the risk summary section: diff --git a/docs/serverless/advanced-entity-analytics/asset-criticality.asciidoc b/docs/serverless/advanced-entity-analytics/asset-criticality.asciidoc index 19a6853896..5717328788 100644 --- a/docs/serverless/advanced-entity-analytics/asset-criticality.asciidoc +++ b/docs/serverless/advanced-entity-analytics/asset-criticality.asciidoc @@ -1,4 +1,4 @@ -[[asset-criticality]] +[[security-asset-criticality]] = Asset criticality :description: Learn how to use asset criticality to improve your security operations. @@ -12,9 +12,9 @@ preview:[] To view and assign asset criticality, you must: * Have the appropriate user role. -* Turn on the `securitySolution:enableAssetCriticality` <>. +* Turn on the `securitySolution:enableAssetCriticality` <>. -For more information, refer to <>. +For more information, refer to <>. ==== The asset criticality feature allows you to classify your organization's entities based on various operational factors that are important to your organization. Through this classification, you can improve your threat detection capabilities by focusing your alert triage, threat-hunting, and investigation activities on high-impact entities. @@ -29,10 +29,10 @@ You can assign one of the following asset criticality levels to your entities, b For example, you can assign **Extreme impact** to business-critical entities, or **Low impact** to entities that pose minimal risk to your security posture. [discrete] -[[asset-criticality-view-and-assign-asset-criticality]] +[[security-asset-criticality-view-and-assign-asset-criticality]] == View and assign asset criticality -Entities do not have a default asset criticality level. You can either assign asset criticality to your entities individually, or <> it to multiple entities by importing a text file. +Entities do not have a default asset criticality level. You can either assign asset criticality to your entities individually, or <> it to multiple entities by importing a text file. When you assign, change, or unassign an individual entity's asset criticality level, that entity's risk score is immediately recalculated. @@ -43,21 +43,21 @@ If you assign asset criticality using the file import feature, risk scores are * You can view, assign, change, or unassign asset criticality from the following places in the {elastic-sec} app: -* The <> and <>: +* The <> and <>: + [role="screenshot"] image::images/asset-criticality/-assign-asset-criticality-host-details.png[Assign asset criticality from the host details page] -* The <> and <>: +* The <> and <>: + [role="screenshot"] image::images/asset-criticality/-assign-asset-criticality-host-flyout.png[Assign asset criticality from the host details flyout] -* The host details flyout and user details flyout in <>: +* The host details flyout and user details flyout in <>: + [role="screenshot"] image::images/asset-criticality/-assign-asset-criticality-timeline.png[Assign asset criticality from the host details flyout in Timeline] [discrete] -[[asset-criticality-bulk-assign-asset-criticality]] +[[security-asset-criticality-bulk-assign-asset-criticality]] === Bulk assign asset criticality You can bulk assign asset criticality to multiple entities by importing a CSV, TXT or TSV file from your asset management tools. @@ -100,31 +100,31 @@ This process overwrites any previously assigned asset criticality levels for the You can trigger an immediate recalculation of entity risk scores by clicking **Recalculate entity risk scores now**. Otherwise, the newly assigned or updated asset criticality levels will be factored in during the next hourly risk scoring calculation. [discrete] -[[asset-criticality-improve-your-security-operations]] +[[security-asset-criticality-improve-your-security-operations]] == Improve your security operations With asset criticality, you can improve your security operations by: -* <> -* <> +* <> +* <> [discrete] -[[asset-criticality-prioritize-open-alerts]] +[[security-asset-criticality-prioritize-open-alerts]] === Prioritize open alerts You can use asset criticality as a prioritization factor when triaging alerts and conducting investigations and response activities. -Once you assign a criticality level to an entity, all subsequent alerts related to that entity are enriched with its criticality level. This additional context allows you to <>. +Once you assign a criticality level to an entity, all subsequent alerts related to that entity are enriched with its criticality level. This additional context allows you to <>. [discrete] -[[asset-criticality-monitor-an-entitys-risk]] +[[security-asset-criticality-monitor-an-entitys-risk]] === Monitor an entity's risk -The risk scoring engine dynamically factors in an entity's asset criticality, along with `Open` and `Acknowledged` detection alerts to <>. This dynamic risk scoring allows you to monitor changes in the risk profiles of your most sensitive entities, and quickly escalate high-risk threats. +The risk scoring engine dynamically factors in an entity's asset criticality, along with `Open` and `Acknowledged` detection alerts to <>. This dynamic risk scoring allows you to monitor changes in the risk profiles of your most sensitive entities, and quickly escalate high-risk threats. To view the impact of asset criticality on an entity's risk score, follow these steps: -. Open the <> or <>. The risk summary section shows asset criticality's contribution to the overall risk score. +. Open the <> or <>. The risk summary section shows asset criticality's contribution to the overall risk score. . Click **View risk contributions** to open the flyout's left panel. . In the **Risk contributions** section, verify the entity's criticality level from the time the alert was generated. diff --git a/docs/serverless/advanced-entity-analytics/behavioral-detection-use-cases.asciidoc b/docs/serverless/advanced-entity-analytics/behavioral-detection-use-cases.asciidoc index 676db9f9c1..83ee759958 100644 --- a/docs/serverless/advanced-entity-analytics/behavioral-detection-use-cases.asciidoc +++ b/docs/serverless/advanced-entity-analytics/behavioral-detection-use-cases.asciidoc @@ -1,4 +1,4 @@ -[[behavioral-detection-use-cases]] +[[security-behavioral-detection-use-cases]] = Behavioral detection use cases :description: Detect internal and external threats using behavioral detection integrations. @@ -11,7 +11,7 @@ Behavioral detection identifies potential internal and external threats based on The behavioral detection feature is built on {elastic-sec}'s foundational SIEM detection capabilities, leveraging {ml} algorithms to enable proactive threat detection and hunting. [discrete] -[[behavioral-detection-use-cases-elastic-integrations-for-behavioral-detection-use-cases]] +[[security-behavioral-detection-use-cases-elastic-integrations-for-behavioral-detection-use-cases]] == Elastic integrations for behavioral detection use cases Behavioral detection integrations provide a convenient way to enable behavioral detection capabilities. They streamline the deployment of components that implement behavioral detection, such as data ingestion, transforms, rules, {ml} jobs, and scripts. @@ -20,7 +20,7 @@ Behavioral detection integrations provide a convenient way to enable behavioral [NOTE] ==== * Behavioral detection integrations require the Security Analytics Complete https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature]. -* To learn more about the requirements for using {ml} jobs, refer to <>. +* To learn more about the requirements for using {ml} jobs, refer to <>. ==== Here's a list of integrations for various behavioral detection use cases: diff --git a/docs/serverless/advanced-entity-analytics/entity-risk-scoring.asciidoc b/docs/serverless/advanced-entity-analytics/entity-risk-scoring.asciidoc index a56d337a12..38b2a2fa29 100644 --- a/docs/serverless/advanced-entity-analytics/entity-risk-scoring.asciidoc +++ b/docs/serverless/advanced-entity-analytics/entity-risk-scoring.asciidoc @@ -1,4 +1,4 @@ -[[entity-risk-scoring]] +[[security-entity-risk-scoring]] = Entity risk scoring :description: Learn about the risk scoring engine and its features. @@ -13,7 +13,7 @@ Entity risk scoring allows you to monitor risk score changes of hosts and users It also generates risk scores on a recurring interval, and allows for easy onboarding and management. The engine is built to factor in risks from all {elastic-sec} use cases, and allows you to customize and control how and when risk is calculated. [discrete] -[[entity-risk-scoring-risk-scoring-inputs]] +[[security-entity-risk-scoring-risk-scoring-inputs]] == Risk scoring inputs Entity risk scores are determined by the following risk inputs: @@ -21,10 +21,10 @@ Entity risk scores are determined by the following risk inputs: |=== | Risk input | Storage location -| <> +| <> | `.alerts-security.alerts-` index alias -| <> +| <> | `.asset-criticality.asset-criticality-` index alias |=== @@ -33,16 +33,16 @@ The resulting entity risk scores are stored in the `risk-score.risk-score->. +* To use asset criticality, you must enable the `securitySolution:enableAssetCriticality` <>. ==== [discrete] -[[entity-risk-scoring-how-is-risk-score-calculated]] +[[security-entity-risk-scoring-how-is-risk-score-calculated]] == How is risk score calculated? . The risk scoring engine runs hourly to aggregate `Open` and `Acknowledged` alerts from the last 30 days. For each entity, the engine processes up to 10,000 alerts. -. The engine groups alerts by `host.name` or `user.name`, and aggregates the individual alert risk scores (`kibana.alert.risk_score`) such that alerts with higher risk scores contribute more than alerts with lower risk scores. The resulting aggregated risk score is assigned to the **Alerts** category in the entity's <>. -. The engine then verifies the entity's <>. If there is no asset criticality assigned, the entity risk score remains equal to the aggregated score from the **Alerts** category. If a criticality level is assigned, the engine updates the risk score based on the default risk weight for each criticality level. The asset criticality risk input is assigned to the **Asset Criticality** category in the entity's risk summary. +. The engine groups alerts by `host.name` or `user.name`, and aggregates the individual alert risk scores (`kibana.alert.risk_score`) such that alerts with higher risk scores contribute more than alerts with lower risk scores. The resulting aggregated risk score is assigned to the **Alerts** category in the entity's <>. +. The engine then verifies the entity's <>. If there is no asset criticality assigned, the entity risk score remains equal to the aggregated score from the **Alerts** category. If a criticality level is assigned, the engine updates the risk score based on the default risk weight for each criticality level. The asset criticality risk input is assigned to the **Asset Criticality** category in the entity's risk summary. + |=== | Asset criticality level| Default risk weight @@ -117,4 +117,4 @@ To calculate the user risk score, the risk scoring engine: If `User_A` had no asset criticality level assigned, the user risk score would remain unchanged at 36.16. ===== -Learn how to <>. +Learn how to <>. diff --git a/docs/serverless/advanced-entity-analytics/ers-req.asciidoc b/docs/serverless/advanced-entity-analytics/ers-req.asciidoc index aea5822185..9bab34151c 100644 --- a/docs/serverless/advanced-entity-analytics/ers-req.asciidoc +++ b/docs/serverless/advanced-entity-analytics/ers-req.asciidoc @@ -1,4 +1,4 @@ -[[ers-requirements]] +[[security-ers-requirements]] = Entity risk scoring requirements :description: Requirements for using entity risk scoring and asset criticality. @@ -9,11 +9,11 @@ To use entity risk scoring and asset criticality, you need the appropriate user This page covers the requirements for using the entity risk scoring and asset criticality features, as well as their known limitations. [discrete] -[[ers-requirements-entity-risk-scoring]] +[[security-ers-requirements-entity-risk-scoring]] == Entity risk scoring [discrete] -[[ers-requirements-user-roles]] +[[security-ers-requirements-user-roles]] === User roles To turn on the risk scoring engine, you need either the appropriate https://www.elastic.co/docs/current/serverless/general/assign-user-roles[predefined Security user role] or a https://www.elastic.co/docs/current/serverless/custom-roles[custom role] with the right privileges: @@ -36,20 +36,20 @@ To turn on the risk scoring engine, you need either the appropriate https://www. |=== [discrete] -[[ers-requirements-known-limitations]] +[[security-ers-requirements-known-limitations]] === Known limitations * The risk scoring engine uses an internal user role to score all hosts and users. After you turn on the risk scoring engine, all alerts in the project will contribute to host and user risk scores. * You cannot customize alert data views or risk weights associated with alerts and asset criticality levels. [discrete] -[[ers-requirements-asset-criticality]] +[[security-ers-requirements-asset-criticality]] == Asset criticality -To use the asset criticality feature, turn on the `securitySolution:enableAssetCriticality` <>. +To use the asset criticality feature, turn on the `securitySolution:enableAssetCriticality` <>. [discrete] -[[ers-requirements-user-roles-1]] +[[security-ers-requirements-user-roles-1]] === User roles To use asset criticality, you need either the appropriate https://www.elastic.co/docs/current/serverless/general/assign-user-roles[predefined Security user role] or a https://www.elastic.co/docs/current/serverless/custom-roles[custom role] with the right privileges: diff --git a/docs/serverless/advanced-entity-analytics/machine-learning.asciidoc b/docs/serverless/advanced-entity-analytics/machine-learning.asciidoc index 3de7412be6..6c3c93c0b8 100644 --- a/docs/serverless/advanced-entity-analytics/machine-learning.asciidoc +++ b/docs/serverless/advanced-entity-analytics/machine-learning.asciidoc @@ -7,7 +7,7 @@ preview:[] {ml-docs}/ml-ad-overview.html[{ml-cap}] functionality is available when -you have the appropriate role. Refer to <> for more information. +you have the appropriate role. Refer to <> for more information. You can view the details of detected anomalies within the `Anomalies` table widget shown on the Hosts, Network, and associated details pages, or even narrow @@ -49,7 +49,7 @@ host and network anomalies. The jobs are displayed in the `Anomaly Detection` interface. They are available when either: * You ship data using https://www.elastic.co/products/beats[Beats] or the -<>, and {kib} is configured with the required index +<>, and {kib} is configured with the required index patterns (such as `auditbeat-*`, `filebeat-*`, `packetbeat-*`, or `winlogbeat-*` in **Project settings** → **Management** → **Index Management**). @@ -60,12 +60,12 @@ data's index patterns in **Project settings** → **Management** → **Index Man Or -* You install one or more of the <>. +* You install one or more of the <>. -<> describes all available {ml} jobs and lists which ECS +<> describes all available {ml} jobs and lists which ECS fields are required on your hosts when you are not using {beats} or the {agent} to ship your data. For information on tuning anomaly results to reduce the -number of false positives, see <>. +number of false positives, see <>. [NOTE] ==== diff --git a/docs/serverless/advanced-entity-analytics/ml-requirements.asciidoc b/docs/serverless/advanced-entity-analytics/ml-requirements.asciidoc index e9227c5360..0a672625c4 100644 --- a/docs/serverless/advanced-entity-analytics/ml-requirements.asciidoc +++ b/docs/serverless/advanced-entity-analytics/ml-requirements.asciidoc @@ -1,4 +1,4 @@ -[[ml-requirements]] +[[security-ml-requirements]] = {ml-cap} job and rule requirements :description: Requirements for using {ml} jobs and rules. @@ -8,7 +8,7 @@ preview:[] To run and create {ml} jobs and rules, you need the appropriate https://www.elastic.co/docs/current/serverless/general/assign-user-roles[user role]. -Additionally, for https://www.elastic.co/docs/current/serverless/custom-roles[custom roles], to configure <> for {ml} rules, your role needs the following index privilege: +Additionally, for https://www.elastic.co/docs/current/serverless/custom-roles[custom roles], to configure <> for {ml} rules, your role needs the following index privilege: * `read` permission for the `.ml-anomalies-*` index diff --git a/docs/serverless/advanced-entity-analytics/prebuilt-ml-jobs.asciidoc b/docs/serverless/advanced-entity-analytics/prebuilt-ml-jobs.asciidoc index f5261ea3d2..67779ddf94 100644 --- a/docs/serverless/advanced-entity-analytics/prebuilt-ml-jobs.asciidoc +++ b/docs/serverless/advanced-entity-analytics/prebuilt-ml-jobs.asciidoc @@ -1,4 +1,4 @@ -[[prebuilt-ml-jobs]] +[[security-prebuilt-ml-jobs]] = Prebuilt ML job reference :keywords: serverless, security, reference diff --git a/docs/serverless/advanced-entity-analytics/tuning-anomaly-results.asciidoc b/docs/serverless/advanced-entity-analytics/tuning-anomaly-results.asciidoc index f398e48e0e..0ad10c8f5b 100644 --- a/docs/serverless/advanced-entity-analytics/tuning-anomaly-results.asciidoc +++ b/docs/serverless/advanced-entity-analytics/tuning-anomaly-results.asciidoc @@ -1,4 +1,4 @@ -[[tuning-anomaly-results]] +[[security-tuning-anomaly-results]] = Optimizing anomaly results :description: Learn how to fine-tune and filter anomaly results. diff --git a/docs/serverless/advanced-entity-analytics/turn-on-risk-engine.asciidoc b/docs/serverless/advanced-entity-analytics/turn-on-risk-engine.asciidoc index e27224c10e..2cd09138a7 100644 --- a/docs/serverless/advanced-entity-analytics/turn-on-risk-engine.asciidoc +++ b/docs/serverless/advanced-entity-analytics/turn-on-risk-engine.asciidoc @@ -1,4 +1,4 @@ -[[turn-on-risk-engine]] +[[security-turn-on-risk-engine]] = Turn on the risk scoring engine :description: Start generating host and user risk scores. @@ -13,11 +13,11 @@ preview:[] .Requirements [NOTE] ==== -To use entity risk scoring, you must have the appropriate user role. For more information, refer to <>. +To use entity risk scoring, you must have the appropriate user role. For more information, refer to <>. ==== [discrete] -[[turn-on-risk-engine-preview-risky-entities]] +[[security-turn-on-risk-engine-preview-risky-entities]] == Preview risky entities You can preview risky entities before installing the risk engine. The preview shows the riskiest hosts and users found in the 1000 sampled entities during the time frame selected in the date picker. @@ -33,7 +33,7 @@ To preview risky entities, go to **Project settings** → **Management** → **E image::images/turn-on-risk-engine/preview-risky-entities.png[Preview of risky entities] [discrete] -[[turn-on-risk-engine-turn-on-the-risk-engine]] +[[security-turn-on-risk-engine-turn-on-the-risk-engine]] == Turn on the risk engine [NOTE] diff --git a/docs/serverless/alerts/alert-schema.asciidoc b/docs/serverless/alerts/alert-schema.asciidoc index e67b5fbef3..9ffc73bd8b 100644 --- a/docs/serverless/alerts/alert-schema.asciidoc +++ b/docs/serverless/alerts/alert-schema.asciidoc @@ -1,4 +1,4 @@ -[[alert-schema]] +[[security-alert-schema]] = Alert schema :description: The alert schema describes all the fields present in alert events. diff --git a/docs/serverless/alerts/alert-suppression.asciidoc b/docs/serverless/alerts/alert-suppression.asciidoc index 3689542c95..e4249e5604 100644 --- a/docs/serverless/alerts/alert-suppression.asciidoc +++ b/docs/serverless/alerts/alert-suppression.asciidoc @@ -1,4 +1,4 @@ -[[alert-suppression]] +[[security-alert-suppression]] = Suppress detection alerts :description: Reduce noise from rules that create repeated or duplicate alerts. @@ -13,7 +13,7 @@ preview:[] .Requirements and notice [IMPORTANT] ==== -* {ml-cap} rules have <> for alert suppression. +* {ml-cap} rules have <> for alert suppression. * Alert suppression is in technical preview for event correlation rules. The functionality may be changed or removed in a future release. Elastic will work to fix any issues, but features in technical preview are not subject to the support SLA of official GA features. ==== @@ -37,7 +37,7 @@ Alert suppression is not available for Elastic prebuilt rules. However, if you w ==== [discrete] -[[alert-suppression-configure-alert-suppression]] +[[security-alert-suppression-configure-alert-suppression]] == Configure alert suppression You can configure alert suppression when you create or edit a supported rule type. Refer to documentation for creating <>, <>, <>, <>, <>, <>, or <> rules for detailed instructions. @@ -89,7 +89,7 @@ These options are not available for threshold rules. ==== [discrete] -[[alert-suppression-confirm-suppressed-alerts]] +[[security-alert-suppression-confirm-suppressed-alerts]] == Confirm suppressed alerts The {security-app} displays several indicators of whether a detection alert was created with alert suppression enabled, and how many duplicate alerts were suppressed. @@ -113,7 +113,7 @@ image:images/alert-suppression/-detections-suppressed-alerts-table-column.png[Su image:images/alert-suppression/-detections-suppressed-alerts-details.png[Suppressed alerts Insights section in alert details flyout] [discrete] -[[alert-suppression-investigate-events-for-suppressed-alerts]] +[[security-alert-suppression-investigate-events-for-suppressed-alerts]] == Investigate events for suppressed alerts With alert suppression, detection alerts aren't created for the grouped source events, but you can still retrieve the events for further analysis or investigation. Do one of the following to open Timeline with the original events associated with both the created alert and the suppressed alerts: @@ -125,7 +125,7 @@ image:images/alert-suppression/-detections-timeline-button.png[Investigate in ti * Alert details flyout — Select **Take action** → **Investigate in timeline**. [discrete] -[[alert-suppression-alert-suppression-limit-by-rule-type]] +[[security-alert-suppression-alert-suppression-limit-by-rule-type]] == Alert suppression limit by rule type Some rule types have a maximum number of alerts that can be suppressed (custom query rules don't have a suppression limit): diff --git a/docs/serverless/alerts/alerts-ui-manage.asciidoc b/docs/serverless/alerts/alerts-ui-manage.asciidoc index 55c9b54e05..8f91765f77 100644 --- a/docs/serverless/alerts/alerts-ui-manage.asciidoc +++ b/docs/serverless/alerts/alerts-ui-manage.asciidoc @@ -1,4 +1,4 @@ -[[alerts-manage]] +[[security-alerts-manage]] = Manage detection alerts :description: Filter alerts, view trends, and start investigating and analyzing detections on the Alerts page. @@ -21,21 +21,21 @@ image::images/alerts-ui-manage/-detections-alert-page.png[Alerts page overview] The Alerts page offers various ways for you to organize and triage detection alerts as you investigate suspicious events. You can: -* View an alert's details. Click the **View details** button from the Alerts table to open the alert details flyout. Learn more at <>. +* View an alert's details. Click the **View details** button from the Alerts table to open the alert details flyout. Learn more at <>. + [role="screenshot"] image:images/alerts-ui-manage/-detections-view-alert-details.png[View details button] * View the rule that created an alert. Click a name in the **Rule** column to open the rule's details page. -* View the details of the host and user associated with the alert. In the Alerts table, click a host name to open the <>, or a user name to open the <>. +* View the details of the host and user associated with the alert. In the Alerts table, click a host name to open the <>, or a user name to open the <>. * Filter for a specific rule in the KQL bar (for example, `kibana.alert.rule.name :"SSH (Secure Shell) from the Internet"`). KQL autocomplete is available for `.alerts-security.alerts-*` indices. * Use the date and time filter to define a specific time range. By default, this filter is set to search the last 24 hours. * Use the drop-down filter controls to filter alerts by up to four fields. By default, you can filter alerts by **Status**, **Severity**, **User**, and **Host**, and you can <> to use other fields. -* Visualize and group alerts by specific fields in the visualization section. Use the buttons on the left to select a view type (**Summary**, **Trend**, **Counts**, or **Treemap**), and use the menus on the right to select the ECS fields used for grouping alerts. Refer to <> for more on each view type. +* Visualize and group alerts by specific fields in the visualization section. Use the buttons on the left to select a view type (**Summary**, **Trend**, **Counts**, or **Treemap**), and use the menus on the right to select the ECS fields used for grouping alerts. Refer to <> for more on each view type. * Hover over a value to display available <>, such as **Filter In**, **Filter Out**, and **Add to timeline**. Click the expand icon for more options, including **Show top _x_** and **Copy to Clipboard**. The available options vary based on the type of data. + [role="screenshot"] image:images/alerts-ui-manage/-detections-inline-actions-menu.png[Inline additional actions menu] -* Filter alert results to include building block alerts or to only show alerts from indicator match rules by selecting the **Additional filters** drop-down. By default, <> are excluded from the Overview and Alerts pages. You can choose to include building block alerts on the Alerts page, which expands the number of alerts. +* Filter alert results to include building block alerts or to only show alerts from indicator match rules by selecting the **Additional filters** drop-down. By default, <> are excluded from the Overview and Alerts pages. You can choose to include building block alerts on the Alerts page, which expands the number of alerts. + [role="screenshot"] image::images/alerts-ui-manage/-detections-additional-filters.png[Alerts table with Additional filters menu highlighted] @@ -106,7 +106,7 @@ Use the toolbar buttons in the upper-left of the Alerts table to customize the c * **Columns**: Reorder the columns. * **_x_ fields sorted**: Sort the table by one or more columns. -* **Fields**: Select the fields to display in the table. You can also add <> to detection alerts and display them in the Alerts table. +* **Fields**: Select the fields to display in the table. You can also add <> to detection alerts and display them in the Alerts table. Click the **Full screen** button in the upper-right to view the table in full-screen mode. @@ -132,18 +132,18 @@ When using grid view, you can view alert-rendered reason statements and event re From the Alerts table or the alert details flyout, you can: -* <> +* <> * <> * <> * <> * <> * <> * <> -* <> -* <> (Alert details flyout only) -* <> +* <> +* <> (Alert details flyout only) +* <> * <> -* <> +* <> [discrete] [[detection-alert-status]] @@ -264,7 +264,7 @@ To add an exception, click the **More actions** menu (**...**) in the Alerts tab **Add exception**. Alternatively, select **Take action** → **Add rule exception** in the alert details flyout. For information about exceptions and how to use them, refer to -<>. +<>. [discrete] [[signals-to-timelines]] @@ -282,7 +282,7 @@ image:images/alerts-ui-manage/-detections-bulk-add-alerts-to-timeline.png[Bulk a [TIP] ==== When you send an alert generated by a -<> to Timeline, all matching events are +<> to Timeline, all matching events are listed in the Timeline, even ones that did not reach the threshold value. For example, if you have an alert generated by a threshold rule that detects 10 failed login attempts, when you send that alert to Timeline, all failed login @@ -301,6 +301,6 @@ is `host.name: "Windows-ArsenalFC"`. [NOTE] ==== -Refer to <> for information on creating Timelines and Timeline -templates. For information on how to add Timeline templates to rules, refer to <>. +Refer to <> for information on creating Timelines and Timeline +templates. For information on how to add Timeline templates to rules, refer to <>. ==== diff --git a/docs/serverless/alerts/query-alert-indices.asciidoc b/docs/serverless/alerts/query-alert-indices.asciidoc index 8ed9b1ce41..91cdeedf4d 100644 --- a/docs/serverless/alerts/query-alert-indices.asciidoc +++ b/docs/serverless/alerts/query-alert-indices.asciidoc @@ -1,4 +1,4 @@ -[[query-alert-indices]] +[[security-query-alert-indices]] = Query alert indices :description: Index patterns for querying alert data. @@ -6,16 +6,16 @@ preview:[] -This page explains how you should query alert indices, for example, when building rule queries, custom dashboards, or visualizations. For more information about alert event field definitions, review the <>. +This page explains how you should query alert indices, for example, when building rule queries, custom dashboards, or visualizations. For more information about alert event field definitions, review the <>. [discrete] -[[query-alert-indices-alert-index-aliases]] +[[security-query-alert-indices-alert-index-aliases]] == Alert index aliases We recommend querying the `.alerts-security.alerts-` index alias. You should not include a dash or wildcard after the space ID. To query all spaces, use the following syntax: `.alerts-security.alerts-*`. [discrete] -[[query-alert-indices-alert-indices]] +[[security-query-alert-indices-alert-indices]] == Alert indices For additional context, alert events are stored in hidden {es} indices. We do not recommend querying them directly. The naming convention for these indices and their aliases is `.internal.alerts-security.alerts--NNNNNN`, where `NNNNNN` is a number that increases over time, starting from 000001. diff --git a/docs/serverless/alerts/reduce-notifications-alerts.asciidoc b/docs/serverless/alerts/reduce-notifications-alerts.asciidoc index f656a7f85c..51ac1b2655 100644 --- a/docs/serverless/alerts/reduce-notifications-alerts.asciidoc +++ b/docs/serverless/alerts/reduce-notifications-alerts.asciidoc @@ -1,4 +1,4 @@ -[[reduce-notifications-alerts]] +[[security-reduce-notifications-alerts]] = Reduce notifications and alerts :description: A comparison of alert-reduction features. @@ -14,19 +14,19 @@ preview:[] | <> a| **_Stops a specific rule's notification actions from running_**. -Use to avoid unnecessary notifications from a specific rule. The rule continues to run and generate alerts during the snooze period, but its <> don't run. +Use to avoid unnecessary notifications from a specific rule. The rule continues to run and generate alerts during the snooze period, but its <> don't run. | {kibana-ref}/maintenance-windows.html[Maintenance window] a| **_Prevents all rules' notification actions from running_**. -Use to avoid false alarms and unnecessary notifications during planned outages. All rules continue to run and generate alerts during the maintenance window, but their <> don't run. +Use to avoid false alarms and unnecessary notifications during planned outages. All rules continue to run and generate alerts during the maintenance window, but their <> don't run. -| <> +| <> a| **_Reduces repeated or duplicate alerts_**. Use to reduce the number of alerts created when a rule meets its criteria repeatedly. Duplicate qualifying events are grouped, and only one alert is created for each group. -| <> +| <> a| **_Prevents a rule from creating alerts under specific conditions_**. Use to reduce false positive alerts by preventing trusted processes and network activity from generating unnecessary alerts. You can configure an exception to be used by a single rule or shared among multiple rules, but they typically don't affect _all_ rules. diff --git a/docs/serverless/alerts/signals-to-cases.asciidoc b/docs/serverless/alerts/signals-to-cases.asciidoc index 88f570c2fa..330be85a99 100644 --- a/docs/serverless/alerts/signals-to-cases.asciidoc +++ b/docs/serverless/alerts/signals-to-cases.asciidoc @@ -1,4 +1,4 @@ -[[signals-to-cases]] +[[security-signals-to-cases]] = Add detection alerts to cases :description: Add alerts to new or existing cases in {elastic-sec}. @@ -41,7 +41,7 @@ https://docs.github.com/en/get-started/writing-on-github/getting-started-with-wr If you do not assign your case a severity level, it will be assigned **Low** by default. ==== . Optionally, add a category, assignees and relevant tags. You can add users only if they -meet the necessary <>. +meet the necessary <>. . Specify whether you want to sync the status of associated alerts. It is enabled by default; however, you can toggle this setting on or off at any time. If it remains enabled, the alert's status updates whenever the case's status is modified. . Select a connector. If you've previously added one, that connector displays as the default selection. Otherwise, the default setting is `No connector selected`. . Click **Create case** after you've completed all of the required fields. A confirmation message is displayed with an option to view the new case. Click the link in the notification or go to the Cases page to view the case. diff --git a/docs/serverless/alerts/view-alert-details.asciidoc b/docs/serverless/alerts/view-alert-details.asciidoc index b9a9842589..c8365cd7d6 100644 --- a/docs/serverless/alerts/view-alert-details.asciidoc +++ b/docs/serverless/alerts/view-alert-details.asciidoc @@ -1,4 +1,4 @@ -[[view-alert-details]] +[[security-view-alert-details]] = View detection alert details :description: Expand an alert to view detailed alert data. @@ -131,8 +131,8 @@ image::images/view-alert-details/-detections-visualizations-section-rp.png[Visua Click **Visualizations** to display the following previews: -* **Session view preview**: Shows a preview of <> data. Click **Session viewer preview** to open the **Session View** tab in Timeline. -* **Analyzer preview**: Shows a preview of the <>. The preview displays up to three levels of the analyzed event's ancestors and up to three levels of the event's descendants and children. The ellipses symbol (**`...`**) indicates the event has more ancestors and descendants to examine. Click **Analyzer preview** to open the **Event Analyzer** tab in Timeline. +* **Session view preview**: Shows a preview of <> data. Click **Session viewer preview** to open the **Session View** tab in Timeline. +* **Analyzer preview**: Shows a preview of the <>. The preview displays up to three levels of the analyzed event's ancestors and up to three levels of the event's descendants and children. The ellipses symbol (**`...`**) indicates the event has more ancestors and descendants to examine. Click **Analyzer preview** to open the **Event Analyzer** tab in Timeline. [discrete] [[insights-section]] @@ -250,7 +250,7 @@ In the expanded view, corelation data is organized into several tables: * **Suppressed alerts**: preview:[] Shows how many duplicate alerts were suppressed. This information only appears if alert suppression is enabled for the rule. * **Related cases**: Shows cases to which the alert has been added. Click a case's name to open its details. * **Alerts related by source event**: Shows alerts created by the same source event. This can help you find alerts with a shared origin and provide more context about the source event. Click the **Investigate in timeline** button to examine related alerts in Timeline. -* **Alerts related by session**: Shows alerts generated during the same <>. These alerts share the same session ID, which is a unique ID for tracking a given Linux session. To use this feature, you must enable the **Collect session data** setting in your {elastic-defend} integration policy. Refer to <> for more information. +* **Alerts related by session**: Shows alerts generated during the same <>. These alerts share the same session ID, which is a unique ID for tracking a given Linux session. To use this feature, you must enable the **Collect session data** setting in your {elastic-defend} integration policy. Refer to <> for more information. * **Alerts related by ancestry**: Shows alerts that are related by process events on the same linear branch. Note that alerts generated from processes on child or related branches are not shown. To further examine alerts, click **Investigate in timeline**. [discrete] @@ -286,7 +286,7 @@ The expanded Prevalence view provides the following details: [[response-overview]] == Response -The **Response** section is located on the **Overview** tab in the right panel. It shows <> that were added to the rule associated with the alert. Click **Response** to display the response action's results in the left panel. +The **Response** section is located on the **Overview** tab in the right panel. It shows <> that were added to the rule associated with the alert. Click **Response** to display the response action's results in the left panel. [role="screenshot"] image::images/view-alert-details/-detections-response-action-rp.png[Response section of the Overview tab] diff --git a/docs/serverless/alerts/visual-event-analyzer.asciidoc b/docs/serverless/alerts/visual-event-analyzer.asciidoc index e8dfa373b2..1dbcf0c5bf 100644 --- a/docs/serverless/alerts/visual-event-analyzer.asciidoc +++ b/docs/serverless/alerts/visual-event-analyzer.asciidoc @@ -1,4 +1,4 @@ -[[visual-event-analyzer]] +[[security-visual-event-analyzer]] = Visual event analyzer :description: Examine events and processes in a graphical timeline. @@ -10,7 +10,7 @@ preview:[] [TIP] ==== -If you're experiencing performance degradation, you can <> from analyzer queries. +If you're experiencing performance degradation, you can <> from analyzer queries. ==== [discrete] @@ -51,7 +51,7 @@ image::images/visual-event-analyzer/-detections-analyze-event-timeline.png[] + [TIP] ==== -You can also analyze events from <>. +You can also analyze events from <>. ==== [discrete] diff --git a/docs/serverless/alerts/visualize-alerts.asciidoc b/docs/serverless/alerts/visualize-alerts.asciidoc index 2099a0f206..634b895ea4 100644 --- a/docs/serverless/alerts/visualize-alerts.asciidoc +++ b/docs/serverless/alerts/visualize-alerts.asciidoc @@ -1,4 +1,4 @@ -[[visualize-alerts]] +[[security-visualize-alerts]] = Visualize detection alerts :description: Display alert trends and distributions on the Alerts page. @@ -40,7 +40,7 @@ Click the collapse icon (image:images/icons/arrowDown.svg[Markdown]) to minimize image::images/visualize-alerts/-detections-alert-page-viz-collapsed.png[Alerts page with visualizations section collapsed] [discrete] -[[visualize-alerts-summary]] +[[security-visualize-alerts-summary]] == Summary On the Alerts page, the summary visualization displays by default and shows how alerts are distributed across these indicators: @@ -55,7 +55,7 @@ You can hover and click on elements within the summary — such as severity leve image::images/visualize-alerts/-detections-alerts-viz-summary.png[Summary visualization for alerts] [discrete] -[[visualize-alerts-trend]] +[[security-visualize-alerts-trend]] == Trend The trend view shows the occurrence of alerts over time. By default, it groups alerts by detection rule name (`kibana.alert.rule.name`). @@ -69,7 +69,7 @@ The **Group by top** menu is unavailable for the trend view. image::images/visualize-alerts/-detections-alerts-viz-trend.png[Trend visualization for alerts] [discrete] -[[visualize-alerts-counts]] +[[security-visualize-alerts-counts]] == Counts The counts view shows the count of alerts in each group. By default, it groups alerts first by detection rule name (`kibana.alert.rule.name`), then by host name (`host.name`). @@ -78,7 +78,7 @@ The counts view shows the count of alerts in each group. By default, it groups a image::images/visualize-alerts/-detections-alerts-viz-counts.png[Counts visualization for alerts] [discrete] -[[visualize-alerts-treemap]] +[[security-visualize-alerts-treemap]] == Treemap The treemap view shows the distribution of alerts as nested, proportionally-sized tiles. This view can help you quickly pinpoint the most prevalent and critical alerts. diff --git a/docs/serverless/assets/asset-management.asciidoc b/docs/serverless/assets/asset-management.asciidoc index 3559c91948..d393421f12 100644 --- a/docs/serverless/assets/asset-management.asciidoc +++ b/docs/serverless/assets/asset-management.asciidoc @@ -1,4 +1,4 @@ -[[asset-management]] +[[security-asset-management]] = Asset management :keywords: serverless, security, overview, manage @@ -9,5 +9,5 @@ The **Assets** page allows you to manage the following features: * {fleet-guide}/manage-agents-in-fleet.html[{fleet}] * {fleet-guide}/integrations.html[{integrations}] -* <> -* <> +* <> +* <> diff --git a/docs/serverless/billing.asciidoc b/docs/serverless/billing.asciidoc index e9eb1a6492..9dcbb13318 100644 --- a/docs/serverless/billing.asciidoc +++ b/docs/serverless/billing.asciidoc @@ -40,7 +40,7 @@ Cloud Protection is an _optional_ add-on to Security Analytics that provides val Your total cost depends on the number of protected cloud workloads and other billable cloud assets you configure for use with Elastic Cloud Security. -For <>, billing is based on how many billable resources (`resource.id`s) you monitor. The following types of assets are considered billable: +For <>, billing is based on how many billable resources (`resource.id`s) you monitor. The following types of assets are considered billable: * VMs: + @@ -58,11 +58,11 @@ For <>, billing is based on how many billable resources (`resource.id ** **Azure:** SQL database, Cosmos DB, Synapse Analytics ** **GCP:** Cloud SQL, Firestore, BigQuery -For <>, billing is based on how many Kubernetes nodes (`agent.id`s) you monitor. +For <>, billing is based on how many Kubernetes nodes (`agent.id`s) you monitor. -For <>, billing is based on how many cloud assets (`cloud.instance.id`s) you monitor. +For <>, billing is based on how many cloud assets (`cloud.instance.id`s) you monitor. -For <>, billing is based on how many agents (`agent.id`s) you use. +For <>, billing is based on how many agents (`agent.id`s) you use. Logs, events, alerts, and configuration data ingested into your security project are billed using the **Ingest** and **Retention** pricing described above. diff --git a/docs/serverless/cloud-native-security/benchmark-rules.asciidoc b/docs/serverless/cloud-native-security/benchmark-rules.asciidoc index cafc3bbbdc..41b54be01b 100644 --- a/docs/serverless/cloud-native-security/benchmark-rules.asciidoc +++ b/docs/serverless/cloud-native-security/benchmark-rules.asciidoc @@ -1,4 +1,4 @@ -[[benchmark-rules]] +[[security-benchmark-rules]] = Benchmarks :description: Review the cloud security benchmark rules used by the CSPM and KSPM integrations. @@ -6,13 +6,13 @@ preview:[] -The Benchmarks page lets you view the cloud security posture (CSP) benchmarks for the <> (CSPM) and <> (KSPM) integrations. +The Benchmarks page lets you view the cloud security posture (CSP) benchmarks for the <> (CSPM) and <> (KSPM) integrations. [role="screenshot"] image::images/benchmark-rules/-cloud-native-security-benchmark-rules.png[Benchmark rules page] [discrete] -[[benchmark-rules-what-are-benchmarks]] +[[security-benchmark-rules-what-are-benchmarks]] == What are benchmarks? Each benchmark contains benchmark rules which are used by the CSPM and KSPM integrations to identify configuration risks in your cloud infrastructure. There are different benchmarks for different cloud services, such as AWS, GCP, or Azure. They are based on the Center for Internet Security's (CIS) https://www.cisecurity.org/cis-benchmarks/[secure configuration benchmarks]. @@ -24,7 +24,7 @@ Each benchmark rule checks to see if a specific type of resource is configured a * `Ensure IAM policies that allow full "*:*" administrative privileges are not attached` * `Ensure the default namespace is not in use` -When benchmark rules are evaluated, the resulting <> data appears on the <>. +When benchmark rules are evaluated, the resulting <> data appears on the <>. [NOTE] ==== @@ -32,7 +32,7 @@ Benchmark rules are not editable. ==== [discrete] -[[benchmark-rules-review-your-benchmarks]] +[[security-benchmark-rules-review-your-benchmarks]] == Review your benchmarks To access your active benchmarks, go to **Rules -> Benchmarks**. From there, you can click a benchmark's name to view the benchmark rules associated with it. You can click a benchmark rule's name to see details including information about how to remediate it, and related links. @@ -45,7 +45,7 @@ Disabling a benchmark rule automatically disables any associated detection rules ==== [discrete] -[[benchmark-rules-how-benchmark-rules-work]] +[[security-benchmark-rules-how-benchmark-rules-work]] == How benchmark rules work . When a security posture management integration is deployed, and every four hours after that, {agent} fetches relevant cloud resources. diff --git a/docs/serverless/cloud-native-security/cloud-native-security-overview.asciidoc b/docs/serverless/cloud-native-security/cloud-native-security-overview.asciidoc index 83879cfa2e..81f79340f8 100644 --- a/docs/serverless/cloud-native-security/cloud-native-security-overview.asciidoc +++ b/docs/serverless/cloud-native-security/cloud-native-security-overview.asciidoc @@ -1,4 +1,4 @@ -[[cloud-native-security-overview]] +[[security-cloud-native-security-overview]] = Secure cloud native resources :description: Helps you improve your cloud security posture. @@ -11,42 +11,42 @@ Elastic Security for Cloud helps you improve your cloud security posture by comp This page describes what each solution does and provides links to more information. [discrete] -[[cloud-native-security-overview-cloud-security-posture-management-cspm]] +[[security-cloud-native-security-overview-cloud-security-posture-management-cspm]] == Cloud Security Posture Management (CSPM) Discovers and evaluates the services in your cloud environment — like storage, compute, IAM, and more — against configuration security guidelines defined by the https://www.cisecurity.org/[Center for Internet Security] (CIS) to help you identify and remediate risks that could undermine the confidentiality, integrity, and availability of your cloud data. -<>. +<>. [discrete] -[[cloud-native-security-overview-kubernetes-security-posture-management-kspm]] +[[security-cloud-native-security-overview-kubernetes-security-posture-management-kspm]] == Kubernetes Security Posture Management (KSPM) Allows you to identify configuration risks in the various components that make up your Kubernetes cluster. It does this by evaluating your Kubernetes clusters against secure configuration guidelines defined by the Center for Internet Security (CIS) and generating findings with step-by-step instructions for remediating potential security risks. -<>. +<>. [discrete] -[[cloud-native-security-overview-cloud-native-vulnerability-management-cnvm]] +[[security-cloud-native-security-overview-cloud-native-vulnerability-management-cnvm]] == Cloud Native Vulnerability Management (CNVM) Scans your cloud workloads for known vulnerabilities. When it finds a vulnerability, it supports your risk assessment by quickly providing information such as the vulnerability's CVSS and severity, which software versions it affects, and whether a fix is available. -<>. +<>. [discrete] -[[cloud-native-security-overview-cloud-workload-protection-for-kubernetes]] +[[security-cloud-native-security-overview-cloud-workload-protection-for-kubernetes]] == Cloud Workload Protection for Kubernetes Provides cloud-native runtime protections for containerized environments by identifying and (optionally) blocking unexpected system behavior in Kubernetes containers. These capabilities are sometimes referred to as container drift detection and prevention. The solution also captures detailed process and file telemetry from monitored containers, allowing you to set up custom alerts and protection rules. -<>. +<>. [discrete] -[[cloud-native-security-overview-cloud-workload-protection-for-vms]] +[[security-cloud-native-security-overview-cloud-workload-protection-for-vms]] == Cloud Workload Protection for VMs Helps you monitor and protect your Linux VMs. It uses {elastic-defend} to instantly detect and prevent malicious behavior and malware, and captures workload telemetry data for process, file, and network activity. You can use this data with Elastic's out-of-the-box detection rules and {ml} models. These detections generate alerts that quickly help you identify and remediate threats. -<>. +<>. diff --git a/docs/serverless/cloud-native-security/cloud-workload-protection.asciidoc b/docs/serverless/cloud-native-security/cloud-workload-protection.asciidoc index 3b459a08c8..1ef94fb8a9 100644 --- a/docs/serverless/cloud-native-security/cloud-workload-protection.asciidoc +++ b/docs/serverless/cloud-native-security/cloud-workload-protection.asciidoc @@ -1,4 +1,4 @@ -[[cloud-workload-protection]] +[[security-cloud-workload-protection]] = Cloud workload protection for VMs :description: Use cloud workload protection to monitor and protect your Linux VMs. @@ -6,12 +6,12 @@ preview:[] -Cloud workload protection helps you monitor and protect your Linux VMs. It uses the <> integration to capture cloud workload telemetry containing process, file, and network activity. +Cloud workload protection helps you monitor and protect your Linux VMs. It uses the <> integration to capture cloud workload telemetry containing process, file, and network activity. Use this telemetry with out-of-the-box detection rules and machine learning models to automate processes that identify cloud threats. [discrete] -[[cloud-workload-protection-use-cases]] +[[security-cloud-workload-protection-use-cases]] == Use cases * **Runtime monitoring of cloud workloads:** Provides visibility into cloud workloads, context for detected threats, and the historical data needed for retroactive threat investigations. @@ -20,7 +20,7 @@ Use this telemetry with out-of-the-box detection rules and machine learning mode To continue setting up your cloud workload protection, learn more about: -* <>: configure {elastic-defend} to protect your hosts. Be sure to select one of the "Cloud workloads" presets if you want to collect session data by default, including process, file, and network telemetry. -* <>: examine Linux process data organized in a tree-like structure according to the Linux logical event model, with processes organized by parentage and time of execution. Use it to monitor and investigate session activity, and to understand user and service behavior on your Linux infrastructure. -* <>: Explore an overview of your protected Kubernetes clusters, and drill down into individual sessions within your Kubernetes infrastructure. -* <>: Capture the environment variables associated with process events, such as `PATH`, `LD_PRELOAD`, or `USER`. +* <>: configure {elastic-defend} to protect your hosts. Be sure to select one of the "Cloud workloads" presets if you want to collect session data by default, including process, file, and network telemetry. +* <>: examine Linux process data organized in a tree-like structure according to the Linux logical event model, with processes organized by parentage and time of execution. Use it to monitor and investigate session activity, and to understand user and service behavior on your Linux infrastructure. +* <>: Explore an overview of your protected Kubernetes clusters, and drill down into individual sessions within your Kubernetes infrastructure. +* <>: Capture the environment variables associated with process events, such as `PATH`, `LD_PRELOAD`, or `USER`. diff --git a/docs/serverless/cloud-native-security/cspm-findings-page.asciidoc b/docs/serverless/cloud-native-security/cspm-findings-page.asciidoc index 2c2b6106ff..6e8a3d3578 100644 --- a/docs/serverless/cloud-native-security/cspm-findings-page.asciidoc +++ b/docs/serverless/cloud-native-security/cspm-findings-page.asciidoc @@ -1,4 +1,4 @@ -[[cspm-findings-page]] +[[security-cspm-findings-page]] = Findings page :description: Review your cloud security posture management data. @@ -6,7 +6,7 @@ preview:[] -The **Misconfigurations** tab on the Findings page displays the configuration risks identified by the <> and <> integrations. +The **Misconfigurations** tab on the Findings page displays the configuration risks identified by the <> and <> integrations. [role="screenshot"] image::images/findings-page/-cloud-native-security-findings-page.png[Findings page] @@ -24,7 +24,7 @@ CSPM and KSPM findings indicate whether a given resource passed or failed evalua By default, the Findings page lists all findings, without grouping or filtering. [discrete] -[[cspm-findings-page-group-findings]] +[[security-cspm-findings-page-group-findings]] === Group findings Click **Group findings by** to group your data by a field. Select one of the suggested fields or **Custom field** to choose your own. You can select up to three group fields at once. @@ -47,7 +47,7 @@ You can filter findings data in two ways: * **In-table value filters**: Hover over a finding to display available inline actions. Use the **Filter In** (plus) and **Filter Out** (minus) buttons. [discrete] -[[cspm-findings-page-customize-the-findings-table]] +[[security-cspm-findings-page-customize-the-findings-table]] == Customize the Findings table You can use the toolbar buttons in the upper-left of the Findings table to select which columns appear: diff --git a/docs/serverless/cloud-native-security/cspm-get-started-azure.asciidoc b/docs/serverless/cloud-native-security/cspm-get-started-azure.asciidoc index b811a3381b..e0062b2713 100644 --- a/docs/serverless/cloud-native-security/cspm-get-started-azure.asciidoc +++ b/docs/serverless/cloud-native-security/cspm-get-started-azure.asciidoc @@ -1,4 +1,4 @@ -[[cspm-get-started-azure]] +[[security-cspm-get-started-azure]] = Get started with CSPM for Azure :description: Start monitoring the security posture of your Azure cloud assets. diff --git a/docs/serverless/cloud-native-security/cspm-get-started-gcp.asciidoc b/docs/serverless/cloud-native-security/cspm-get-started-gcp.asciidoc index 441ed59aa5..0ef54f94b7 100644 --- a/docs/serverless/cloud-native-security/cspm-get-started-gcp.asciidoc +++ b/docs/serverless/cloud-native-security/cspm-get-started-gcp.asciidoc @@ -1,4 +1,4 @@ -[[cspm-get-started-gcp]] +[[security-cspm-get-started-gcp]] = Get started with CSPM for GCP :description: Start monitoring the security posture of your GCP cloud assets. diff --git a/docs/serverless/cloud-native-security/cspm-get-started.asciidoc b/docs/serverless/cloud-native-security/cspm-get-started.asciidoc index 802795ade1..df3b2b27c2 100644 --- a/docs/serverless/cloud-native-security/cspm-get-started.asciidoc +++ b/docs/serverless/cloud-native-security/cspm-get-started.asciidoc @@ -1,4 +1,4 @@ -[[cspm-get-started]] +[[security-cspm-get-started]] = Get started with CSPM for AWS :description: Start monitoring the security posture of your AWS cloud assets. diff --git a/docs/serverless/cloud-native-security/cspm-security-posture-faq.asciidoc b/docs/serverless/cloud-native-security/cspm-security-posture-faq.asciidoc index 0278dc1130..05a9b149df 100644 --- a/docs/serverless/cloud-native-security/cspm-security-posture-faq.asciidoc +++ b/docs/serverless/cloud-native-security/cspm-security-posture-faq.asciidoc @@ -1,4 +1,4 @@ -[[cspm-security-posture-faq]] +[[security-cspm-security-posture-faq]] = Frequently asked questions (FAQ) :description: Frequently asked questions about the CSPM and KSPM integrations. @@ -7,6 +7,7 @@ preview:[] [discrete] +[[cspm-security-posture-faq]] == CSPM FAQ Frequently asked questions about the Cloud Security Posture Management (CSPM) integration and features. @@ -28,7 +29,7 @@ After you deploy the CSPM integration, it can take up to 10 minutes for resource Newly unenrolled cloud accounts can take a maximum of 24 hours to disappear from the Cloud Security Posture dashboard. [discrete] -[[cspm-security-posture-faq-kspm-faq]] +[[security-cspm-security-posture-faq-kspm-faq]] == KSPM FAQ Frequently asked questions about the Kubernetes Security Posture Management (KSPM) integration and features. @@ -40,7 +41,7 @@ For self-managed/vanilla clusters, Kubernetes version 1.23 is supported. For EKS clusters, all Kubernetes versions available at the time of cluster deployment are supported. **Do benchmark rules support multiple Kubernetes deployment types?** -Yes. There are different sets of benchmark rules for self-managed and third party-managed deployments. Refer to <> for more information about setting up each deployment type. +Yes. There are different sets of benchmark rules for self-managed and third party-managed deployments. Refer to <> for more information about setting up each deployment type. **Can I evaluate the security posture of my Amazon EKS clusters?** Yes. KSPM currently supports the security posture evaluation of Amazon EKS and unmanaged Kubernetes clusters. @@ -55,7 +56,7 @@ It can take up to 10 minutes for deployment, resource fetching, evaluation, and A cluster will disappear as soon as the KSPM integration fetches data while that cluster is not enrolled. The fetch process repeats every four hours, which means a newly unenrolled cluster can take a maximum of four hours to disappear from the dashboard. [discrete] -[[cspm-security-posture-faq-findings-page]] +[[security-cspm-security-posture-faq-findings-page]] == Findings page **Are all the findings page current?** @@ -71,7 +72,7 @@ You can access findings data using the following index patterns: * **Historical findings:** `logs-cloud_security_posture.findings-*` [discrete] -[[cspm-security-posture-faq-benchmark-rules]] +[[security-cspm-security-posture-faq-benchmark-rules]] == Benchmark rules **How often are my resources evaluated against benchmark rules?** diff --git a/docs/serverless/cloud-native-security/cspm.asciidoc b/docs/serverless/cloud-native-security/cspm.asciidoc index 984f4bd190..762489e99f 100644 --- a/docs/serverless/cloud-native-security/cspm.asciidoc +++ b/docs/serverless/cloud-native-security/cspm.asciidoc @@ -1,4 +1,4 @@ -[[cspm]] +[[security-cspm]] = Cloud security posture management :description: Identify misconfigured cloud resources. @@ -8,7 +8,7 @@ preview:[] The Cloud Security Posture Management (CSPM) feature discovers and evaluates the services in your cloud environment — like storage, compute, IAM, and more — against configuration security guidelines defined by the https://www.cisecurity.org/[Center for Internet Security] (CIS) to help you identify and remediate risks that could undermine the confidentiality, integrity, and availability of your cloud data. -This feature currently supports Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure. For step-by-step getting started guides, refer to <>, <>, or <>. +This feature currently supports Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure. For step-by-step getting started guides, refer to <>, <>, or <>. .Requirements [NOTE] @@ -22,4 +22,4 @@ This feature currently supports Amazon Web Services (AWS), Google Cloud Platform == How CSPM works Using the read-only credentials you will provide during the setup process, it will evaluate the configuration of resources in your environment every 24 hours. -After each evaluation, the integration sends findings to Elastic. A high-level summary of the findings appears on the <>, and detailed findings appear on the <>. +After each evaluation, the integration sends findings to Elastic. A high-level summary of the findings appears on the <>, and detailed findings appear on the <>. diff --git a/docs/serverless/cloud-native-security/d4c-get-started.asciidoc b/docs/serverless/cloud-native-security/d4c-get-started.asciidoc index 4d8aa021ad..c987d56f05 100644 --- a/docs/serverless/cloud-native-security/d4c-get-started.asciidoc +++ b/docs/serverless/cloud-native-security/d4c-get-started.asciidoc @@ -1,4 +1,4 @@ -[[d4c-get-started]] +[[security-d4c-get-started]] = Get started with CWP :description: Secure your containerized workloads and start detecting threats and vulnerabilities. @@ -17,14 +17,14 @@ This page describes how to set up Cloud Workload Protection (CWP) for Kubernetes ==== [discrete] -[[d4c-get-started-initial-setup]] +[[security-d4c-get-started-initial-setup]] == Initial setup First, you'll need to deploy Elastic's Defend for Containers integration to the Kubernetes clusters you wish to monitor. . Go to **Assets → Cloud**, then click **Add D4C Integration**. . Name the integration. The default name, which you can change, is `cloud_defend-1`. -. Optional — make any desired changes to the integration's policy by adjusting the **Selectors** and **Responses** sections. (For more information, refer to the <>). You can also change these later. +. Optional — make any desired changes to the integration's policy by adjusting the **Selectors** and **Responses** sections. (For more information, refer to the <>). You can also change these later. . Under **Where to add this integration**, select an existing or new agent policy. . Click **Save & Continue**, then **Add {agent} to your hosts**. . On the {agent} policy page, click **Add agent** to open the Add agent flyout. @@ -49,7 +49,7 @@ First, you'll need to deploy Elastic's Defend for Containers integration to the One of the <> sends process telemetry events (`fork` and `exec`) to {es}. -In order to detect threats using this data, you'll need active <>. Elastic has prebuilt detection rules designed for this data. (You can also create your own <>.) +In order to detect threats using this data, you'll need active <>. Elastic has prebuilt detection rules designed for this data. (You can also create your own <>.) To install and enable the prebuilt rules: diff --git a/docs/serverless/cloud-native-security/d4c-overview.asciidoc b/docs/serverless/cloud-native-security/d4c-overview.asciidoc index 855ea01a24..03fb26535e 100644 --- a/docs/serverless/cloud-native-security/d4c-overview.asciidoc +++ b/docs/serverless/cloud-native-security/d4c-overview.asciidoc @@ -1,4 +1,4 @@ -[[d4c-overview]] +[[security-d4c-overview]] = Container workload protection :description: Identify and block unexpected system behavior in Kubernetes containers. @@ -15,25 +15,25 @@ Elastic Cloud Workload Protection (CWP) for Kubernetes provides cloud-native run == Use cases [discrete] -[[d4c-overview-threat-detection-and-threat-hunting]] +[[security-d4c-overview-threat-detection-and-threat-hunting]] === Threat detection & threat hunting CWP for Kubernetes sends system events from your containers to {es}. {elastic-sec}'s prebuilt security rules include many designed to detect malicious behavior in container runtimes. These can help you detect events that should never occur in containers, such as reverse shell executions, privilege escalation, container escape attempts, and more. [discrete] -[[d4c-overview-drift-detection-and-prevention]] +[[security-d4c-overview-drift-detection-and-prevention]] === Drift detection & prevention Cloud-native containers should be immutable, meaning that their file systems should not change during normal operations. By leveraging this principle, security teams can detect unusual system behavior with a high degree of accuracy — without relying on more resource-intensive techniques like memory scanning or attack signature detection. Elastic’s Drift Detection mechanism has a low rate of false positives, so you can deploy it in most environments without worrying about creating excessive alerts. [discrete] -[[d4c-overview-workload-protection-policies]] +[[security-d4c-overview-workload-protection-policies]] === Workload protection policies CWP for Kubernetes uses a flexible policy language to restrict container workloads to a set of allowlisted capabilities chosen by you. When employed with Drift and Threat Detection, this can provide multiple layers of defense. [discrete] -[[d4c-overview-support-matrix]] +[[security-d4c-overview-support-matrix]] == Support matrix: |=== @@ -73,7 +73,7 @@ CWP for Kubernetes uses a flexible policy language to restrict container workloa |=== [discrete] -[[d4c-overview-how-cwp-for-kubernetes-works]] +[[security-d4c-overview-how-cwp-for-kubernetes-works]] == How CWP for Kubernetes works CWP for Kubernetes uses a lightweight integration, Defend for Containers (D4C). When you set up the D4C integration, it gets deployed by {agent}. Specifically, the {agent} is installed as a DaemonSet on your Kubernetes clusters, where it enables D4C to use eBPF Linux Security Modules (https://docs.kernel.org/bpf/prog_lsm.html[LSM]) and tracepoint probes to record system events. Events are evaluated against LSM hook points, enabling {agent} to evaluate system activity against your policy before allowing it to proceed. @@ -84,5 +84,5 @@ The default D4C policy sends data about all running processes to your {es} clust [IMPORTANT] ==== -To learn more about D4C policies, including how to create your own, refer to the <>. +To learn more about D4C policies, including how to create your own, refer to the <>. ==== diff --git a/docs/serverless/cloud-native-security/d4c-policy-guide.asciidoc b/docs/serverless/cloud-native-security/d4c-policy-guide.asciidoc index 7463f6f386..84af0b30bf 100644 --- a/docs/serverless/cloud-native-security/d4c-policy-guide.asciidoc +++ b/docs/serverless/cloud-native-security/d4c-policy-guide.asciidoc @@ -1,4 +1,4 @@ -[[d4c-policy-guide]] +[[security-d4c-policy-guide]] = Container workload protection policies :description: Learn to build policies for cloud workload protection for Kubernetes. @@ -32,7 +32,7 @@ image::images/d4c-policy-guide/-cloud-native-security-d4c-policy-editor.png[The A selector requires a name and at least one operation. It will select all events of the specified operation types, unless you also include _conditions_ to narrow down the selection. Some conditions are available for both `file` and `process` selectors, while others only available for one type of selector. [discrete] -[[d4c-policy-guide-common-conditions]] +[[security-d4c-policy-guide-common-conditions]] === Common conditions These conditions are available for both `file` and `process` selectors. @@ -68,7 +68,7 @@ These conditions are available for both `file` and `process` selectors. |=== [discrete] -[[d4c-policy-guide-file-selector-conditions]] +[[security-d4c-policy-guide-file-selector-conditions]] === File-selector conditions These conditions are available only for `file` selectors. @@ -97,7 +97,7 @@ In order to ensure precise targeting of file integrity monitoring operations, a ==== [discrete] -[[d4c-policy-guide-process-selector-conditions]] +[[security-d4c-policy-guide-process-selector-conditions]] === Process-selector conditions These conditions are available only for `process` selectors. @@ -121,7 +121,7 @@ These conditions are available only for `process` selectors. |=== [discrete] -[[d4c-policy-guide-response-fields]] +[[security-d4c-policy-guide-response-fields]] === Response fields A policy can include one or more responses. Each response is comprised of the following fields: @@ -142,7 +142,7 @@ A policy can include one or more responses. Each response is comprised of the fo |=== [discrete] -[[d4c-policy-guide-response-actions]] +[[security-d4c-policy-guide-response-actions]] === Response actions D4C responses can include the following actions: diff --git a/docs/serverless/cloud-native-security/enable-cloudsec.asciidoc b/docs/serverless/cloud-native-security/enable-cloudsec.asciidoc index 2edfe856a9..0936736e9b 100644 --- a/docs/serverless/cloud-native-security/enable-cloudsec.asciidoc +++ b/docs/serverless/cloud-native-security/enable-cloudsec.asciidoc @@ -1,4 +1,4 @@ -[[enable-cloudsec]] +[[security-enable-cloudsec]] = Enable cloud security features :description: Learn to turn on cloud security features in your project diff --git a/docs/serverless/cloud-native-security/environment-variable-capture.asciidoc b/docs/serverless/cloud-native-security/environment-variable-capture.asciidoc index 5d3f9fa83e..85323cb685 100644 --- a/docs/serverless/cloud-native-security/environment-variable-capture.asciidoc +++ b/docs/serverless/cloud-native-security/environment-variable-capture.asciidoc @@ -1,4 +1,4 @@ -[[environment-variable-capture]] +[[security-environment-variable-capture]] = Capture environment variables :description: Capture environment variables from monitored Linux sessions. diff --git a/docs/serverless/cloud-native-security/get-started-with-kspm.asciidoc b/docs/serverless/cloud-native-security/get-started-with-kspm.asciidoc index 27a2d2f3d5..7d22128fc6 100644 --- a/docs/serverless/cloud-native-security/get-started-with-kspm.asciidoc +++ b/docs/serverless/cloud-native-security/get-started-with-kspm.asciidoc @@ -1,4 +1,4 @@ -[[get-started-with-kspm]] +[[security-get-started-with-kspm]] = Get started with KSPM :keywords: serverless, security, overview, cloud security @@ -37,7 +37,7 @@ The instructions differ depending on whether you're installing on EKS or on unma == Set up KSPM for Amazon EKS clusters [discrete] -[[get-started-with-kspm-name-your-integration-and-select-a-kubernetes-deployment-type]] +[[security-get-started-with-kspm-name-your-integration-and-select-a-kubernetes-deployment-type]] === Name your integration and select a Kubernetes Deployment type . Go to **Dashboards → Cloud Security Posture**. @@ -246,7 +246,7 @@ The **Add agent** wizard helps you deploy the KSPM integration on the Kubernetes . Download the manifest and make any necessary revisions to its configuration to suit the needs of your environment. . Apply the manifest using the `kubectl apply -f` command. For example: `kubectl apply -f elastic-agent-managed-kubernetes.yaml` -After a few minutes, a message confirming the {agent} enrollment appears, followed by a message confirming that data is incoming. You can then click **View assets** to see where the newly-collected configuration information appears, including the <> and the <>. +After a few minutes, a message confirming the {agent} enrollment appears, followed by a message confirming that data is incoming. You can then click **View assets** to see where the newly-collected configuration information appears, including the <> and the <>. [discrete] [[kspm-setup-unmanaged]] @@ -255,7 +255,7 @@ After a few minutes, a message confirming the {agent} enrollment appears, follow Follow these steps to deploy the KSPM integration to unmanaged clusters. Keep in mind credentials are NOT required for unmanaged deployments. [discrete] -[[get-started-with-kspm-configure-the-kspm-integration]] +[[security-get-started-with-kspm-configure-the-kspm-integration]] === Configure the KSPM integration To install the integration on unmanaged clusters: @@ -281,7 +281,7 @@ The **Add agent** wizard helps you deploy the KSPM integration on the Kubernetes . Download the manifest and make any necessary revisions to its configuration to suit the needs of your environment. . Apply the manifest using the `kubectl apply -f` command. For example: `kubectl apply -f elastic-agent-managed-kubernetes.yaml` -After a few minutes, a message confirming the {agent} enrollment appears, followed by a message confirming that data is incoming. You can then click **View assets** to see where the newly-collected configuration information appears, including the <> and the <>. +After a few minutes, a message confirming the {agent} enrollment appears, followed by a message confirming that data is incoming. You can then click **View assets** to see where the newly-collected configuration information appears, including the <> and the <>. [discrete] [[kspm-eck]] diff --git a/docs/serverless/cloud-native-security/kspm.asciidoc b/docs/serverless/cloud-native-security/kspm.asciidoc index eabf076a30..a74347bd55 100644 --- a/docs/serverless/cloud-native-security/kspm.asciidoc +++ b/docs/serverless/cloud-native-security/kspm.asciidoc @@ -1,4 +1,4 @@ -[[kspm]] +[[security-kspm]] = Kubernetes security posture management :description: Identify configuration risks in your Kubernetes clusters. @@ -13,7 +13,7 @@ preview:[] The Kubernetes Security Posture Management (KSPM) integration allows you to identify configuration risks in the various components that make up your Kubernetes cluster. It does this by evaluating your Kubernetes clusters against secure configuration guidelines defined by the Center for Internet Security (CIS) and generating findings with step-by-step instructions for remediating potential security risks. -This integration supports Amazon EKS and unmanaged Kubernetes clusters. For setup instructions, refer to <>. +This integration supports Amazon EKS and unmanaged Kubernetes clusters. For setup instructions, refer to <>. .Requirements [NOTE] @@ -33,7 +33,7 @@ This integration supports Amazon EKS and unmanaged Kubernetes clusters. For setu . When you add a KSPM integration, it generates a Kubernetes manifest. When applied to a cluster, the manifest deploys an {agent} as a https://kubernetes.io/docs/concepts/workloads/controllers/daemonset[DaemonSet] to ensure all nodes are evaluated. . Upon deployment, the integration immediately assesses the security posture of your Kubernetes resources. The evaluation process repeats every four hours. -. After each evaluation, the integration sends findings to {es}. Findings appear on the <> and the <> page. +. After each evaluation, the integration sends findings to {es}. Findings appear on the <> and the <> page. [discrete] [[kspm-use-cases]] @@ -51,7 +51,7 @@ The KSPM integration helps you to: To identify and remediate failed failed findings: -. Go to the <>. +. Go to the <>. . Click **View all failed findings**, either for an individual cluster or for all monitored clusters. . Click a failed finding. The findings flyout opens. . Follow the steps under **Remediation** to correct the misconfiguration. @@ -67,7 +67,7 @@ Remediation steps typically include commands for you to execute. These sometimes To identify the Kubernetes resources generating the most failed findings: -. Go to the <> page. +. Go to the <> page. . Click the **Group by** menu near the search box and select **Resource** to view a list of resources sorted by their total number of failed findings. . Click a resource ID to view the findings associated with that resource. @@ -77,7 +77,7 @@ To identify the Kubernetes resources generating the most failed findings: To identify risks in particular CIS sections: -. Go to the <> (**Dashboards → Cloud Security Posture**). +. Go to the <> (**Dashboards → Cloud Security Posture**). . In the Failed findings by CIS section widget, click the name of a CIS section to view all failed findings for that section. Alternatively: diff --git a/docs/serverless/cloud-native-security/security-posture-faq.asciidoc b/docs/serverless/cloud-native-security/security-posture-faq.asciidoc index 73f9c8f76b..844397a611 100644 --- a/docs/serverless/cloud-native-security/security-posture-faq.asciidoc +++ b/docs/serverless/cloud-native-security/security-posture-faq.asciidoc @@ -39,7 +39,7 @@ Frequently asked questions about the Kubernetes Security Posture Management (KSP For self-managed/vanilla clusters, Kubernetes version 1.23 is supported. **Do benchmark rules support multiple Kubernetes deployment types?** -Yes. There are different sets of benchmark rules for self-managed and third party-managed deployments. Refer to <> for more information about setting up each deployment type. +Yes. There are different sets of benchmark rules for self-managed and third party-managed deployments. Refer to <> for more information about setting up each deployment type. **Can I evaluate the security posture of my Amazon EKS clusters?** Yes. KSPM currently supports the security posture evaluation of Amazon EKS and unmanaged Kubernetes clusters. diff --git a/docs/serverless/cloud-native-security/security-posture-management.asciidoc b/docs/serverless/cloud-native-security/security-posture-management.asciidoc index 660c91f7eb..1c1338148f 100644 --- a/docs/serverless/cloud-native-security/security-posture-management.asciidoc +++ b/docs/serverless/cloud-native-security/security-posture-management.asciidoc @@ -9,7 +9,7 @@ preview:[] [discrete] == Overview -Elastic's <> (CSPM) and <> (KSPM) features help you discover and evaluate the services and resources in your cloud environment — like storage, compute, IAM, and more — against security guidelines defined by the Center for Internet Security (CIS). They help you identify and remediate configuration risks that could undermine the confidentiality, integrity, and availability of your cloud assets, such as publicly exposed storage buckets or overly permissive networking objects. +Elastic's <> (CSPM) and <> (KSPM) features help you discover and evaluate the services and resources in your cloud environment — like storage, compute, IAM, and more — against security guidelines defined by the Center for Internet Security (CIS). They help you identify and remediate configuration risks that could undermine the confidentiality, integrity, and availability of your cloud assets, such as publicly exposed storage buckets or overly permissive networking objects. The KSPM feature assesses the security of your Kubernetes assets, while the CSPM feature assesses the security of your AWS resources such as storage, compute, IAM, and more. @@ -19,8 +19,8 @@ The KSPM feature assesses the security of your Kubernetes assets, while the CSPM For setup instructions, refer to: -* <> -* <> +* <> +* <> [discrete] [[security-posture-use-cases]] diff --git a/docs/serverless/cloud-native-security/session-view.asciidoc b/docs/serverless/cloud-native-security/session-view.asciidoc index f5465ca41c..e398d6c4be 100644 --- a/docs/serverless/cloud-native-security/session-view.asciidoc +++ b/docs/serverless/cloud-native-security/session-view.asciidoc @@ -1,4 +1,4 @@ -[[session-view]] +[[security-session-view]] = Session View :description: Examine Linux process data in context with Session View. @@ -22,7 +22,7 @@ Session View has the following features: [NOTE] ==== -To view Linux session data from your Kubernetes infrastructure, you'll need to set up the <>. +To view Linux session data from your Kubernetes infrastructure, you'll need to set up the <>. ==== [discrete] diff --git a/docs/serverless/cloud-native-security/vuln-management-faq.asciidoc b/docs/serverless/cloud-native-security/vuln-management-faq.asciidoc index ad53c2f657..92e5139881 100644 --- a/docs/serverless/cloud-native-security/vuln-management-faq.asciidoc +++ b/docs/serverless/cloud-native-security/vuln-management-faq.asciidoc @@ -1,4 +1,4 @@ -[[vuln-management-faq]] +[[security-vuln-management-faq]] = Frequently asked questions (FAQ) :description: Frequently asked questions about the CNVM integration. diff --git a/docs/serverless/cloud-native-security/vuln-management-findings.asciidoc b/docs/serverless/cloud-native-security/vuln-management-findings.asciidoc index 23c88e842b..09feb01727 100644 --- a/docs/serverless/cloud-native-security/vuln-management-findings.asciidoc +++ b/docs/serverless/cloud-native-security/vuln-management-findings.asciidoc @@ -1,4 +1,4 @@ -[[vuln-management-findings]] +[[security-vuln-management-findings]] = Findings page :description: The Findings page displays information about cloud vulnerabilities found in your environment. @@ -6,13 +6,13 @@ preview:[] -The **Vulnerabilities** tab on the Findings page displays the vulnerabilities detected by the <>. +The **Vulnerabilities** tab on the Findings page displays the vulnerabilities detected by the <>. [role="screenshot"] image::images/vuln-management-findings/-cloud-native-security-cnvm-findings-page.png[The Vulnerabilities tab of the Findings page] [discrete] -[[vuln-management-findings-what-are-cnvm-findings]] +[[security-vuln-management-findings-what-are-cnvm-findings]] == What are CNVM findings? CNVM findings represent security vulnerabilities detected in your cloud. They include metadata such as the CVE identifier, CVSS score, severity, affected package, and fix version if available, as well as information about impacted systems. @@ -26,7 +26,7 @@ Clicking on a finding provides a detailed description of the vulnerability, and To help you prioritize remediation efforts, you can organize findings in various ways. [discrete] -[[vuln-management-findings-group-findings]] +[[security-vuln-management-findings-group-findings]] === Group findings Click **Group vulnerabilities by** to group your data by a field. Select one of the suggested fields or **Custom field** to choose your own. You can select up to three group fields at once. @@ -43,7 +43,7 @@ Multiple groupings apply to your data in the order you selected them. For exampl image::images/vuln-management-findings/-cloud-native-security-cnvm-findings-grouped.png[The Vulnerabilities tab of the Findings page] [discrete] -[[vuln-management-findings-filter-findings]] +[[security-vuln-management-findings-filter-findings]] === Filter findings You can filter the data in two ways: @@ -52,7 +52,7 @@ You can filter the data in two ways: * **In-table value filters**: Hover over a finding to display available inline actions. Use the **Filter In** (plus) and **Filter Out** (minus) buttons. [discrete] -[[vuln-management-findings-customize-the-findings-table]] +[[security-vuln-management-findings-customize-the-findings-table]] === Customize the Findings table When grouping is turned off, you can use the toolbar buttons in the upper-left of the Findings table to select which columns appear: @@ -67,7 +67,7 @@ You can also click a column's name to open a menu that allows you to perform mul ==== [discrete] -[[vuln-management-findings-learn-more-about-a-vulnerability]] +[[security-vuln-management-findings-learn-more-about-a-vulnerability]] == Learn more about a vulnerability Click a vulnerability to open the vulnerability details flyout. This flyout includes a link to the related vulnerability database, the vulnerability's publication date, CVSS vector strings, fix versions (if available), and more. diff --git a/docs/serverless/cloud-native-security/vuln-management-get-started.asciidoc b/docs/serverless/cloud-native-security/vuln-management-get-started.asciidoc index a594a99294..b142a08e5d 100644 --- a/docs/serverless/cloud-native-security/vuln-management-get-started.asciidoc +++ b/docs/serverless/cloud-native-security/vuln-management-get-started.asciidoc @@ -1,4 +1,4 @@ -[[vuln-management-get-started]] +[[security-vuln-management-get-started]] = Get started with CNVM :description: Set up cloud native vulnerability management. @@ -74,4 +74,4 @@ The integration will only scan VMs in the region you select. To scan multiple re image::images/vuln-management-get-started/-dashboards-cnvm-cloudformation.png[The cloud formation template] . Click **Create stack**. To avoid authentication problems, you can only make configuration changes to the VM InstanceType, which you could make larger to increase scanning speed. . Wait for the confirmation that {agent} was enrolled. -. Your data will start to appear on the **Vulnerabilities** tab of the <>. +. Your data will start to appear on the **Vulnerabilities** tab of the <>. diff --git a/docs/serverless/cloud-native-security/vuln-management-overview.asciidoc b/docs/serverless/cloud-native-security/vuln-management-overview.asciidoc index 947111ebc4..4524eacdd7 100644 --- a/docs/serverless/cloud-native-security/vuln-management-overview.asciidoc +++ b/docs/serverless/cloud-native-security/vuln-management-overview.asciidoc @@ -1,4 +1,4 @@ -[[vuln-management-overview]] +[[security-vuln-management-overview]] = Cloud native vulnerability management :description: Find and track vulnerabilities in your cloud. @@ -8,7 +8,7 @@ preview:[] Elastic's Cloud Native Vulnerability Management (CNVM) feature helps you identify known vulnerabilities in your cloud workloads. -Setup uses infrastructure as code. For instructions, refer to <>. +Setup uses infrastructure as code. For instructions, refer to <>. [NOTE] ==== @@ -33,7 +33,7 @@ During setup, you will use an infrastructure as code provisioning template to cr The CNVM integration uses https://github.com/aquasecurity/trivy[Trivy], a comprehensive open-source security scanner, to scan cloud workloads and identify security vulnerabilities. During each scan, the VM running the integration takes a snapshot of all cloud workloads in its region using the snapshot APIs of the cloud service provider, and analyzes them for vulnerabilities using Trivy. Therefore, scanning does not use resources on the VMs being scanned. All resource usage occurs on the VM installed during CNVM setup. -The scanning process begins immediately upon deployment, then repeats every twenty-four hours. After each scan, the integration sends the discovered vulnerabilities to {es}, where they appear in the **Vulnerabilities** tab of the <>. +The scanning process begins immediately upon deployment, then repeats every twenty-four hours. After each scan, the integration sends the discovered vulnerabilities to {es}, where they appear in the **Vulnerabilities** tab of the <>. [NOTE] ==== diff --git a/docs/serverless/dashboards/cloud-posture-dashboard-dash.asciidoc b/docs/serverless/dashboards/cloud-posture-dashboard-dash.asciidoc index c2fbc91f62..6cdbf09a45 100644 --- a/docs/serverless/dashboards/cloud-posture-dashboard-dash.asciidoc +++ b/docs/serverless/dashboards/cloud-posture-dashboard-dash.asciidoc @@ -1,4 +1,4 @@ -[[cloud-posture-dashboard-dash]] +[[security-cloud-posture-dashboard-dash]] = Cloud Security Posture dashboard :description: The Cloud Security Posture dashboard summarizes your cloud infrastructure's performance on CIS security benchmarks. @@ -10,7 +10,7 @@ preview:[] -The Cloud Security Posture dashboard summarizes your cloud infrastructure's overall performance against <> defined by the Center for Internet Security (CIS). To start collecting this data, refer to <> or <>. +The Cloud Security Posture dashboard summarizes your cloud infrastructure's overall performance against <> defined by the Center for Internet Security (CIS). To start collecting this data, refer to <> or <>. [role="screenshot"] image::images/cloud-posture-dashboard/-dashboards-cloud-sec-dashboard.png[The cloud Security dashboard] @@ -27,7 +27,7 @@ The Cloud Security Posture dashboard shows: At the top of the dashboard, you can switch between the Cloud accounts and Kubernetes cluster views. -The top section of either view summarizes your overall cloud security posture (CSP) by aggregating data from all monitored resources. The summary cards on the left show the number of cloud accounts or clusters evaluated, and the number of resources evaluated. You can click **Enroll more accounts** or **Enroll more clusters** to deploy to additional cloud assets. Click **View all resources** to open the <>. +The top section of either view summarizes your overall cloud security posture (CSP) by aggregating data from all monitored resources. The summary cards on the left show the number of cloud accounts or clusters evaluated, and the number of resources evaluated. You can click **Enroll more accounts** or **Enroll more clusters** to deploy to additional cloud assets. Click **View all resources** to open the <>. The remaining summary cards show your overall compliance score, and your compliance score for each CIS section. Click **View all failed findings** to view all failed findings, or click a CIS section name to view failed findings from only that section on the Findings page. diff --git a/docs/serverless/dashboards/dashboards-overview.asciidoc b/docs/serverless/dashboards/dashboards-overview.asciidoc index 4568530413..9223234fc0 100644 --- a/docs/serverless/dashboards/dashboards-overview.asciidoc +++ b/docs/serverless/dashboards/dashboards-overview.asciidoc @@ -1,4 +1,4 @@ -[[dashboards-overview]] +[[security-dashboards-overview]] = Dashboards :description: Dashboards give you insight into your security environment. diff --git a/docs/serverless/dashboards/data-quality-dash.asciidoc b/docs/serverless/dashboards/data-quality-dash.asciidoc index 9cb4bba8d3..cde81a5eb5 100644 --- a/docs/serverless/dashboards/data-quality-dash.asciidoc +++ b/docs/serverless/dashboards/data-quality-dash.asciidoc @@ -1,4 +1,4 @@ -[[data-quality-dash]] +[[security-data-quality-dash]] = Data Quality dashboard :description: The Data Quality dashboard summarizes the health of your data ingest pipeline. @@ -48,7 +48,7 @@ To customize which indices are checked when you click **Check all**, {security-g * **Check a single index**: To check a single index, click the **Check now** button under **Actions**. Checking a single index is faster than checking all indices. [discrete] -[[data-quality-dash-visualize-checked-indices]] +[[security-data-quality-dash-visualize-checked-indices]] == Visualize checked indices The treemap that appears at the top of the dashboard shows the relative document count of your indices. The color of each index's node refers to its status: @@ -60,7 +60,7 @@ The treemap that appears at the top of the dashboard shows the relative document Click a node in the treemap to expand the corresponding index. [discrete] -[[data-quality-dash-learn-more-about-checked-index-fields]] +[[security-data-quality-dash-learn-more-about-checked-index-fields]] == Learn more about checked index fields After an index is checked, a `Pass` or `Fail` status appears. `Fail` indicates mapping problems in an index. To view index check details, including which fields weren't successfully mapped, click the **Check now** button under **Actions**. @@ -76,7 +76,7 @@ Fields in the Same family category have the correct search behavior, but might h ==== [discrete] -[[data-quality-dash-view-historical-data-quality-results]] +[[security-data-quality-dash-view-historical-data-quality-results]] == View historical data quality results You can review an index's data quality history by clicking **View history** under **Actions**, or by clicking the **History** tab in the details flyout. You can filter the results by time and **Pass** / **Fail** status. Click a historical check to expand it and view more details. @@ -90,7 +90,7 @@ Recent historical data includes the **Incompatible fields** and **Same family** ==== [discrete] -[[data-quality-dash-export-data-quality-results]] +[[security-data-quality-dash-export-data-quality-results]] == Export data quality results You can share data quality results to help track your team's remediation efforts. First, follow the instructions under <> to generate results, then either: @@ -98,13 +98,13 @@ You can share data quality results to help track your team's remediation efforts **Export results for all indices in the current data view**: . At the top of the dashboard, under the **Check all** button, are two buttons that allow you to share results. Exported results include all the data which appears in the dashboard. -. Click **Add to new case** to open a new <>. +. Click **Add to new case** to open a new <>. . Click **Copy to clipboard** to copy a Markdown report to your clipboard. **Export results for one index**: . View details for a checked index by clicking the **Check now** button under **Actions**. -. From the **Incompatible fields** tab, select **Add to new case** to open a new <>, or click **Copy to clipboard** to copy a Markdown report to your clipboard. +. From the **Incompatible fields** tab, select **Add to new case** to open a new <>, or click **Copy to clipboard** to copy a Markdown report to your clipboard. [NOTE] ==== diff --git a/docs/serverless/dashboards/detection-entity-dashboard.asciidoc b/docs/serverless/dashboards/detection-entity-dashboard.asciidoc index 5ff50cdb88..4683f965e2 100644 --- a/docs/serverless/dashboards/detection-entity-dashboard.asciidoc +++ b/docs/serverless/dashboards/detection-entity-dashboard.asciidoc @@ -1,4 +1,4 @@ -[[detection-entity-dashboard]] +[[security-detection-entity-dashboard]] = Entity Analytics dashboard :description: The Entity Analytics dashboard provides a centralized view of emerging insider threats @@ -15,7 +15,7 @@ The Entity Analytics dashboard provides a centralized view of emerging insider t .Requirements [NOTE] ==== -To display host and user risk scores, you must <>. +To display host and user risk scores, you must <>. ==== The dashboard includes the following sections: @@ -51,7 +51,7 @@ Interact with the table to filter data, view more details, and take action: * Click **View all** in the upper-right to display all host risk information on the Hosts page. * Click the number link in the **Alerts** column to view the alerts on the Alerts page. Hover over the number and select **Investigate in timeline** (image:images/icons/timeline.svg[Timeline]) to launch Timeline with a query that includes the associated host name value. -For more information about host risk scores, refer to <>. +For more information about host risk scores, refer to <>. [discrete] [[entity-user-risk-scores]] @@ -70,7 +70,7 @@ Interact with the table to filter data, view more details, and take action: * Click **View all** in the upper-right to display all user risk information on the Users page. * Click the number link in the **Alerts** column to view the alerts on the Alerts page. Hover over the number and select **Investigate in timeline** (image:images/icons/timeline.svg[Timeline]) to launch Timeline with a query that includes the associated user name value. -For more information about user risk scores, refer to <>. +For more information about user risk scores, refer to <>. [discrete] [[entity-anomalies]] diff --git a/docs/serverless/dashboards/detection-response-dashboard.asciidoc b/docs/serverless/dashboards/detection-response-dashboard.asciidoc index 89e2bde2e5..78f2a0403c 100644 --- a/docs/serverless/dashboards/detection-response-dashboard.asciidoc +++ b/docs/serverless/dashboards/detection-response-dashboard.asciidoc @@ -1,4 +1,4 @@ -[[detection-response-dashboard]] +[[security-detection-response-dashboard]] = Detection & Response dashboard :description: The Detection & Response dashboard provides focused visibility into the day-to-day operations of your security environment diff --git a/docs/serverless/dashboards/kubernetes-dashboard-dash.asciidoc b/docs/serverless/dashboards/kubernetes-dashboard-dash.asciidoc index a45a578b8e..9a4b605b14 100644 --- a/docs/serverless/dashboards/kubernetes-dashboard-dash.asciidoc +++ b/docs/serverless/dashboards/kubernetes-dashboard-dash.asciidoc @@ -1,4 +1,4 @@ -[[kubernetes-dashboard-dash]] +[[security-kubernetes-dashboard-dash]] = Kubernetes dashboard :description: The Kubernetes dashboard provides insight into Linux process data from your Kubernetes clusters. @@ -25,10 +25,10 @@ You can filter the data using the KQL search bar and date picker at the top of t From the sessions table's Actions column, you can take the following investigative actions: * View details -* <> -* <> -* <> -* <> +* <> +* <> +* <> +* <> Session View displays Kubernetes metadata under the **Metadata** tab of the Detail panel: @@ -46,7 +46,7 @@ The **Metadata** tab is organized into these expandable sections: [[k8s-dash-setup]] == Setup -To get data for this dashboard, set up <> for the clusters you want to display on the dashboard. +To get data for this dashboard, set up <> for the clusters you want to display on the dashboard. .Requirements [NOTE] @@ -99,5 +99,5 @@ This feature is currently available on GKE and EKS using Linux hosts and Kuberne [IMPORTANT] ==== -This dashboard uses data from the `logs-*` index pattern, which is included by default in the <>. To collect data from multiple {es} clusters (as in a cross-cluster deployment), update `logs-*` to `*:logs-*`. +This dashboard uses data from the `logs-*` index pattern, which is included by default in the <>. To collect data from multiple {es} clusters (as in a cross-cluster deployment), update `logs-*` to `*:logs-*`. ==== diff --git a/docs/serverless/dashboards/overview-dashboard.asciidoc b/docs/serverless/dashboards/overview-dashboard.asciidoc index 418843b6e5..baaeac7a8d 100644 --- a/docs/serverless/dashboards/overview-dashboard.asciidoc +++ b/docs/serverless/dashboards/overview-dashboard.asciidoc @@ -1,4 +1,4 @@ -[[overview-dashboard]] +[[security-overview-dashboard]] = Overview dashboard :description: The Overview dashboard provides a high-level snapshot of alerts and events. @@ -16,7 +16,7 @@ The Overview dashboard provides a high-level snapshot of alerts and events. It h image::images/overview-dashboard/-dashboards-overview-pg.png[Overview dashboard] [discrete] -[[overview-dashboard-live-feed]] +[[security-overview-dashboard-live-feed]] == Live feed The live feed on the Overview dashboard helps you quickly access recently created cases, favorited Timelines, and the latest {elastic-sec} news. @@ -30,7 +30,7 @@ The **Security news** section provides the latest {elastic-sec} news to help you image::images/overview-dashboard/-dashboards-live-feed-ov-page.png[Overview dashboard with live feed section highlighted] [discrete] -[[overview-dashboard-histograms]] +[[security-overview-dashboard-histograms]] == Histograms Time-based histograms show the number of detections, alerts, and events that have occurred within the selected time range. To focus on a particular time, click and drag to select a time range, or choose a preset value. The **Stack by** menu lets you select which field is used to organize the data. For example, in the Alert trend histogram, stack by `kibana.alert.rule.name` to display alert counts by rule name within the specified time frame. @@ -38,7 +38,7 @@ Time-based histograms show the number of detections, alerts, and events that hav Hover over histograms, graphs, and tables to display an **Inspect** button (image:images/icons/inspect.svg[Inspect]) or options menu (image:images/icons/boxesHorizontal.svg[More actions]). Click to inspect the visualization's {es} queries, add it to a new or existing case, or open it in Lens for customization. [discrete] -[[overview-dashboard-host-and-network-events]] +[[security-overview-dashboard-host-and-network-events]] == Host and network events View event and host counts grouped by data source, such as **Auditbeat** or **{elastic-defend}**. Expand a category to view specific counts of host or network events from the selected source. @@ -47,7 +47,7 @@ View event and host counts grouped by data source, such as **Auditbeat** or **{e image::images/overview-dashboard/-getting-started-events-count.png[Host and network events on the Overview dashboard] [discrete] -[[overview-dashboard-threat-intelligence]] +[[security-overview-dashboard-threat-intelligence]] == Threat Intelligence The Threat Intelligence view on the Overview dashboard provides streamlined threat intelligence data for threat detection and matching. @@ -56,7 +56,7 @@ The view shows the total number of ingested threat indicators, enabled threat in [NOTE] ==== -For more information about connecting to threat intelligence sources, visit <>. +For more information about connecting to threat intelligence sources, visit <>. ==== [role="screenshot"] diff --git a/docs/serverless/dashboards/rule-monitoring-dashboard.asciidoc b/docs/serverless/dashboards/rule-monitoring-dashboard.asciidoc index 33e0bce483..c37364a416 100644 --- a/docs/serverless/dashboards/rule-monitoring-dashboard.asciidoc +++ b/docs/serverless/dashboards/rule-monitoring-dashboard.asciidoc @@ -1,4 +1,4 @@ -[[rule-monitoring-dashboard]] +[[security-rule-monitoring-dashboard]] = Detection rule monitoring dashboard :description: Visualize your detection rules' performance. diff --git a/docs/serverless/dashboards/vuln-management-dashboard-dash.asciidoc b/docs/serverless/dashboards/vuln-management-dashboard-dash.asciidoc index 232c8b5d6f..0b12ab8d4f 100644 --- a/docs/serverless/dashboards/vuln-management-dashboard-dash.asciidoc +++ b/docs/serverless/dashboards/vuln-management-dashboard-dash.asciidoc @@ -1,4 +1,4 @@ -[[vuln-management-dashboard-dash]] +[[security-vuln-management-dashboard-dash]] = Cloud Native Vulnerability Management Dashboard :description: The CNVM dashboard gives an overview of vulnerabilities detected in your cloud infrastructure. @@ -18,7 +18,7 @@ image::images/vuln-management-dashboard-dash/-cloud-native-security-vuln-managem .Requirements [NOTE] ==== -* To collect this data, install the <> integration. +* To collect this data, install the <> integration. ==== [discrete] @@ -42,4 +42,4 @@ The page also includes three tables: * **Top 10 patchable vulnerabilities** shows the most common vulnerabilities in your environment that can be fixed by a software update. * **Top 10 vulnerabilities** shows the most common vulnerabilities in your environment, with additional details. -Click **View all vulnerabilities** at the bottom of a table to open the <> page, where you can view additional details. +Click **View all vulnerabilities** at the bottom of a table to open the <> page, where you can view additional details. diff --git a/docs/serverless/edr-install-config/agent-tamper-protection.asciidoc b/docs/serverless/edr-install-config/agent-tamper-protection.asciidoc index 7cfe9020d7..426de1a096 100644 --- a/docs/serverless/edr-install-config/agent-tamper-protection.asciidoc +++ b/docs/serverless/edr-install-config/agent-tamper-protection.asciidoc @@ -1,4 +1,4 @@ -[[agent-tamper-protection]] +[[security-agent-tamper-protection]] = Prevent {agent} uninstallation :description: Block unauthorized attempts to uninstall {agent} on hosts. @@ -32,7 +32,7 @@ You can enable Agent tamper protection by configuring the {agent} policy. . Select the **Settings** tab on the policy details page. . In the **Agent tamper protection** section, turn on the **Prevent agent tampering** setting. + -This makes the **Get uninstall command** link available, which you can follow to get the uninstall token and CLI command if you need to <> on this policy. +This makes the **Get uninstall command** link available, which you can follow to get the uninstall token and CLI command if you need to <> on this policy. + [TIP] ==== diff --git a/docs/serverless/edr-install-config/artifact-control.asciidoc b/docs/serverless/edr-install-config/artifact-control.asciidoc index b8512152be..52635cfa26 100644 --- a/docs/serverless/edr-install-config/artifact-control.asciidoc +++ b/docs/serverless/edr-install-config/artifact-control.asciidoc @@ -1,4 +1,4 @@ -[[protection-artifact-control]] +[[security-protection-artifact-control]] = Configure updates for protection artifacts :description: Configure updates for protection artifacts. diff --git a/docs/serverless/edr-install-config/configure-endpoint-integration-policy.asciidoc b/docs/serverless/edr-install-config/configure-endpoint-integration-policy.asciidoc index a4086ff071..4510902f68 100644 --- a/docs/serverless/edr-install-config/configure-endpoint-integration-policy.asciidoc +++ b/docs/serverless/edr-install-config/configure-endpoint-integration-policy.asciidoc @@ -1,4 +1,4 @@ -[[configure-endpoint-integration-policy]] +[[security-configure-endpoint-integration-policy]] = Configure an integration policy for {elastic-defend} :description: Configure settings on an {elastic-defend} integration policy. @@ -43,7 +43,7 @@ To configure an integration policy: ** <> ** <> ** <> -. Click the **Trusted applications**, **Event filters**, **Host isolation exceptions**, and **Blocklist** tabs to review the endpoint policy artifacts assigned to this integration policy (for more information, refer to <>, <>, <>, and <>). On these tabs, you can: +. Click the **Trusted applications**, **Event filters**, **Host isolation exceptions**, and **Blocklist** tabs to review the endpoint policy artifacts assigned to this integration policy (for more information, refer to <>, <>, <>, and <>). On these tabs, you can: + ** Expand and view an artifact — Click the arrow next to its name. ** View an artifact's details — Click the actions menu (image:images/icons/boxesHorizontal.svg[Actions menu]), then select **View full details**. @@ -58,7 +58,7 @@ You can't create a new endpoint policy artifact while configuring an integration To create a new artifact, go to its main page in the {security-app} (for example, to create a new trusted application, go to **Assets** → **Endpoints** → **Trusted applications**). ==== -. Click the **Protection updates** tab to configure how {elastic-defend} receives updates from Elastic with the latest threat detections, malware models, and other protection artifacts. Refer to <> for more information. +. Click the **Protection updates** tab to configure how {elastic-defend} receives updates from Elastic with the latest threat detections, malware models, and other protection artifacts. Refer to <> for more information. [discrete] [[malware-protection]] @@ -84,7 +84,7 @@ You must pay attention to and analyze any malware alerts that are generated. These additional options are available for malware protection: -* **Blocklist**: Enable or disable the <> for all hosts associated with this {elastic-defend} policy. The blocklist allows you to prevent specified applications from running on hosts, extending the list of processes that {elastic-defend} considers malicious. +* **Blocklist**: Enable or disable the <> for all hosts associated with this {elastic-defend} policy. The blocklist allows you to prevent specified applications from running on hosts, extending the list of processes that {elastic-defend} considers malicious. * **Scan files upon modification**: By default, {elastic-defend} scans files every time they're modified, which can be resource-intensive on hosts where files are frequently modified, such as servers and developer machines. Turn off this option to only scan files when they're executed. {elastic-defend} will continue to identify malware as it attempts to run, providing a robust level of protection while improving endpoint performance. Select **Notify user** to send a push notification in the host operating system when activity is detected or prevented. Notifications are enabled by default for the **Prevent** option. @@ -101,7 +101,7 @@ image::images/configure-endpoint-integration-policy/-getting-started-install-end [[manage-quarantined-files]] === Manage quarantined files -When **Prevent** is enabled for malware protection, {elastic-defend} will quarantine any malicious file it finds (this includes files defined in the <>). Specifically {elastic-defend} will remove the file from its current location, encrypt it with the encryption key `ELASTIC`, move it to a different folder, and rename it as a GUID string, such as `318e70c2-af9b-4c3a-939d-11410b9a112c`. +When **Prevent** is enabled for malware protection, {elastic-defend} will quarantine any malicious file it finds (this includes files defined in the <>). Specifically {elastic-defend} will remove the file from its current location, encrypt it with the encryption key `ELASTIC`, move it to a different folder, and rename it as a GUID string, such as `318e70c2-af9b-4c3a-939d-11410b9a112c`. The quarantine folder location varies by operating system: @@ -110,7 +110,7 @@ The quarantine folder location varies by operating system: * Windows - {elastic-defend} versions 8.5 and later: `[DriveLetter:].quarantine`, unless the files are from the `C:` drive. These files are moved to `C:\Program Files\Elastic\Endpoint\state.equarantine`. * Windows - {elastic-defend} versions 8.4 and earlier: `[DriveLetter:].quarantine`, for any drive -To restore a quarantined file to its original state and location, <> to the rule that identified the file as malicious. If the exception would've stopped the rule from identifying the file as malicious, {elastic-defend} restores the file. +To restore a quarantined file to its original state and location, <> to the rule that identified the file as malicious. If the exception would've stopped the rule from identifying the file as malicious, {elastic-defend} restores the file. You can access a quarantined file by using the `get-file` <> in the response console. To do this, copy the path from the alert's **Quarantined file path** field (`file.Ext.quarantine_path`), which appears under **Highlighted fields** in the alert details flyout. Then paste the value into the `--path` parameter. This action doesn't restore the file to its original location, so you will need to do this manually. @@ -275,9 +275,9 @@ Advanced settings are not recommended for most users. This section includes: -* <> -* <> -* <> +* <> +* <> +* <> [discrete] [[save-policy]] diff --git a/docs/serverless/edr-install-config/defend-feature-privs.asciidoc b/docs/serverless/edr-install-config/defend-feature-privs.asciidoc index f5b45bb790..1cef912803 100644 --- a/docs/serverless/edr-install-config/defend-feature-privs.asciidoc +++ b/docs/serverless/edr-install-config/defend-feature-privs.asciidoc @@ -1,4 +1,4 @@ -[[endpoint-management-req]] +[[security-endpoint-management-req]] = {elastic-defend} feature privileges :description: Manage user roles and privileges to grant access to {elastic-defend} features. @@ -25,37 +25,37 @@ To grant access, select **All** for the **Security** feature in the **{kib} priv | | | **Endpoint List** -| Access the <> page, which lists all hosts running {elastic-defend}, and associated integration details. +| Access the <> page, which lists all hosts running {elastic-defend}, and associated integration details. | **Trusted Applications** -| Access the <> page to remediate conflicts with other software, such as antivirus or endpoint security applications +| Access the <> page to remediate conflicts with other software, such as antivirus or endpoint security applications | **Host Isolation Exceptions** -| Access the <> page to add specific IP addresses that isolated hosts can still communicate with. +| Access the <> page to add specific IP addresses that isolated hosts can still communicate with. | **Blocklist** -| Access the <> page to prevent specified applications from running on hosts, extending the list of processes that {elastic-defend} considers malicious. +| Access the <> page to prevent specified applications from running on hosts, extending the list of processes that {elastic-defend} considers malicious. | **Event Filters** -| Access the <> page to filter out endpoint events that you don't want stored in {es}. +| Access the <> page to filter out endpoint events that you don't want stored in {es}. | **{elastic-defend} Policy Management** -| Access the <> page and {elastic-defend} integration policies to configure protections, event collection, and advanced policy features. +| Access the <> page and {elastic-defend} integration policies to configure protections, event collection, and advanced policy features. | **Response Actions History** -| Access the <> for endpoints. +| Access the <> for endpoints. | **Host Isolation** -| Allow users to <>. +| Allow users to <>. | **Process Operations** -| Perform host process-related <>, including `processes`, `kill-process`, and `suspend-process`. +| Perform host process-related <>, including `processes`, `kill-process`, and `suspend-process`. | **File Operations** -| Perform file-related <> in the response console. +| Perform file-related <> in the response console. | **Execute Operations** -a| Perform shell commands and script-related <> in the response console. +a| Perform shell commands and script-related <> in the response console. [WARNING] ==== @@ -63,5 +63,5 @@ The commands are run on the host using the same user account running the {elasti ==== | **Scan Operations** -| Perform folder scan <> in the response console. +| Perform folder scan <> in the response console. |=== diff --git a/docs/serverless/edr-install-config/deploy-endpoint-macos-cat-mont.asciidoc b/docs/serverless/edr-install-config/deploy-endpoint-macos-cat-mont.asciidoc index b626a83e28..6b62ed0930 100644 --- a/docs/serverless/edr-install-config/deploy-endpoint-macos-cat-mont.asciidoc +++ b/docs/serverless/edr-install-config/deploy-endpoint-macos-cat-mont.asciidoc @@ -1,4 +1,4 @@ -[[install-endpoint-manually]] +[[security-install-endpoint-manually]] = Enable access for macOS Monterey :description: Configure access for deploying {elastic-defend} on macOS Monterey. @@ -14,7 +14,7 @@ To properly install and configure {elastic-defend} manually without a Mobile Dev [NOTE] ==== -The following permissions that need to be enabled are required after you <>, which includes <>. +The following permissions that need to be enabled are required after you <>, which includes <>. ==== [discrete] @@ -47,7 +47,7 @@ After successfully loading the {elastic-endpoint} system extension, an addition [role="screenshot"] image::images/deploy-elastic-endpoint/-getting-started-install-endpoint-filter-network-content.png[] -* Click **Allow** to enable content filtering for the {elastic-endpoint} system extension. Without this approval, {elastic-endpoint} cannot receive network events and, therefore, cannot enable network-related features such as <>. +* Click **Allow** to enable content filtering for the {elastic-endpoint} system extension. Without this approval, {elastic-endpoint} cannot receive network events and, therefore, cannot enable network-related features such as <>. [discrete] [[enable-fda-endpoint]] diff --git a/docs/serverless/edr-install-config/deploy-endpoint-macos-ven.asciidoc b/docs/serverless/edr-install-config/deploy-endpoint-macos-ven.asciidoc index 893c935ca4..c0b1d0ccae 100644 --- a/docs/serverless/edr-install-config/deploy-endpoint-macos-ven.asciidoc +++ b/docs/serverless/edr-install-config/deploy-endpoint-macos-ven.asciidoc @@ -1,4 +1,4 @@ -[[deploy-elastic-endpoint-ven]] +[[security-deploy-elastic-endpoint-ven]] = Enable access for macOS Ventura and higher :description: Configure access for deploying {elastic-defend} on macOS Ventura and higher. @@ -14,7 +14,7 @@ To properly install and configure {elastic-defend} manually without a Mobile Dev [NOTE] ==== -The following permissions that need to be enabled are required after you <>, which includes <>. +The following permissions that need to be enabled are required after you <>, which includes <>. ==== [discrete] @@ -51,7 +51,7 @@ After successfully loading the ElasticEndpoint system extension, an additional m [role="screenshot"] image::images/deploy-elastic-endpoint-ven/-getting-started-install-endpoint-ven-allow_network_filter_ven.png[] -Click **Allow** to enable content filtering for the ElasticEndpoint system extension. Without this approval, {elastic-endpoint} cannot receive network events and, therefore, cannot enable network-related features such as <>. +Click **Allow** to enable content filtering for the ElasticEndpoint system extension. Without this approval, {elastic-endpoint} cannot receive network events and, therefore, cannot enable network-related features such as <>. [discrete] [[enable-fda-endpoint-ven]] diff --git a/docs/serverless/edr-install-config/deploy-endpoint-reqs.asciidoc b/docs/serverless/edr-install-config/deploy-endpoint-reqs.asciidoc index 77278662dd..0b4990e31c 100644 --- a/docs/serverless/edr-install-config/deploy-endpoint-reqs.asciidoc +++ b/docs/serverless/edr-install-config/deploy-endpoint-reqs.asciidoc @@ -1,4 +1,4 @@ -[[elastic-endpoint-deploy-reqs]] +[[security-elastic-endpoint-deploy-reqs]] = {elastic-defend} requirements :description: System requirements for {elastic-defend}. @@ -8,11 +8,11 @@ preview:[] To properly deploy {elastic-defend} without a Mobile Device Management (MDM) profile, you must manually enable additional permissions on the host before {elastic-endpoint}—the installed component that performs {elastic-defend}'s threat monitoring and prevention—is fully functional. For more information, refer to the instructions for your macOS version: -* <> -* <> +* <> +* <> [discrete] -[[elastic-endpoint-deploy-reqs-minimum-system-requirements]] +[[security-elastic-endpoint-deploy-reqs-minimum-system-requirements]] == Minimum system requirements |=== diff --git a/docs/serverless/edr-install-config/deploy-with-mdm.asciidoc b/docs/serverless/edr-install-config/deploy-with-mdm.asciidoc index 68a717a279..77266f154c 100644 --- a/docs/serverless/edr-install-config/deploy-with-mdm.asciidoc +++ b/docs/serverless/edr-install-config/deploy-with-mdm.asciidoc @@ -1,4 +1,4 @@ -[[deploy-with-mdm]] +[[security-deploy-with-mdm]] = Deploy {elastic-defend} on macOS with mobile device management :description: Configure access for deploying {elastic-defend} on macOS with mobile device management. @@ -15,18 +15,18 @@ To silently install and deploy {elastic-defend} without the need for user intera This page explains how to deploy {elastic-defend} silently using Jamf. [discrete] -[[deploy-with-mdm-configure-a-jamf-mdm-profile]] +[[security-deploy-with-mdm-configure-a-jamf-mdm-profile]] == Configure a Jamf MDM profile In Jamf, create a configuration profile for {elastic-endpoint}. Follow these steps to configure the profile: -. <>. -. <>. -. <>. -. <>. +. <>. +. <>. +. <>. +. <>. [discrete] -[[deploy-with-mdm-approve-the-system-extension]] +[[security-deploy-with-mdm-approve-the-system-extension]] === Approve the system extension . Select the **System Extensions** option to configure the system extension policy for the {elastic-endpoint} configuration profile. @@ -43,7 +43,7 @@ In Jamf, create a configuration profile for {elastic-endpoint}. Follow these ste image::images/deploy-with-mdm/system-extension-jamf.png[] [discrete] -[[deploy-with-mdm-approve-network-content-filtering]] +[[security-deploy-with-mdm-approve-network-content-filtering]] === Approve network content filtering . Select the **Content Filter** option to configure the Network Extension policy for the {elastic-endpoint} configuration profile. @@ -73,7 +73,7 @@ identifier "co.elastic.systemextension" and anchor apple generic and certificate image::images/deploy-with-mdm/content-filtering-jamf.png[] [discrete] -[[deploy-with-mdm-enable-notifications]] +[[security-deploy-with-mdm-enable-notifications]] === Enable notifications . Select the **Notifications** option to configure the Notification Center policy for the {elastic-endpoint} configuration profile. @@ -94,7 +94,7 @@ image::images/deploy-with-mdm/content-filtering-jamf.png[] image::images/deploy-with-mdm/notifications-jamf.png[] [discrete] -[[deploy-with-mdm-enable-full-disk-access]] +[[security-deploy-with-mdm-enable-full-disk-access]] === Enable Full Disk Access . Select the **Privacy Preferences Policy Control** option to configure the Full Disk Access policy for the {elastic-endpoint} configuration profile. diff --git a/docs/serverless/edr-install-config/endpoint-data-volume.asciidoc b/docs/serverless/edr-install-config/endpoint-data-volume.asciidoc index 22536a926d..1dac188be9 100644 --- a/docs/serverless/edr-install-config/endpoint-data-volume.asciidoc +++ b/docs/serverless/edr-install-config/endpoint-data-volume.asciidoc @@ -1,4 +1,4 @@ -[[endpoint-data-volume]] +[[security-endpoint-data-volume]] = Configure {elastic-endpoint}'s data volume :description: diff --git a/docs/serverless/edr-install-config/endpoint-diagnostic-data.asciidoc b/docs/serverless/edr-install-config/endpoint-diagnostic-data.asciidoc index 322c61d63c..57a5055059 100644 --- a/docs/serverless/edr-install-config/endpoint-diagnostic-data.asciidoc +++ b/docs/serverless/edr-install-config/endpoint-diagnostic-data.asciidoc @@ -1,4 +1,4 @@ -[[endpoint-diagnostic-data]] +[[security-endpoint-diagnostic-data]] = Turn off diagnostic data for {elastic-defend} :description: Stop producing diagnostic data for Elastic defend by configuring your integration policy. diff --git a/docs/serverless/edr-install-config/endpoint-protection-intro.asciidoc b/docs/serverless/edr-install-config/endpoint-protection-intro.asciidoc index d520257c12..63170fed5a 100644 --- a/docs/serverless/edr-install-config/endpoint-protection-intro.asciidoc +++ b/docs/serverless/edr-install-config/endpoint-protection-intro.asciidoc @@ -1,4 +1,4 @@ -[[endpoint-protection-intro]] +[[security-endpoint-protection-intro]] = Configure endpoint protection with {elastic-defend} :description: Start protecting your endpoints with {elastic-defend}. diff --git a/docs/serverless/edr-install-config/install-elastic-defend.asciidoc b/docs/serverless/edr-install-config/install-elastic-defend.asciidoc index ab68a882b6..c13ed7820d 100644 --- a/docs/serverless/edr-install-config/install-elastic-defend.asciidoc +++ b/docs/serverless/edr-install-config/install-elastic-defend.asciidoc @@ -1,4 +1,4 @@ -[[install-edr]] +[[security-install-edr]] = Install the {elastic-defend} integration :description: Start protecting your endpoints with {elastic-defend}. @@ -28,7 +28,7 @@ Like other Elastic integrations, {elastic-defend} is integrated into the {agent} [[security-before-you-begin]] == Before you begin -If you're using macOS, some versions may require you to grant Full Disk Access to different kernels, system extensions, or files. Refer to <> for more information. +If you're using macOS, some versions may require you to grant Full Disk Access to different kernels, system extensions, or files. Refer to <> for more information. [NOTE] ==== @@ -58,7 +58,7 @@ If this is the first integration you've installed and the **Ready to add your fi image:images/install-endpoint/-getting-started-install-endpoint-endpoint-cloud-security-configuration.png[Add {elastic-defend} integration page] . Configure the {elastic-defend} integration with an **Integration name** and optional **Description**. . Select the type of environment you want to protect, either **Traditional Endpoints** or **Cloud Workloads**. -. Select a configuration preset. Each preset comes with different default settings for {agent} — you can further customize these later by <>. +. Select a configuration preset. Each preset comes with different default settings for {agent} — you can further customize these later by <>. + |=== | | @@ -72,10 +72,10 @@ a| All traditional endpoint presets _except_ **Data Collection** have these prev * **Complete EDR (Endpoint Detection & Response):** All events; all preventions | **Cloud Workloads presets** -a| Both cloud workload presets are intended for monitoring cloud-based Linux hosts. Therefore, <> collection, which enriches process events, is enabled by default. They both have all preventions disabled by default, and collect process, network, and file events. +a| Both cloud workload presets are intended for monitoring cloud-based Linux hosts. Therefore, <> collection, which enriches process events, is enabled by default. They both have all preventions disabled by default, and collect process, network, and file events. * **All events:** Includes data from automated sessions. -* **Interactive only:** Filters out data from non-interactive sessions by creating an <>. +* **Interactive only:** Filters out data from non-interactive sessions by creating an <>. |=== . Enter a name for the agent policy in **New agent policy name**. If other agent policies already exist, you can click the **Existing hosts** tab and select an existing policy instead. For more details on {agent} configuration settings, refer to {fleet-guide}/agent-policy.html[{agent} policies]. . When you're ready, click **Save and continue**. @@ -115,4 +115,4 @@ image:images/install-endpoint/-getting-started-install-endpoint-endpoint-cloud-s . After you have enrolled the {agent} on your host, you can click **View enrolled agents** to access the list of agents enrolled in {fleet}. Otherwise, select **Close**. + The host will now appear on the **Endpoints** page in the {security-app}. It may take another minute or two for endpoint data to appear in {elastic-sec}. -. For macOS, continue with <> to grant {elastic-endpoint} the required permissions. +. For macOS, continue with <> to grant {elastic-endpoint} the required permissions. diff --git a/docs/serverless/edr-install-config/linux-file-monitoring.asciidoc b/docs/serverless/edr-install-config/linux-file-monitoring.asciidoc index 1a1023a764..1900170419 100644 --- a/docs/serverless/edr-install-config/linux-file-monitoring.asciidoc +++ b/docs/serverless/edr-install-config/linux-file-monitoring.asciidoc @@ -1,4 +1,4 @@ -[[linux-file-monitoring]] +[[security-linux-file-monitoring]] = Configure Linux file system monitoring :description: Configure monitoring for Linux file systems. diff --git a/docs/serverless/edr-install-config/self-healing-rollback.asciidoc b/docs/serverless/edr-install-config/self-healing-rollback.asciidoc index e25db921d7..55e119311c 100644 --- a/docs/serverless/edr-install-config/self-healing-rollback.asciidoc +++ b/docs/serverless/edr-install-config/self-healing-rollback.asciidoc @@ -1,4 +1,4 @@ -[[self-healing-rollback]] +[[security-self-healing-rollback]] = Configure self-healing rollback for Windows endpoints :description: Revert file changes on the Windows endpoints. diff --git a/docs/serverless/edr-install-config/uninstall-agent.asciidoc b/docs/serverless/edr-install-config/uninstall-agent.asciidoc index 1581f88967..2ba8134f2d 100644 --- a/docs/serverless/edr-install-config/uninstall-agent.asciidoc +++ b/docs/serverless/edr-install-config/uninstall-agent.asciidoc @@ -1,4 +1,4 @@ -[[uninstall-agent]] +[[security-uninstall-agent]] = Uninstall {agent} :description: Remove {agent} from a host. @@ -8,7 +8,7 @@ preview:[] To uninstall {agent} from a host, run the `uninstall` command from the directory where it's running. Refer to the {fleet-guide}/uninstall-elastic-agent.html[{fleet} and {agent} documentation] for more information. -If <> is enabled on the Agent policy for the host, you'll need to include the uninstall token in the command, using the `--uninstall-token` flag. You can <> on the Agent policy or at **{fleet}** -> **Uninstall tokens**. +If <> is enabled on the Agent policy for the host, you'll need to include the uninstall token in the command, using the `--uninstall-token` flag. You can <> on the Agent policy or at **{fleet}** -> **Uninstall tokens**. For example: diff --git a/docs/serverless/edr-manage/allowlist-endpoint-3rd-party-av.asciidoc b/docs/serverless/edr-manage/allowlist-endpoint-3rd-party-av.asciidoc index e6b70d99de..4dfd182c58 100644 --- a/docs/serverless/edr-manage/allowlist-endpoint-3rd-party-av.asciidoc +++ b/docs/serverless/edr-manage/allowlist-endpoint-3rd-party-av.asciidoc @@ -1,4 +1,4 @@ -[[allowlist-endpoint]] +[[security-allowlist-endpoint]] = Allowlist {elastic-endpoint} in third-party antivirus apps :description: Add {elastic-endpoint} as a trusted application in third-party antivirus (AV) software. @@ -8,7 +8,7 @@ preview:[] [NOTE] ==== -If you use other antivirus (AV) software along with {elastic-defend}, you may need to add the other system as a trusted application in the {security-app}. Refer to <> for more information. +If you use other antivirus (AV) software along with {elastic-defend}, you may need to add the other system as a trusted application in the {security-app}. Refer to <> for more information. ==== Third-party antivirus (AV) applications may identify the expected behavior of {elastic-endpoint}—the installed component that performs {elastic-defend}'s threat monitoring and prevention—as a potential threat. Add {elastic-endpoint}'s digital signatures and file paths to your AV software's allowlist to ensure {elastic-endpoint} continues to function as intended. We recommend you allowlist both the file paths and digital signatures, if applicable. @@ -19,7 +19,7 @@ Your AV software may refer to allowlisted processes as process exclusions, ignor ==== [discrete] -[[allowlist-endpoint-allowlist-elastic-endpoint-on-windows]] +[[security-allowlist-endpoint-allowlist-elastic-endpoint-on-windows]] == Allowlist {elastic-endpoint} on Windows File paths: @@ -41,7 +41,7 @@ Digital signatures: For additional information about allowlisting on Windows, refer to https://github.com/elastic/endpoint/blob/main/PerformanceIssues-Windows.md#trusting-elastic-defend-in-other-software[Trusting Elastic Defend in other software]. [discrete] -[[allowlist-endpoint-allowlist-elastic-endpoint-on-macos]] +[[security-allowlist-endpoint-allowlist-elastic-endpoint-on-macos]] == Allowlist {elastic-endpoint} on macOS File paths: @@ -65,7 +65,7 @@ Digital signatures: * Team ID: `2BT3HPN62Z` [discrete] -[[allowlist-endpoint-allowlist-elastic-endpoint-on-linux]] +[[security-allowlist-endpoint-allowlist-elastic-endpoint-on-linux]] == Allowlist {elastic-endpoint} on Linux File path: diff --git a/docs/serverless/edr-manage/blocklist.asciidoc b/docs/serverless/edr-manage/blocklist.asciidoc index b7250b86e2..cb773b434d 100644 --- a/docs/serverless/edr-manage/blocklist.asciidoc +++ b/docs/serverless/edr-manage/blocklist.asciidoc @@ -1,4 +1,4 @@ -[[blocklist]] +[[security-blocklist]] = Blocklist :keywords: serverless, security, how-to @@ -7,7 +7,7 @@ preview:[] The blocklist (**Assets** → **Blocklist**) allows you to prevent specified applications from running on hosts, extending the list of processes that {elastic-defend} considers malicious. This helps ensure that known malicious processes aren't accidentally executed by end users. -The blocklist is not intended to broadly block benign applications for non-security reasons; only use it to block potentially harmful applications. To compare the blocklist with other endpoint artifacts, refer to <>. +The blocklist is not intended to broadly block benign applications for non-security reasons; only use it to block potentially harmful applications. To compare the blocklist with other endpoint artifacts, refer to <>. .Requirements [NOTE] diff --git a/docs/serverless/edr-manage/endpoint-command-ref.asciidoc b/docs/serverless/edr-manage/endpoint-command-ref.asciidoc index 05488c5271..396e245002 100644 --- a/docs/serverless/edr-manage/endpoint-command-ref.asciidoc +++ b/docs/serverless/edr-manage/endpoint-command-ref.asciidoc @@ -1,4 +1,4 @@ -[[endpoint-command-ref]] +[[security-endpoint-command-ref]] = {elastic-endpoint} command reference :description: Manage and troubleshoot {elastic-endpoint} using CLI commands. @@ -20,18 +20,18 @@ This page lists the commands for management and troubleshooting of {elastic-endp The following {elastic-endpoint} commands are available: -* <> -* <> -* <> -* <> -* <> -* <> -* <> -* <> -* <> -* <> -* <> -* <> +* <> +* <> +* <> +* <> +* <> +* <> +* <> +* <> +* <> +* <> +* <> +* <> Each of the commands accepts the following logging options: @@ -39,7 +39,7 @@ Each of the commands accepts the following logging options: * `--log-level [error,info,debug]` [discrete] -[[endpoint-command-ref-elastic-endpoint-diagnostics]] +[[security-endpoint-command-ref-elastic-endpoint-diagnostics]] == elastic-endpoint diagnostics Gather diagnostics information from {elastic-endpoint}. This command produces an archive that contains: @@ -53,7 +53,7 @@ Gather diagnostics information from {elastic-endpoint}. This command produces an * `logs` directory: Copy of {elastic-endpoint} log files [discrete] -[[endpoint-command-ref-example]] +[[security-endpoint-command-ref-example]] === Example [source] @@ -62,13 +62,13 @@ elastic-endpoint diagnostics ---- [discrete] -[[endpoint-command-ref-elastic-endpoint-help]] +[[security-endpoint-command-ref-elastic-endpoint-help]] == elastic-endpoint help Show help for the available commands. [discrete] -[[endpoint-command-ref-example-1]] +[[security-endpoint-command-ref-example-1]] === Example [source] @@ -77,13 +77,13 @@ elastic-endpoint help ---- [discrete] -[[endpoint-command-ref-elastic-endpoint-inspect]] +[[security-endpoint-command-ref-elastic-endpoint-inspect]] == elastic-endpoint inspect Show the current {elastic-endpoint} configuration. [discrete] -[[endpoint-command-ref-example-2]] +[[security-endpoint-command-ref-example-2]] === Example [source] @@ -92,7 +92,7 @@ elastic-endpoint inspect ---- [discrete] -[[endpoint-command-ref-elastic-endpoint-install]] +[[security-endpoint-command-ref-elastic-endpoint-install]] == elastic-endpoint install Install {elastic-endpoint} as a system service. @@ -103,7 +103,7 @@ We do not recommend installing {elastic-endpoint} using this command. {elastic-e ==== [discrete] -[[endpoint-command-ref-options-3]] +[[security-endpoint-command-ref-options-3]] === Options `--resources `:: @@ -113,7 +113,7 @@ Specify a resources `.zip` file to be used during the installation. This option Upgrade the existing installation. [discrete] -[[endpoint-command-ref-example-4]] +[[security-endpoint-command-ref-example-4]] === Example [source] @@ -122,13 +122,13 @@ elastic-endpoint install --upgrade --resources endpoint-security-resources.zip ---- [discrete] -[[endpoint-command-ref-elastic-endpoint-memorydump]] +[[security-endpoint-command-ref-elastic-endpoint-memorydump]] == elastic-endpoint memorydump Save a memory dump of the {elastic-endpoint} service. [discrete] -[[endpoint-command-ref-options-5]] +[[security-endpoint-command-ref-options-5]] === Options `--compress`:: @@ -138,7 +138,7 @@ Compress the saved memory dump. Specify the memory collection timeout, in seconds; the default is 60 seconds. [discrete] -[[endpoint-command-ref-example-6]] +[[security-endpoint-command-ref-example-6]] === Example [source] @@ -147,13 +147,13 @@ elastic-endpoint memorydump --timeout 120 ---- [discrete] -[[endpoint-command-ref-elastic-endpoint-run]] +[[security-endpoint-command-ref-elastic-endpoint-run]] == elastic-endpoint run Run `elastic-endpoint` as a foreground process if no other instance is already running. [discrete] -[[endpoint-command-ref-example-7]] +[[security-endpoint-command-ref-example-7]] === Example [source] @@ -162,20 +162,20 @@ elastic-endpoint run ---- [discrete] -[[endpoint-command-ref-elastic-endpoint-send]] +[[security-endpoint-command-ref-elastic-endpoint-send]] == elastic-endpoint send Send the requested document to the {stack}. [discrete] -[[endpoint-command-ref-subcommands-8]] +[[security-endpoint-command-ref-subcommands-8]] === Subcommands `metadata`:: Send an off-schedule metrics document to the {stack}. [discrete] -[[endpoint-command-ref-example-9]] +[[security-endpoint-command-ref-example-9]] === Example [source] @@ -184,13 +184,13 @@ elastic-endpoint send metadata ---- [discrete] -[[endpoint-command-ref-elastic-endpoint-status]] +[[security-endpoint-command-ref-elastic-endpoint-status]] == elastic-endpoint status Retrieve the current status of the running {elastic-endpoint} service. The command also returns the last known status of {agent}. [discrete] -[[endpoint-command-ref-options-10]] +[[security-endpoint-command-ref-options-10]] === Options `--output`:: @@ -201,7 +201,7 @@ Control the level of detail and formatting of the information. Valid values are: * `json`: Always returns the full status information. [discrete] -[[endpoint-command-ref-example-11]] +[[security-endpoint-command-ref-example-11]] === Example [source] @@ -210,20 +210,20 @@ elastic-endpoint status --output json ---- [discrete] -[[endpoint-command-ref-elastic-endpoint-test]] +[[security-endpoint-command-ref-elastic-endpoint-test]] == elastic-endpoint test Perform the requested test. [discrete] -[[endpoint-command-ref-subcommands-12]] +[[security-endpoint-command-ref-subcommands-12]] === Subcommands `output`:: Test whether {elastic-endpoint} can connect to remote resources. [discrete] -[[endpoint-command-ref-example-13]] +[[security-endpoint-command-ref-example-13]] === Example [source] @@ -232,7 +232,7 @@ elastic-endpoint test output ---- [discrete] -[[endpoint-command-ref-example-output-14]] +[[security-endpoint-command-ref-example-output-14]] === Example output [source] @@ -252,7 +252,7 @@ Fleet server: https://fleet.example.elastic.co:443 ---- [discrete] -[[endpoint-command-ref-elastic-endpoint-top]] +[[security-endpoint-command-ref-elastic-endpoint-top]] == elastic-endpoint top Show a breakdown of the executables that triggered {elastic-endpoint} CPU usage within the last interval. This displays which {elastic-endpoint} features are resource-intensive for a particular executable. @@ -263,7 +263,7 @@ The meaning and output of this command are similar, but not identical, to the PO ==== [discrete] -[[endpoint-command-ref-options-15]] +[[security-endpoint-command-ref-options-15]] === Options `--interval `:: @@ -276,7 +276,7 @@ Specify the number of updates to collect; by default, data is collected until in Normalize CPU usage values to a total of 100% across all CPUs on multi-CPU systems. [discrete] -[[endpoint-command-ref-example-16]] +[[security-endpoint-command-ref-example-16]] === Example [source] @@ -285,7 +285,7 @@ elastic-endpoint top --interval 10 --limit 5 ---- [discrete] -[[endpoint-command-ref-example-output-17]] +[[security-endpoint-command-ref-example-output-17]] === Example output [source] @@ -316,7 +316,7 @@ Collecting data. Press Ctrl-C to cancel ---- [discrete] -[[endpoint-command-ref-column-abbreviations]] +[[security-endpoint-command-ref-column-abbreviations]] ==== Column abbreviations * `API`: Event Tracing for Windows (ETW) API events @@ -336,25 +336,25 @@ Collecting data. Press Ctrl-C to cancel * `REG`: Registry events [discrete] -[[endpoint-command-ref-elastic-endpoint-uninstall]] +[[security-endpoint-command-ref-elastic-endpoint-uninstall]] == elastic-endpoint uninstall Uninstall {elastic-endpoint}. [NOTE] ==== -{elastic-endpoint} is managed by {agent}. To remove {elastic-endpoint} from the target machine permanently, remove the {elastic-defend} integration from the {fleet} policy. The <> command also uninstalls {elastic-endpoint}; therefore, in practice, the `elastic-endpoint uninstall` command is used only to troubleshoot broken installations. +{elastic-endpoint} is managed by {agent}. To remove {elastic-endpoint} from the target machine permanently, remove the {elastic-defend} integration from the {fleet} policy. The <> command also uninstalls {elastic-endpoint}; therefore, in practice, the `elastic-endpoint uninstall` command is used only to troubleshoot broken installations. ==== [discrete] -[[endpoint-command-ref-options-18]] +[[security-endpoint-command-ref-options-18]] === Options `--uninstall-token `:: -Provide the uninstall token. The token is required if <> is enabled. +Provide the uninstall token. The token is required if <> is enabled. [discrete] -[[endpoint-command-ref-example-19]] +[[security-endpoint-command-ref-example-19]] === Example [source] @@ -363,13 +363,13 @@ elastic-endpoint uninstall --uninstall-token 12345678901234567890123456789012 ---- [discrete] -[[endpoint-command-ref-elastic-endpoint-version]] +[[security-endpoint-command-ref-elastic-endpoint-version]] == elastic-endpoint version Show the version of {elastic-endpoint}. [discrete] -[[endpoint-command-ref-example-20]] +[[security-endpoint-command-ref-example-20]] === Example [source] diff --git a/docs/serverless/edr-manage/endpoint-event-capture.asciidoc b/docs/serverless/edr-manage/endpoint-event-capture.asciidoc index 6fa3af2bf8..c49a08c80f 100644 --- a/docs/serverless/edr-manage/endpoint-event-capture.asciidoc +++ b/docs/serverless/edr-manage/endpoint-event-capture.asciidoc @@ -1,4 +1,4 @@ -[[endpoint-event-capture]] +[[security-endpoint-event-capture]] = Event capture and {elastic-defend} :description: Learn more about how {elastic-defend} collects event data. @@ -11,7 +11,7 @@ preview:[] You can supplement {elastic-defend}'s protection capabilities with {integrations-docs}[Elastic integrations] and tools that provide more visibility and historical data. Consult the following sections to expand data collection for specific types of system events. [discrete] -[[endpoint-event-capture-network-port-creation-and-deletion]] +[[security-endpoint-event-capture-network-port-creation-and-deletion]] == Network port creation and deletion {elastic-defend} tracks TCP connections. If a port is created but no traffic flows, no events are generated. @@ -19,7 +19,7 @@ You can supplement {elastic-defend}'s protection capabilities with {integrations For complete capture of network port creation and deletion, consider capturing Windows event ID 5158 using the {integrations-docs}/winlog[Custom Windows Event Logs] integration. [discrete] -[[endpoint-event-capture-network-inout-connections]] +[[security-endpoint-event-capture-network-inout-connections]] == Network in/out connections {elastic-defend} tracks TCP connections, which don't include network in/out connections. @@ -27,7 +27,7 @@ For complete capture of network port creation and deletion, consider capturing W For complete network capture, consider deploying {packetbeat} using the {integrations-docs}/network_traffic[Network Packet Capture] integration. [discrete] -[[endpoint-event-capture-user-behavior]] +[[security-endpoint-event-capture-user-behavior]] == User behavior {elastic-defend} only captures user security events required by its behavioral protection. This doesn't include every user event such as logins and logouts, or every time a user account is created, deleted, or modified. @@ -35,7 +35,7 @@ For complete network capture, consider deploying {packetbeat} using the {integra For complete capture of all or specific Windows security events, consider the {integrations-docs}/winlog[Custom Windows Event Logs] integration. [discrete] -[[endpoint-event-capture-system-service-registration-deletion-and-modification]] +[[security-endpoint-event-capture-system-service-registration-deletion-and-modification]] == System service registration, deletion, and modification {elastic-defend} only captures system service security events required by its behavioral protection engine. Service creation and modification can also be detected in registry activity, for which {elastic-defend} has internal rules such as https://github.com/elastic/protections-artifacts/blob/6d54ae289b290b1d42a7717569483f6ce907200a/behavior/rules/persistence_registry_or_file_modification_from_suspicious_memory.toml[Registry or File Modification from Suspicious Memory]. @@ -43,7 +43,7 @@ For complete capture of all or specific Windows security events, consider the {i For complete capture of all or specific Windows security events, consider the {integrations-docs}/winlog[Custom Windows Event Logs] integration. In particular, capture events such as https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4697[Windows event ID 4697]. [discrete] -[[endpoint-event-capture-kernel-driver-registration-deletion-and-queries]] +[[security-endpoint-event-capture-kernel-driver-registration-deletion-and-queries]] == Kernel driver registration, deletion, and queries {elastic-defend} scans every driver as it is loaded, but it doesn't generate an event each time. @@ -53,7 +53,7 @@ Drivers are registered in the system as system services. You can capture this wi Also consider capturing Windows event ID 6 using {winlogbeat}'s {winlogbeat-ref}/winlogbeat-module-sysmon.html[Sysmon module]. [discrete] -[[endpoint-event-capture-system-configuration-file-creation-modification-and-deletion]] +[[security-endpoint-event-capture-system-configuration-file-creation-modification-and-deletion]] == System configuration file creation, modification, and deletion {elastic-defend} tracks creation, modification, and deletion of all files on the system. However, as mentioned above, the data might be aggregated, truncated, or deduplicated to provide only what's required for threat detection and prevention. diff --git a/docs/serverless/edr-manage/endpoint-self-protection.asciidoc b/docs/serverless/edr-manage/endpoint-self-protection.asciidoc index 94883b372e..dd4c86a57f 100644 --- a/docs/serverless/edr-manage/endpoint-self-protection.asciidoc +++ b/docs/serverless/edr-manage/endpoint-self-protection.asciidoc @@ -1,4 +1,4 @@ -[[endpoint-self-protection]] +[[security-endpoint-self-protection]] = {elastic-endpoint} self-protection features :description: Learn how {elastic-endpoint} guards itself from tampering and attacks. diff --git a/docs/serverless/edr-manage/endpoints-page.asciidoc b/docs/serverless/edr-manage/endpoints-page.asciidoc index 2d3b7c836d..f2265ae7b9 100644 --- a/docs/serverless/edr-manage/endpoints-page.asciidoc +++ b/docs/serverless/edr-manage/endpoints-page.asciidoc @@ -1,11 +1,11 @@ -[[endpoints-page]] +[[security-endpoints-page]] = Endpoints :keywords: serverless, security, overview preview:[] -The **Endpoints** page (**Assets** → **Endpoints**) allows administrators to view and manage endpoints that are running the <>. +The **Endpoints** page (**Assets** → **Endpoints**) allows administrators to view and manage endpoints that are running the <>. .Requirements [NOTE] @@ -34,7 +34,7 @@ The Endpoints list provides the following data: + ** `Healthy`: The agent is online and communicating with {elastic-sec}. ** `Unenrolling`: The agent is currently unenrolling and will soon be removed from Fleet. Afterward, the endpoint will also uninstall. -** `Unhealthy`: The agent is online but requires attention from an administrator because it's reporting a problem with a process. An unhealthy status could mean an upgrade failed and was rolled back to its previous version, or an integration might be missing prerequisites or additional configuration. Refer to <> for more on resolving an unhealthy agent status. +** `Unhealthy`: The agent is online but requires attention from an administrator because it's reporting a problem with a process. An unhealthy status could mean an upgrade failed and was rolled back to its previous version, or an integration might be missing prerequisites or additional configuration. Refer to <> for more on resolving an unhealthy agent status. ** `Updating`: The agent is online and is updating the agent policy or binary, or is enrolling or unenrolling. ** `Offline`: The agent is still enrolled but may be on a machine that is shut down or currently does not have internet access. In this state, the agent is no longer communicating with {elastic-sec} at a regular interval. + @@ -50,8 +50,8 @@ The Endpoints list provides the following data: * **Last active**: A date and timestamp of the last time the {agent} was active. * **Actions**: Select the context menu (_..._) to do the following: + -** **Isolate host**: <> from your network, blocking communication until the host is released. -** **Respond**: Open the <> to perform response actions directly on the host. +** **Isolate host**: <> from your network, blocking communication until the host is released. +** **Respond**: Open the <> to perform response actions directly on the host. ** **View response actions history**: View a <> performed on the host. ** **View host details**: View host details on the **Hosts** page in the {security-app}. ** **View agent policy**: View the agent policy in {fleet}. @@ -71,7 +71,7 @@ image::images/endpoints-page/-management-admin-host-flyout.png[Endpoint details [[response-action-history-tab]] === Response actions history -The endpoint details flyout also includes the **Response actions history** tab, which provides a log of the <> performed on the endpoint, such as isolating a host or terminating a process. You can use the tools at the top to filter the information displayed in this view. Refer to <> for more details. +The endpoint details flyout also includes the **Response actions history** tab, which provides a log of the <> performed on the endpoint, such as isolating a host or terminating a process. You can use the tools at the top to filter the information displayed in this view. Refer to <> for more details. [role="screenshot"] image::images/endpoints-page/-management-admin-response-actions-history-endpoint-details.png[Response actions history with a few past actions] @@ -122,14 +122,14 @@ For more details on what's causing a policy status, click the link in the **Poli [TIP] ==== -If you need help troubleshooting a configuration failure, refer to <> and {fleet-guide}/fleet-troubleshooting.html[{fleet} troubleshooting]. +If you need help troubleshooting a configuration failure, refer to <> and {fleet-guide}/fleet-troubleshooting.html[{fleet} troubleshooting]. ==== [role="screenshot"] image::images/endpoints-page/-management-admin-config-status.png[Config status details] [discrete] -[[endpoints-page-filter-endpoints]] +[[security-endpoints-page-filter-endpoints]] === Filter endpoints To filter the Endpoints list, use the search bar to enter a query using **{kibana-ref}/kuery-query.html[{kib} Query Language (KQL)]**. To refresh the search results, click **Refresh**. diff --git a/docs/serverless/edr-manage/event-filters.asciidoc b/docs/serverless/edr-manage/event-filters.asciidoc index 12a09cfe51..6dd4578d52 100644 --- a/docs/serverless/edr-manage/event-filters.asciidoc +++ b/docs/serverless/edr-manage/event-filters.asciidoc @@ -1,4 +1,4 @@ -[[event-filters]] +[[security-event-filters]] = Event filters :keywords: serverless, security, how-to @@ -7,7 +7,7 @@ preview:[] Event filters (**Assets** → **Event filters**) allow you to filter out endpoint events that you don't want stored in {es} — for example, high-volume events. By creating event filters, you can optimize your storage in {es}. -Event filters do not lower CPU usage on hosts; {elastic-endpoint} still monitors events to detect and prevent possible threats, but without writing event data to {es}. To compare event filters with other endpoint artifacts, refer to <>. +Event filters do not lower CPU usage on hosts; {elastic-endpoint} still monitors events to detect and prevent possible threats, but without writing event data to {es}. To compare event filters with other endpoint artifacts, refer to <>. .Requirements [NOTE] diff --git a/docs/serverless/edr-manage/host-isolation-exceptions.asciidoc b/docs/serverless/edr-manage/host-isolation-exceptions.asciidoc index bcfaec6af1..670c44b110 100644 --- a/docs/serverless/edr-manage/host-isolation-exceptions.asciidoc +++ b/docs/serverless/edr-manage/host-isolation-exceptions.asciidoc @@ -1,11 +1,11 @@ -[[host-isolation-exceptions]] +[[security-host-isolation-exceptions]] = Host isolation exceptions :keywords: serverless, security, how-to preview:[] -You can configure host isolation exceptions (**Assets** → **Host isolation exceptions**) for specific IP addresses that <> are still allowed to communicate with, even when blocked from the rest of your network. Isolated hosts can still send data to {elastic-sec}, so you don't need to set up host isolation exceptions for them. +You can configure host isolation exceptions (**Assets** → **Host isolation exceptions**) for specific IP addresses that <> are still allowed to communicate with, even when blocked from the rest of your network. Isolated hosts can still send data to {elastic-sec}, so you don't need to set up host isolation exceptions for them. Host isolation exceptions support IPv4 addresses, with optional classless inter-domain routing (CIDR) notation. diff --git a/docs/serverless/edr-manage/manage-endpoint-protection.asciidoc b/docs/serverless/edr-manage/manage-endpoint-protection.asciidoc index c1e7306ed6..009fd6ad71 100644 --- a/docs/serverless/edr-manage/manage-endpoint-protection.asciidoc +++ b/docs/serverless/edr-manage/manage-endpoint-protection.asciidoc @@ -1,4 +1,4 @@ -[[manage-endpoint-protection]] +[[security-manage-endpoint-protection]] = Manage {elastic-defend} :description: Manage endpoint protection artifacts for {elastic-defend}. diff --git a/docs/serverless/edr-manage/optimize-edr.asciidoc b/docs/serverless/edr-manage/optimize-edr.asciidoc index 2f67d5e137..d4b62e7b33 100644 --- a/docs/serverless/edr-manage/optimize-edr.asciidoc +++ b/docs/serverless/edr-manage/optimize-edr.asciidoc @@ -1,4 +1,4 @@ -[[optimize-edr]] +[[security-optimize-edr]] = Optimize {elastic-defend} :keywords: serverless, security, how-to @@ -14,7 +14,7 @@ The following table explains the differences between several Endpoint artifacts |=== | | -| <> +| <> a| **_Prevents {elastic-endpoint} from monitoring a process._** Use to avoid conflicts with other software, usually other antivirus or endpoint security applications. * Creates intentional blind spots in your security environment — use sparingly! @@ -23,12 +23,12 @@ a| **_Prevents {elastic-endpoint} from monitoring a process._** Use to avoid con * Might improve performance, since {elastic-endpoint} monitors fewer processes. * Might still generate malicious behavior alerts, if the application's process events indicate malicious behavior. To suppress alerts, create <>. -| <> +| <> a| **_Prevents event documents from being written to {es}._** Use to reduce storage usage in {es}. Does NOT lower CPU usage for {elastic-endpoint}. It still monitors event data for possible threats, but without writing event data to {es}. -| <> +| <> a| **_Prevents known malware from running._** Use to extend {elastic-defend}'s protection against malicious processes. NOT intended to broadly block benign applications for non-security reasons. diff --git a/docs/serverless/edr-manage/policies-page-ov.asciidoc b/docs/serverless/edr-manage/policies-page-ov.asciidoc index 8864293412..7c37730697 100644 --- a/docs/serverless/edr-manage/policies-page-ov.asciidoc +++ b/docs/serverless/edr-manage/policies-page-ov.asciidoc @@ -1,4 +1,4 @@ -[[policies-page]] +[[security-policies-page]] = Policies :keywords: serverless, security, reference @@ -17,7 +17,7 @@ You must have the appropriate user role to use this feature. // You must have the **{elastic-defend} Policy Management** privilege to access this feature. ==== -Click on an integration policy's name to configure its settings. For more information on configuring an integration policy, refer to <>. +Click on an integration policy's name to configure its settings. For more information on configuring an integration policy, refer to <>. [role="screenshot"] image::images/policies-page-ov/-management-admin-policy-list.png[] diff --git a/docs/serverless/edr-manage/trusted-apps-ov.asciidoc b/docs/serverless/edr-manage/trusted-apps-ov.asciidoc index ff26aa561f..25792df02b 100644 --- a/docs/serverless/edr-manage/trusted-apps-ov.asciidoc +++ b/docs/serverless/edr-manage/trusted-apps-ov.asciidoc @@ -1,4 +1,4 @@ -[[trusted-applications]] +[[security-trusted-applications]] = Trusted applications :keywords: serverless, security, how-to @@ -7,7 +7,7 @@ preview:[] [NOTE] ==== -If you use {elastic-defend} along with other antivirus (AV) software, you might need to configure the other system to trust {elastic-endpoint}. Refer to <> for more information. +If you use {elastic-defend} along with other antivirus (AV) software, you might need to configure the other system to trust {elastic-endpoint}. Refer to <> for more information. ==== On the **Trusted applications** page (**Assets** → **Trusted applications**), you can add Windows, macOS, and Linux applications that should be trusted, such as other antivirus or endpoint security applications. Trusted applications are designed to help mitigate performance issues and incompatibilities with other endpoint software installed on your hosts. Trusted applications apply only to hosts running the {elastic-defend} integration. @@ -24,9 +24,9 @@ You must have the appropriate user role to use this feature. Trusted applications create blindspots for {elastic-defend}, because the applications are no longer monitored for threats. One avenue attackers use to exploit these blindspots is by DLL (Dynamic Link Library) side-loading, where they leverage processes signed by trusted vendors — such as antivirus software — to execute their malicious DLLs. Such activity appears to originate from the trusted application's process. -Trusted applications might still generate alerts in some cases, such as if the application's process events indicate malicious behavior. To reduce false positive alerts, add an <>, which prevents {elastic-defend} from generating alerts. To compare trusted applications with other endpoint artifacts, refer to <>. +Trusted applications might still generate alerts in some cases, such as if the application's process events indicate malicious behavior. To reduce false positive alerts, add an <>, which prevents {elastic-defend} from generating alerts. To compare trusted applications with other endpoint artifacts, refer to <>. -Additionally, trusted applications still generate process events for visualizations and other internal use by the {stack}. To prevent process events from being written to {es}, use an <> to filter out the specific events that you don't want stored in {es}, but be aware that features that depend on these process events may not function correctly. +Additionally, trusted applications still generate process events for visualizations and other internal use by the {stack}. To prevent process events from being written to {es}, use an <> to filter out the specific events that you don't want stored in {es}, but be aware that features that depend on these process events may not function correctly. By default, a trusted application is recognized globally across all hosts running {elastic-defend}. You can also assign a trusted application to a specific {elastic-defend} integration policy, enabling the application to be trusted by only the hosts assigned to that policy. diff --git a/docs/serverless/endpoint-response-actions/automated-response-actions.asciidoc b/docs/serverless/endpoint-response-actions/automated-response-actions.asciidoc index 973d06e3b6..2236b3f791 100644 --- a/docs/serverless/endpoint-response-actions/automated-response-actions.asciidoc +++ b/docs/serverless/endpoint-response-actions/automated-response-actions.asciidoc @@ -1,4 +1,4 @@ -[[automated-response-actions]] +[[security-automated-response-actions]] = Automated response actions :description: Automatically respond to events with endpoint response actions triggered by detection rules. @@ -6,7 +6,7 @@ preview:[] -Add {elastic-defend}'s <> to detection rules to automatically perform actions on an affected host when an event meets the rule's criteria. Use these actions to support your response to detected threats and suspicious events. +Add {elastic-defend}'s <> to detection rules to automatically perform actions on an affected host when an event meets the rule's criteria. Use these actions to support your response to detected threats and suspicious events. .Requirements [NOTE] @@ -25,7 +25,7 @@ To add automated response actions to a new or existing rule: ** **Existing rule**: Edit the rule's settings, then go to the **Actions** tab. In the tab, select **{elastic-defend}** under the **Response Actions** section. . Select an option in the **Response action** field: + -** **Isolate**: <>, blocking communication with other hosts on the network. +** **Isolate**: <>, blocking communication with other hosts on the network. ** **Kill process**: Terminate a process on the host. ** **Suspend process**: Temporarily suspend a process on the host. + diff --git a/docs/serverless/endpoint-response-actions/host-isolation-ov.asciidoc b/docs/serverless/endpoint-response-actions/host-isolation-ov.asciidoc index e07619b6ce..f32776e7c9 100644 --- a/docs/serverless/endpoint-response-actions/host-isolation-ov.asciidoc +++ b/docs/serverless/endpoint-response-actions/host-isolation-ov.asciidoc @@ -1,4 +1,4 @@ -[[isolate-host]] +[[security-isolate-host]] = Isolate a host :description: Host isolation allows you to cut off a host's network access until you release it. @@ -8,7 +8,7 @@ preview:[] Host isolation allows you to isolate hosts from your network, blocking communication with other hosts on your network until you release the host. Isolating a host is useful for responding to malicious activity or preventing potential attacks, as it prevents lateral movement across other hosts. -Isolated hosts, however, can still send data to {elastic-sec}. You can also create <> for specific IP addresses that isolated hosts are still allowed to communicate with, even when blocked from the rest of your network. +Isolated hosts, however, can still send data to {elastic-sec}. You can also create <> for specific IP addresses that isolated hosts are still allowed to communicate with, even when blocked from the rest of your network. .Requirements [NOTE] @@ -160,7 +160,7 @@ image::images/host-isolation-ov/-management-admin-host-released-notif.png[Host r To confirm if a host has been successfully isolated or released, check the response actions history, which logs the response actions performed on a host. -Go to **Assets** → **Endpoints**, click an endpoint's name, then click the **Response action history** tab. You can filter the information displayed in this view. Refer to <> for more details. +Go to **Assets** → **Endpoints**, click an endpoint's name, then click the **Response action history** tab. You can filter the information displayed in this view. Refer to <> for more details. [role="screenshot"] image::images/host-isolation-ov/-management-admin-response-actions-history-endpoint-details.png[Response actions history page UI] diff --git a/docs/serverless/endpoint-response-actions/response-actions-config.asciidoc b/docs/serverless/endpoint-response-actions/response-actions-config.asciidoc index 220a3724dd..ca47d67f1f 100644 --- a/docs/serverless/endpoint-response-actions/response-actions-config.asciidoc +++ b/docs/serverless/endpoint-response-actions/response-actions-config.asciidoc @@ -1,4 +1,4 @@ -[[response-actions-config]] +[[security-response-actions-config]] = Configure third-party response actions :description: Configure {elastic-sec} to perform response actions on hosts protected by third-party systems. @@ -13,7 +13,7 @@ You can direct third-party endpoint protection systems to perform response actio * CrowdStrike * SentinelOne -Check out <> to learn which response actions are supported for each system. +Check out <> to learn which response actions are supported for each system. .Prerequisites [NOTE] @@ -77,7 +77,7 @@ Do not create more than one CrowdStrike connector. *** **CrowdStrike Client ID**: Client ID for the API client used to perform actions in CrowdStrike. *** **Client Secret**: Client secret allowing you access to CrowdStrike. .. Click **Save**. -. **Create and enable detection rules to generate {elastic-sec} alerts.** (Optional) Create <> to generate {elastic-sec} alerts based on CrowdStrike events and data. The {integrations-docs}/crowdstrike[CrowdStrike integration docs] list the available ingested logs and fields you can use to build a rule query. +. **Create and enable detection rules to generate {elastic-sec} alerts.** (Optional) Create <> to generate {elastic-sec} alerts based on CrowdStrike events and data. The {integrations-docs}/crowdstrike[CrowdStrike integration docs] list the available ingested logs and fields you can use to build a rule query. + This gives you visibility into CrowdStrike without needing to leave {elastic-sec}. You can perform supported endpoint response actions directly from alerts that a rule creates, by using the **Take action** menu in the alert details flyout. @@ -126,7 +126,7 @@ Do not create more than one SentinelOne connector. *** **SentinelOne tenant URL**: The SentinelOne tenant URL. *** **API token**: The SentinelOne API access token you generated previously, with permission to read SentinelOne data and perform actions on enrolled hosts. .. Click **Save**. -. **Create and enable detection rules to generate {elastic-sec} alerts.** (Optional) Create <> to generate {elastic-sec} alerts based on SentinelOne events and data. +. **Create and enable detection rules to generate {elastic-sec} alerts.** (Optional) Create <> to generate {elastic-sec} alerts based on SentinelOne events and data. + This gives you visibility into SentinelOne without needing to leave {elastic-sec}. You can perform supported endpoint response actions directly from alerts that a rule creates, by using the **Take action** menu in the alert details flyout. + diff --git a/docs/serverless/endpoint-response-actions/response-actions-history.asciidoc b/docs/serverless/endpoint-response-actions/response-actions-history.asciidoc index 41e004ed30..a998a8fe5d 100644 --- a/docs/serverless/endpoint-response-actions/response-actions-history.asciidoc +++ b/docs/serverless/endpoint-response-actions/response-actions-history.asciidoc @@ -1,4 +1,4 @@ -[[response-actions-history]] +[[security-response-actions-history]] = Response actions history :description: The response actions history log keeps a record of actions taken on endpoints. @@ -6,7 +6,7 @@ preview:[] -{elastic-sec} keeps a log of the <> performed on endpoints, such as isolating a host or terminating a process. The log displays when each command was performed, the host on which the action was performed, the user who requested the action, any comments added to the action, and the action's current status. +{elastic-sec} keeps a log of the <> performed on endpoints, such as isolating a host or terminating a process. The log displays when each command was performed, the host on which the action was performed, the user who requested the action, any comments added to the action, and the action's current status. .Requirement [NOTE] diff --git a/docs/serverless/endpoint-response-actions/response-actions.asciidoc b/docs/serverless/endpoint-response-actions/response-actions.asciidoc index 24125eb065..fdfbe90376 100644 --- a/docs/serverless/endpoint-response-actions/response-actions.asciidoc +++ b/docs/serverless/endpoint-response-actions/response-actions.asciidoc @@ -1,4 +1,4 @@ -[[response-actions]] +[[security-response-actions]] = Endpoint response actions :description: Perform response actions on endpoints using a terminal-like interface. @@ -52,10 +52,10 @@ Once you submit a response action, you can't cancel it, even if the action is pe The following response action commands are available in the response console. [discrete] -[[response-actions-isolate]] +[[security-response-actions-isolate]] === `isolate` -<>, blocking communication with other hosts on the network. +<>, blocking communication with other hosts on the network. Predefined role: **Tier 3 analyst**, **SOC manager**, or **Endpoint operations analyst** @@ -64,7 +64,7 @@ Custom role privilege: **Host isolation** Example: `isolate --comment "Isolate host related to detection alerts"` [discrete] -[[response-actions-release]] +[[security-response-actions-release]] === `release` Release an isolated host, allowing it to communicate with the network again. @@ -76,7 +76,7 @@ Custom role privilege: **Host isolation** Example: `release --comment "Release host, everything looks OK"` [discrete] -[[response-actions-status]] +[[security-response-actions-status]] === `status` Show information about the host's status, including: {agent} status and version, the {elastic-defend} integration's policy status, and when the host was last active. @@ -100,7 +100,7 @@ Entity IDs may be more reliable than PIDs, because entity IDs are unique values [NOTE] ==== -Running this command on third-party-protected hosts might return the process list in a different format. Refer to <> for more information. +Running this command on third-party-protected hosts might return the process list in a different format. Refer to <> for more information. ==== [discrete] @@ -126,7 +126,7 @@ Example: `kill-process --processName cat --comment "Terminate suspicious process ==== [discrete] -[[response-actions-suspend-process]] +[[security-response-actions-suspend-process]] === `suspend-process` Suspend a process. You must include one of the following parameters to identify the process to suspend: @@ -148,7 +148,7 @@ Retrieve a file from a host. Files are downloaded in a password-protected `.zip` [NOTE] ==== -Files retrieved from third-party-protected hosts require a different password. Refer to <> for your system's password. +Files retrieved from third-party-protected hosts require a different password. Refer to <> for your system's password. ==== You must include the following parameter to specify the file's location on the host: @@ -163,7 +163,7 @@ Example: `get-file --path "/full/path/to/file.txt" --comment "Possible malware"` [TIP] ==== -You can use the <> to query a host's operating system and gain insight into its files and directories, then use `get-file` to retrieve specific files. +You can use the <> to query a host's operating system and gain insight into its files and directories, then use `get-file` to retrieve specific files. ==== [NOTE] @@ -172,7 +172,7 @@ When {elastic-defend} prevents file activity due to <> (such as **Detect** or **Prevent** options, or enabling the blocklist) as configured in the host's associated {elastic-defend} integration policy. Use these parameters: @@ -247,13 +247,13 @@ Scanning can take longer for directories containing a lot of files. == Supporting commands and parameters [discrete] -[[response-actions-comment]] +[[security-response-actions-comment]] === `--comment` Add to a command to include a comment explaining or describing the action. Comments are included in the response actions history. [discrete] -[[response-actions-help]] +[[security-response-actions-help]] === `--help` Add to a command to get help for that command. @@ -261,13 +261,13 @@ Add to a command to get help for that command. Example: `isolate --help` [discrete] -[[response-actions-clear]] +[[security-response-actions-clear]] === `clear` Clear all output from the response console. [discrete] -[[response-actions-help-1]] +[[security-response-actions-help-1]] === `help` List supported commands in the console output area. @@ -302,7 +302,7 @@ image::images/response-actions/-management-admin-response-console-unsupported-co [[actions-log]] == Response actions history -Click **Response actions history** to display a log of the response actions performed on the endpoint, such as isolating a host or terminating a process. You can filter the information displayed in this view. Refer to <> for more details. +Click **Response actions history** to display a log of the response actions performed on the endpoint, such as isolating a host or terminating a process. You can filter the information displayed in this view. Refer to <> for more details. [role="screenshot"] image::images/response-actions/-management-admin-response-actions-history-console.png[Response actions history with a few past actions] diff --git a/docs/serverless/endpoint-response-actions/third-party-actions.asciidoc b/docs/serverless/endpoint-response-actions/third-party-actions.asciidoc index d712ac80e3..cb03af1314 100644 --- a/docs/serverless/endpoint-response-actions/third-party-actions.asciidoc +++ b/docs/serverless/endpoint-response-actions/third-party-actions.asciidoc @@ -1,4 +1,4 @@ -[[third-party-actions]] +[[security-third-party-actions]] = Third-party response actions :description: Respond to threats on hosts enrolled in third-party security systems. @@ -14,14 +14,14 @@ You can perform response actions on hosts enrolled in other third-party endpoint [NOTE] ==== * Third-party response actions require the Endpoint Protection Complete https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature]. -* Each response action type has its own user role privilege requirements. Find an action's role requirements at <>. +* Each response action type has its own user role privilege requirements. Find an action's role requirements at <>. ==== [discrete] -[[third-party-actions-supported-systems-and-response-actions]] +[[security-third-party-actions-supported-systems-and-response-actions]] == Supported systems and response actions -The following third-party response actions are supported for CrowdStrike and SentinelOne. <> to connect each system with {elastic-sec}. +The following third-party response actions are supported for CrowdStrike and SentinelOne. <> to connect each system with {elastic-sec}. ++++
@@ -71,7 +71,7 @@ For SentinelOne-enrolled hosts, you must use the parameter `--processName` to id Example: `kill-process --processName cat --comment "Terminate suspicious process"` ==== -* **View past response action activity** in the <> log. +* **View past response action activity** in the <> log. ++++
diff --git a/docs/serverless/explore/conf-map-ui.asciidoc b/docs/serverless/explore/conf-map-ui.asciidoc index 3d6b0871c5..ab7ecbce4e 100644 --- a/docs/serverless/explore/conf-map-ui.asciidoc +++ b/docs/serverless/explore/conf-map-ui.asciidoc @@ -1,4 +1,4 @@ -[[conf-map-ui]] +[[security-conf-map-ui]] = Configure network map data :description: Requirements for setting up and using the Network page. @@ -117,7 +117,7 @@ pipeline: geoip-info <1> ---- + <1> The value of this field must be the same as the ingest pipeline name in -<> (`geoip-info` in this example). +<> (`geoip-info` in this example). [discrete] [[private-network]] diff --git a/docs/serverless/explore/data-views-in-sec.asciidoc b/docs/serverless/explore/data-views-in-sec.asciidoc index 820ccb687a..002a325b84 100644 --- a/docs/serverless/explore/data-views-in-sec.asciidoc +++ b/docs/serverless/explore/data-views-in-sec.asciidoc @@ -1,4 +1,4 @@ -[[data-views-in-sec]] +[[security-data-views-in-sec]] = {data-sources-cap} in Elastic Security :description: Use data views to control what data displays on {elastic-sec} pages with event or alert data. @@ -16,7 +16,7 @@ Custom indices are not included in the <>. @@ -49,7 +49,7 @@ You cannot update the data view for the Alerts page. This includes referencing a [[default-data-view-security]] == The default {data-source} -The default {data-source} is defined by the `securitySolution:defaultIndex` setting, which you can modify in your project's advanced settings. To learn more about this setting, including its default value, refer to <>). +The default {data-source} is defined by the `securitySolution:defaultIndex` setting, which you can modify in your project's advanced settings. To learn more about this setting, including its default value, refer to <>). The first time a user visits {elastic-sec}, the default {data-source} generates and becomes active. diff --git a/docs/serverless/explore/explore-your-data.asciidoc b/docs/serverless/explore/explore-your-data.asciidoc index 0a8c69c81f..95fbe177c3 100644 --- a/docs/serverless/explore/explore-your-data.asciidoc +++ b/docs/serverless/explore/explore-your-data.asciidoc @@ -7,9 +7,9 @@ preview:[] This section contains the following pages: -* <> -* <> -* <> -* <> -* <> -* <> +* <> +* <> +* <> +* <> +* <> +* <> diff --git a/docs/serverless/explore/hosts-overview.asciidoc b/docs/serverless/explore/hosts-overview.asciidoc index af39fe6724..9aded4bf36 100644 --- a/docs/serverless/explore/hosts-overview.asciidoc +++ b/docs/serverless/explore/hosts-overview.asciidoc @@ -1,4 +1,4 @@ -[[hosts-overview]] +[[security-hosts-overview]] = Hosts page :description: Explore the Hosts page to analyze hosts and related security events. @@ -34,10 +34,10 @@ Beneath the KPI charts are data tables, categorized by individual tabs, which ar * **All hosts**: High-level host details. * **Uncommon processes**: Uncommon processes running on hosts. * **Anomalies**: Anomalies discovered by machine learning jobs. -* **Host risk**: The latest recorded host risk score for each host, and its host risk classification. This feature requires the Security Analytics Complete https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature] and must be enabled to display the data. To learn more, refer to our <>. -* **Sessions**: Linux process events that you can open in <>, an investigation tool that allows you to examine Linux process data at a hierarchal level. +* **Host risk**: The latest recorded host risk score for each host, and its host risk classification. This feature requires the Security Analytics Complete https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature] and must be enabled to display the data. To learn more, refer to our <>. +* **Sessions**: Linux process events that you can open in <>, an investigation tool that allows you to examine Linux process data at a hierarchal level. -The tables within the **Events** and **Sessions** tabs include inline actions and several customization options. To learn more about what you can do with the data in these tables, refer to <>. +The tables within the **Events** and **Sessions** tabs include inline actions and several customization options. To learn more about what you can do with the data in these tables, refer to <>. [role="screenshot"] image::images/hosts-overview/-getting-started-users-events-table.png[Events table] @@ -50,7 +50,7 @@ A host's details page displays all relevant information for the selected host. T The host details page includes the following sections: -* **Asset Criticality**: If the `securitySolution:enableAssetCriticality` <> is on, this section displays the host's current <>. +* **Asset Criticality**: If the `securitySolution:enableAssetCriticality` <> is on, this section displays the host's current <>. * **Summary**: Details such as the host ID, when the host was first and last seen, the associated IP addresses, and associated operating system. If the entity risk score feature is enabled, this section also displays host risk score data. * **Alert metrics**: The total number of alerts by severity, rule, and status (`Open`, `Acknowledged`, or `Closed`). * **Data tables**: The same data tables as on the main Hosts page, except with values for the selected host instead of all hosts. @@ -59,7 +59,7 @@ The host details page includes the following sections: image::images/hosts-overview/-management-hosts-hosts-detail-pg.png[Host's details page] [discrete] -[[hosts-overview-host-details-flyout]] +[[security-hosts-overview-host-details-flyout]] == Host details flyout In addition to the host details page, relevant host information is also available in the host details flyout throughout the {elastic-sec} app. You can access this flyout from the following places: @@ -73,21 +73,21 @@ In addition to the host details page, relevant host information is also availabl The host details flyout includes the following sections: -* <>, which displays host risk data and inputs. -* <>, which allows you to view and assign asset criticality. -* <>, which displays host details. +* <>, which displays host risk data and inputs. +* <>, which allows you to view and assign asset criticality. +* <>, which displays host details. [role="screenshot"] image::images/hosts-overview/-host-details-flyout.png[Host details flyout] [discrete] -[[hosts-overview-host-risk-summary]] +[[security-hosts-overview-host-risk-summary]] === Host risk summary .Requirements [NOTE] ==== -The **Host risk summary** section is only available if the <>. +The **Host risk summary** section is only available if the <>. ==== The **Host risk summary** section contains a risk summary visualization and table. @@ -107,16 +107,16 @@ If more than 10 alerts contributed to the risk scoring calculation, the remainin image::images/hosts-overview/-host-risk-inputs.png[Host risk inputs] [discrete] -[[hosts-overview-asset-criticality]] +[[security-hosts-overview-asset-criticality]] === Asset Criticality .Requirements [NOTE] ==== -The **Asset Criticality** section is only available if the `securitySolution:enableAssetCriticality` <> is on. +The **Asset Criticality** section is only available if the `securitySolution:enableAssetCriticality` <> is on. ==== -The **Asset Criticality** section displays the selected host's <>. Asset criticality contributes to the overall <>. The criticality level defines how impactful the host is when calculating the risk score. +The **Asset Criticality** section displays the selected host's <>. Asset criticality contributes to the overall <>. The criticality level defines how impactful the host is when calculating the risk score. [role="screenshot"] image::images/hosts-overview/-host-asset-criticality.png[Asset criticality] @@ -124,7 +124,7 @@ image::images/hosts-overview/-host-asset-criticality.png[Asset criticality] Click **Assign** to assign a criticality level to the selected host, or **Change** to change the currently assigned criticality level. [discrete] -[[hosts-overview-observed-data]] +[[security-hosts-overview-observed-data]] === Observed data This section displays details such as the host ID, when the host was first and last seen, the associated IP addresses and operating system, and the relevant Endpoint integration policy information. diff --git a/docs/serverless/explore/network-page-overview.asciidoc b/docs/serverless/explore/network-page-overview.asciidoc index 443939698d..1ec8b9a440 100644 --- a/docs/serverless/explore/network-page-overview.asciidoc +++ b/docs/serverless/explore/network-page-overview.asciidoc @@ -1,4 +1,4 @@ -[[network-page-overview]] +[[security-network-page-overview]] = Network page :description: Analyze key network activity metrics on an interactive map, and use network event tables for deeper insights. @@ -19,7 +19,7 @@ The map provides an interactive visual overview of your network traffic. Hover o [NOTE] ==== -To access the interactive map, you must have the appropriate user role. To learn more about map setup, refer to <>. +To access the interactive map, you must have the appropriate user role. To learn more about map setup, refer to <>. ==== There are several ways to drill down: @@ -52,7 +52,7 @@ There are also tabs for viewing and investigating specific types of data: * **Events**: All network events. To display alerts received from external monitoring tools, scroll down to the events table and select **Show only external alerts** on the right. -The Events table includes inline actions and several customization options. To learn more about what you can do with the data in these tables, refer to <>. +The Events table includes inline actions and several customization options. To learn more about what you can do with the data in these tables, refer to <>. * **Flows**: Source and destination IP addresses and countries. * **DNS**: DNS network queries. diff --git a/docs/serverless/explore/runtime-fields.asciidoc b/docs/serverless/explore/runtime-fields.asciidoc index 4a3a602b07..1f2afa5173 100644 --- a/docs/serverless/explore/runtime-fields.asciidoc +++ b/docs/serverless/explore/runtime-fields.asciidoc @@ -1,4 +1,4 @@ -[[runtime-fields]] +[[security-runtime-fields]] = Create runtime fields in {elastic-sec} :description: Create, edit, or delete runtime fields in {elastic-sec}. @@ -12,7 +12,7 @@ preview:[] Runtime fields are fields that you can add to documents after you've ingested your data. For example, you could combine two fields and treat them as one, or perform calculations on existing data and use the result as a separate field. Runtime fields are evaluated when a query is run. -You can create a runtime field and add it to your detection alerts or events from any page that lists alerts or events in a data grid table, such as **Alerts**, **Timelines**, **Hosts**, and **Users**. Once created, the new field is added to the current <> and becomes available to all {elastic-sec} alerts and events in the data view. +You can create a runtime field and add it to your detection alerts or events from any page that lists alerts or events in a data grid table, such as **Alerts**, **Timelines**, **Hosts**, and **Users**. Once created, the new field is added to the current <> and becomes available to all {elastic-sec} alerts and events in the data view. [NOTE] ==== diff --git a/docs/serverless/explore/siem-field-reference.asciidoc b/docs/serverless/explore/siem-field-reference.asciidoc index 0c3b2d645d..a99c865a0e 100644 --- a/docs/serverless/explore/siem-field-reference.asciidoc +++ b/docs/serverless/explore/siem-field-reference.asciidoc @@ -1,4 +1,4 @@ -[[siem-field-reference]] +[[security-siem-field-reference]] = {elastic-sec} ECS field reference :description: Learn which ECS fields are used by {elastic-sec} to display various data. @@ -61,7 +61,7 @@ For detailed information about which ECS fields can appear in documents generate * `host.os.version` [discrete] -[[siem-field-reference-authentication-fields]] +[[security-siem-field-reference-authentication-fields]] ==== Authentication fields {elastic-sec} relies on these fields and values to analyze and display host authentication data: @@ -74,7 +74,7 @@ For detailed information about which ECS fields can appear in documents generate * `user.name` [discrete] -[[siem-field-reference-uncommon-process-fields]] +[[security-siem-field-reference-uncommon-process-fields]] ==== Uncommon process fields {elastic-sec} relies on this field to analyze and display host uncommon process data: @@ -98,7 +98,7 @@ For detailed information about which ECS fields can appear in documents generate {elastic-sec} relies on these fields to analyze and display network data: -* `destination.geo.location` (required for display of <>) +* `destination.geo.location` (required for display of <>) * `destination.ip` * `source.geo.location` (required to display map data) * `source.ip` @@ -117,7 +117,7 @@ For detailed information about which ECS fields can appear in documents generate * `source.geo.country_iso_code` [discrete] -[[siem-field-reference-dns-query-fields]] +[[security-siem-field-reference-dns-query-fields]] ==== DNS query fields {elastic-sec} relies on these fields to analyze and display DNS data: @@ -136,7 +136,7 @@ events have `dns.question.type` fields with values of `PTR`. ==== [discrete] -[[siem-field-reference-http-request-fields]] +[[security-siem-field-reference-http-request-fields]] ==== HTTP request fields {elastic-sec} relies on these fields to analyze and display HTTP request data: @@ -147,7 +147,7 @@ events have `dns.question.type` fields with values of `PTR`. * `url.path` [discrete] -[[siem-field-reference-tls-fields]] +[[security-siem-field-reference-tls-fields]] ==== TLS fields {elastic-sec} relies on this field to analyze and display TLS data: @@ -162,7 +162,7 @@ events have `dns.question.type` fields with values of `PTR`. * `tls.server.subject` [discrete] -[[siem-field-reference-fields-required-for-events-and-external-alerts]] +[[security-siem-field-reference-fields-required-for-events-and-external-alerts]] == Fields required for events and external alerts {elastic-sec} relies on this field to analyze and display event and external alert data: diff --git a/docs/serverless/explore/users-page.asciidoc b/docs/serverless/explore/users-page.asciidoc index 3e3b2cb2a5..9c4770463c 100644 --- a/docs/serverless/explore/users-page.asciidoc +++ b/docs/serverless/explore/users-page.asciidoc @@ -1,4 +1,4 @@ -[[users-page]] +[[security-users-page]] = Users page :description: Analyze authentication and user behavior within your environment. @@ -14,7 +14,7 @@ image::images/users-page/-getting-started-users-users-page.png[User's page] The Users page has the following sections: [discrete] -[[users-page-user-kpi-key-performance-indicator-charts]] +[[security-users-page-user-kpi-key-performance-indicator-charts]] == User KPI (key performance indicator) charts KPI charts show the total number of users and successful and failed user authentications within the time range specified in the date picker. Data in the KPI charts is visualized through linear and bar graphs. @@ -25,7 +25,7 @@ Hover inside a KPI chart to display the actions menu (image:images/icons/boxesHo ==== [discrete] -[[users-page-data-tables]] +[[security-users-page-data-tables]] == Data tables Beneath the KPI charts are data tables, which are useful for viewing and investigating specific types of data. Select the relevant tab to view the following details: @@ -34,19 +34,19 @@ Beneath the KPI charts are data tables, which are useful for viewing and investi * **All users**: A chronological list of unique user names, when they were last active, and the associated domains. * **Authentications**: A chronological list of user authentication events and associated details, such as the number of successes and failures, and the host name of the last successful destination. * **Anomalies**: Unusual activity discovered by machine learning jobs that contain user data. -* **User risk**: The latest recorded user risk score for each user, and its user risk classification. This feature requires the Security Analytics Complete https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature] and must be enabled to display the data. To learn more, refer to our <>. +* **User risk**: The latest recorded user risk score for each user, and its user risk classification. This feature requires the Security Analytics Complete https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature] and must be enabled to display the data. To learn more, refer to our <>. -The Events table includes inline actions and several customization options. To learn more about what you can do with the data in these tables, refer to <>. +The Events table includes inline actions and several customization options. To learn more about what you can do with the data in these tables, refer to <>. [discrete] -[[users-page-user-details-page]] +[[security-users-page-user-details-page]] == User details page A user's details page displays all relevant information for the selected user. To view a user's details page, click its **User name** link from the **All users** table. The user details page includes the following sections: -* **Asset Criticality**: If the `securitySolution:enableAssetCriticality` <> is on, this section displays the user's current <>. +* **Asset Criticality**: If the `securitySolution:enableAssetCriticality` <> is on, this section displays the user's current <>. * **Summary**: Details such as the user ID, when the user was first and last seen, the associated IP address(es), and operating system. If the entity risk score feature is enabled, this section also displays user risk score data. * **Alert metrics**: The total number of alerts by severity, rule, and status (`Open`, `Acknowledged`, or `Closed`). * **Data tables**: The same data tables as on the main Users page, except with values for the selected user instead of for all users. @@ -54,7 +54,7 @@ The user details page includes the following sections: image::images/users-page/-getting-started-users-user-details-pg.png[User details page] [discrete] -[[users-page-user-details-flyout]] +[[security-users-page-user-details-flyout]] == User details flyout In addition to the user details page, relevant user information is also available in the user details flyout throughout the {elastic-sec} app. You can access this flyout from the following places: @@ -68,21 +68,21 @@ In addition to the user details page, relevant user information is also availabl The user details flyout includes the following sections: -* <>, which displays user risk data and inputs. -* <>, which allows you to view and assign asset criticality. -* <>, which displays user details. +* <>, which displays user risk data and inputs. +* <>, which allows you to view and assign asset criticality. +* <>, which displays user details. [role="screenshot"] image::images/users-page/-user-details-flyout.png[User details flyout] [discrete] -[[users-page-user-risk-summary]] +[[security-users-page-user-risk-summary]] === User risk summary .Requirement [NOTE] ==== -The **User risk summary** section is only available if the <>. +The **User risk summary** section is only available if the <>. ==== The **User risk summary** section contains a risk summary visualization and table. @@ -102,16 +102,16 @@ If more than 10 alerts contributed to the risk scoring calculation, the remainin image::images/users-page/-user-risk-inputs.png[User risk inputs] [discrete] -[[users-page-asset-criticality]] +[[security-users-page-asset-criticality]] === Asset Criticality .Requirement [NOTE] ==== -The **Asset Criticality** section is only available if the `securitySolution:enableAssetCriticality` <> is on. +The **Asset Criticality** section is only available if the `securitySolution:enableAssetCriticality` <> is on. ==== -The **Asset Criticality** section displays the selected user's <>. Asset criticality contributes to the overall <>. The criticality level defines how impactful the user is when calculating the risk score. +The **Asset Criticality** section displays the selected user's <>. Asset criticality contributes to the overall <>. The criticality level defines how impactful the user is when calculating the risk score. [role="screenshot"] image::images/users-page/-user-asset-criticality.png[Asset criticality] @@ -119,7 +119,7 @@ image::images/users-page/-user-asset-criticality.png[Asset criticality] Click **Assign** to assign a criticality level to the selected user, or **Change** to change the currently assigned criticality level. [discrete] -[[users-page-observed-data]] +[[security-users-page-observed-data]] === Observed data This section displays details such as the user ID, when the user was first and last seen, and the associated IP addresses and operating system. diff --git a/docs/serverless/ingest/auto-import.asciidoc b/docs/serverless/ingest/auto-import.asciidoc index 8a51cd8b08..2311a4ecb4 100644 --- a/docs/serverless/ingest/auto-import.asciidoc +++ b/docs/serverless/ingest/auto-import.asciidoc @@ -1,4 +1,4 @@ -[[automatic-import]] +[[security-automatic-import]] = Automatic Import :description: Use Automatic Import to quickly normalize and ingest third-party data. @@ -24,7 +24,7 @@ Click https://elastic.navattic.com/automatic-import[here] to access an interacti .Requirements [NOTE] ==== -* A working <>. Automatic Import currently works with all variants of Claude 3. Other models are not supported in this technical preview, but will be supported in future versions. +* A working <>. Automatic Import currently works with all variants of Claude 3. Other models are not supported in this technical preview, but will be supported in future versions. * A https://www.elastic.co/pricing/serverless-security[Security Analytics Complete] subscription. * A sample of the data you want to import, in JSON or NDJSON format. ==== @@ -37,7 +37,7 @@ You are responsible for ensuring that your use of Automatic Import complies with ==== [discrete] -[[automatic-import-create-a-new-custom-integration]] +[[security-automatic-import-create-a-new-custom-integration]] == Create a new custom integration . In {elastic-sec}, click **Add integrations**. @@ -46,7 +46,7 @@ You are responsible for ensuring that your use of Automatic Import complies with [role="screenshot"] image:images/auto-import-create-new-integration-button.png[The Integrations page with the Create new integration button highlighted] . Click **Create integration**. -. Select an <>. +. Select an <>. . Define how your new integration will appear on the Integrations page by providing a **Title**, **Description**, and **Logo**. Click **Next**. . Define your integration's package name, which will prefix the imported event fields. . Define your **Data stream title**, **Data stream description**, and **Data stream name**. These fields appear on the integration's configuration page to help identify the data stream it writes to. @@ -85,5 +85,5 @@ Once you've added an integration, you can't edit any details other than the inge [TIP] ==== -You can use the <> to check the health of your data ingest pipelines and field mappings. +You can use the <> to check the health of your data ingest pipelines and field mappings. ==== diff --git a/docs/serverless/ingest/ingest-data.asciidoc b/docs/serverless/ingest/ingest-data.asciidoc index a10e5af015..759e768fc0 100644 --- a/docs/serverless/ingest/ingest-data.asciidoc +++ b/docs/serverless/ingest/ingest-data.asciidoc @@ -1,4 +1,4 @@ -[[ingest-data]] +[[security-ingest-data]] = Ingest data to Elastic Security :description: Learn how to add your own data to {elastic-sec}. @@ -13,11 +13,11 @@ preview:[] To ingest data, you can use: * The {fleet-guide}/fleet-overview.html[{agent}] with the **{elastic-defend}** integration, which protects -your hosts and sends logs, metrics, and endpoint security data to {elastic-sec}. See <>. +your hosts and sends logs, metrics, and endpoint security data to {elastic-sec}. See <>. * The {agent} with other integrations, which are available in the {fleet-guide}/fleet-overview.html#package-registry-intro[Elastic Package Registry (EPR)]. To install an integration that works with {elastic-sec}, select **Add integrations** in the toolbar on most pages. On the **Integrations** page, select the **Security** category filter, then select an integration to view the installation instructions. For more information on integrations, refer to {integrations-docs}[{integrations}]. * **{beats}** shippers installed for each system you want to monitor. * The {agent} to send data from Splunk to {elastic-sec}. See {observability-guide}/splunk-get-started.html[Get started with data from Splunk]. -* Third-party collectors configured to ship ECS-compliant data. <> provides a list of ECS fields used in {elastic-sec}. +* Third-party collectors configured to ship ECS-compliant data. <> provides a list of ECS fields used in {elastic-sec}. [IMPORTANT] ==== @@ -59,7 +59,7 @@ network activity You can install {beats} using the UI guide or directly from the command line. [discrete] -[[ingest-data-install-beats-using-the-ui-guide]] +[[security-ingest-data-install-beats-using-the-ui-guide]] === Install {beats} using the UI guide When you add integrations that use {beats}, you're guided through the {beats} installation process. To begin, go to the **Integrations** page (select **Add integrations** in the toolbar on most pages), and then follow the links for the types of data you want to collect. @@ -70,7 +70,7 @@ On the Integrations page, you can select the **Beats only** filter to only view ==== [discrete] -[[ingest-data-download-and-install-beats-from-the-command-line]] +[[security-ingest-data-download-and-install-beats-from-the-command-line]] === Download and install {beats} from the command line To install {beats}, see these installation guides: diff --git a/docs/serverless/ingest/threat-intelligence.asciidoc b/docs/serverless/ingest/threat-intelligence.asciidoc index 73c5840a9a..95ac53755e 100644 --- a/docs/serverless/ingest/threat-intelligence.asciidoc +++ b/docs/serverless/ingest/threat-intelligence.asciidoc @@ -1,4 +1,4 @@ -[[threat-intelligence]] +[[security-threat-intelligence]] = Enable threat intelligence integrations :description: Use threat indicators to detect known threats and malicious activity. @@ -12,7 +12,7 @@ Threat indicators describe potential threats, unusual behavior, or malicious act [NOTE] ==== -To learn more about alerts with threat intelligence, visit <>. +To learn more about alerts with threat intelligence, visit <>. ==== Refer to the following sections to learn how to connect to threat intelligence sources using an <>, the <>, or a <>. @@ -59,7 +59,7 @@ For more information about enabling available threat intelligence filesets, refe [[custom-ti-integration]] == Add a custom integration -. Set up a way to <> into your system. +. Set up a way to <> into your system. . Update the `securitySolution:defaultThreatIndex` <> by adding the appropriate index pattern name after the default {fleet} threat intelligence index pattern (`logs-ti*`), for example, `logs-ti*`,`custom-ti-index*`. + [NOTE] diff --git a/docs/serverless/investigate/case-permissions.asciidoc b/docs/serverless/investigate/case-permissions.asciidoc index d1e0f9a297..8e168d19a0 100644 --- a/docs/serverless/investigate/case-permissions.asciidoc +++ b/docs/serverless/investigate/case-permissions.asciidoc @@ -1,4 +1,4 @@ -[[cases-requirements]] +[[security-cases-requirements]] = Cases requirements :description: Requirements for using and managing cases. diff --git a/docs/serverless/investigate/cases-open-manage.asciidoc b/docs/serverless/investigate/cases-open-manage.asciidoc index abd0f966ff..8fcf399de1 100644 --- a/docs/serverless/investigate/cases-open-manage.asciidoc +++ b/docs/serverless/investigate/cases-open-manage.asciidoc @@ -1,4 +1,4 @@ -[[cases-open-manage]] +[[security-cases-open-manage]] = Create and manage cases :description: Create a case in {elastic-sec}, and add files and visualizations. @@ -18,7 +18,7 @@ Open a new case to keep track of security issues and share their details with colleagues. . Go to **Cases**, then click **Create case**. If no cases exist, the Cases table will be empty and you'll be prompted to create one by clicking the **Create case** button inside the table. -. (Optional) If you defined <>, select one to use its default field values. preview:[] +. (Optional) If you defined <>, select one to use its default field values. preview:[] . Give the case a name, assign a severity level, and provide a description. You can use https://www.markdownguide.org/cheat-sheet[Markdown] syntax in the case description. + @@ -31,10 +31,10 @@ If you do not assign your case a severity level, it will be assigned **Low** by ==== You can insert a Timeline link in the case description by clicking the Timeline icon (image:images/icons/timeline.svg[Timeline]). ==== -. Optionally, add a category, assignees and relevant tags. You can add users only if they meet the necessary <>. -. If you defined <>, they appear in the **Additional fields** section. +. Optionally, add a category, assignees and relevant tags. You can add users only if they meet the necessary <>. +. If you defined <>, they appear in the **Additional fields** section. . Choose if you want alert statuses to sync with the case's status after they are added to the case. This option is enabled by default, but you can turn it off after creating the case. -. From **External incident management**, select a <>. If you've previously added one, that connector displays as the default selection. Otherwise, the default setting is `No connector selected`. +. From **External incident management**, select a <>. If you've previously added one, that connector displays as the default selection. Otherwise, the default setting is `No connector selected`. . Click **Create case**. + [NOTE] @@ -86,7 +86,7 @@ When you subsequently add assignees to cases, they receive an email. //// [discrete] -[[cases-open-manage-manage-existing-cases]] +[[security-cases-open-manage-manage-existing-cases]] == Manage existing cases From the Cases page, you can search existing cases and filter them by attributes such as assignees, categories, severity, status, and tags. You can also select multiple cases and use bulk actions to delete cases or change their attributes. General case metrics, including how long it takes to close cases, are provided above the table. @@ -144,7 +144,7 @@ image::images/cases-open-manage/-cases-cases-manage-comments.png[Shows you a sum [[cases-examine-alerts]] === Examine alerts attached to a case -To explore the alerts attached to a case, click the **Alerts** tab. In the table, alerts are organized from oldest to newest. To <>, click the **View details** button. +To explore the alerts attached to a case, click the **Alerts** tab. In the table, alerts are organized from oldest to newest. To <>, click the **View details** button. [role="screenshot"] image::images/cases-open-manage/-cases-cases-alert-tab.png[Shows you the Alerts tab] @@ -207,7 +207,7 @@ Set an absolute time range for your visualization. This ensures your visualizati . Click **Preview** to show how the visualization will appear in the case comment. . Click **Add Comment** to add the visualization to your case. -Alternatively, while viewing a <> you can open a panel's menu then click **More actions** (image:images/icons/boxesHorizontal.svg[More actions]​) → **Add to existing case** or **More actions** (image:images/icons/boxesHorizontal.svg[More actions]​) → **Add to new case**. +Alternatively, while viewing a <> you can open a panel's menu then click **More actions** (image:images/icons/boxesHorizontal.svg[More actions]​) → **Add to existing case** or **More actions** (image:images/icons/boxesHorizontal.svg[More actions]​) → **Add to new case**. After a visualization has been added to a case, you can modify or interact with it by clicking the **Open Visualization** option in the case's comment menu. diff --git a/docs/serverless/investigate/cases-overview.asciidoc b/docs/serverless/investigate/cases-overview.asciidoc index e48ced8c8f..96b1666c3e 100644 --- a/docs/serverless/investigate/cases-overview.asciidoc +++ b/docs/serverless/investigate/cases-overview.asciidoc @@ -1,4 +1,4 @@ -[[cases-overview]] +[[security-cases-overview]] = Cases :description: Cases enable you to track investigation details about security issues. @@ -10,7 +10,7 @@ Collect and share information about security issues by opening a case in {elasti // Link to classic docs until serverless API docs are available. -You can also send cases to these external systems by <>: +You can also send cases to these external systems by <>: * {sn-itsm} * {sn-sir} diff --git a/docs/serverless/investigate/cases-settings.asciidoc b/docs/serverless/investigate/cases-settings.asciidoc index 048f3b36b7..d238923af0 100644 --- a/docs/serverless/investigate/cases-settings.asciidoc +++ b/docs/serverless/investigate/cases-settings.asciidoc @@ -1,4 +1,4 @@ -[[cases-settings]] +[[security-cases-settings]] = Configure case settings :description: Change the default behavior of {security} cases by adding connectors, custom fields, templates, and closure options. @@ -14,7 +14,7 @@ image::images/cases-settings/security-cases-settings.png[Shows the case settings // NOTE: This is an autogenerated screenshot. Do not edit it directly. [discrete] -[[cases-settings-case-closures]] +[[security-cases-settings-case-closures]] == Case closures If you close cases in your external incident management system, the cases will remain open in {elastic-sec} until you close them manually. @@ -22,7 +22,7 @@ If you close cases in your external incident management system, the cases will r To close cases when they are sent to an external system, select **Automatically close Security cases when pushing new incident to external system**. [discrete] -[[cases-settings-external-incident-management-systems]] +[[security-cases-settings-external-incident-management-systems]] == External incident management systems You can push {elastic-sec} cases to these third-party systems: @@ -40,7 +40,7 @@ To push cases, you need to create a connector, which stores the information requ .Requirements [NOTE] ==== -To create connectors and send cases to external systems, you need the Security Analytics Complete https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature] and the appropriate user role. For more information, refer to <>. +To create connectors and send cases to external systems, you need the Security Analytics Complete https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature] and the appropriate user role. For more information, refer to <>. ==== To create a new connector @@ -66,7 +66,7 @@ To change the settings of an existing connector: To change the default connector used to send cases to external systems, select the required connector from the incident management system list. [discrete] -[[cases-settings-mapped-case-fields]] +[[security-cases-settings-mapped-case-fields]] === Mapped case fields When you export an {elastic-sec} case to an external system, case fields are mapped to existing fields in the external system. @@ -81,7 +81,7 @@ When you push updates to external systems, mapped fields are either overwritten Retrieving data from external systems is not supported. [discrete] -[[cases-settings-custom-fields]] +[[security-cases-settings-custom-fields]] == Custom fields You can add optional and required fields for customized case collaboration. @@ -100,7 +100,7 @@ In existing cases, new custom text fields initially have null values. You can subsequently remove or edit custom fields on the **Settings** page. [discrete] -[[cases-settings-templates]] +[[security-cases-settings-templates]] == Templates preview::[] diff --git a/docs/serverless/investigate/indicators-of-compromise.asciidoc b/docs/serverless/investigate/indicators-of-compromise.asciidoc index 5da53b2bf8..f3982c6374 100644 --- a/docs/serverless/investigate/indicators-of-compromise.asciidoc +++ b/docs/serverless/investigate/indicators-of-compromise.asciidoc @@ -1,4 +1,4 @@ -[[indicators-of-compromise]] +[[security-indicators-of-compromise]] = Indicators of compromise :description: Set up the Indicators page to detect, analyze, and respond to threats. @@ -62,7 +62,7 @@ If indicator data is not appearing in the Indicators table after you installed a [NOTE] ==== -These troubleshooting steps also apply to the <>. +These troubleshooting steps also apply to the <>. ==== [discrete] @@ -96,7 +96,7 @@ image::images/indicators-of-compromise/-cases-indicator-details-flyout.png[Shows [[find-related-sec-events]] == Find related security events -Investigate an indicator in <> to identify and predict related events in your environment. You can add an indicator to Timeline from the Indicators table or the Indicator details flyout. +Investigate an indicator in <> to identify and predict related events in your environment. You can add an indicator to Timeline from the Indicators table or the Indicator details flyout. [role="screenshot"] image::images/indicators-of-compromise/-cases-indicator-query-timeline.png[Shows the results of an indicator being investigated in Timeline] @@ -171,11 +171,11 @@ image::images/indicators-of-compromise/-cases-remove-indicator.png[Removing an i [[add-indicator-to-blocklist]] == Use data from indicators to expand the blocklist -Add indicator values to the <> to prevent selected applications from running on your hosts. You can use MD5, SHA-1, or SHA-256 hash values from `file` type indicators. +Add indicator values to the <> to prevent selected applications from running on your hosts. You can use MD5, SHA-1, or SHA-256 hash values from `file` type indicators. You can add indicator values to the blocklist from the Indicators table or the Indicator details flyout. From the Indicators table, select the **More actions** (image:images/icons/boxesHorizontal.svg[More actions]) menu → **Add blocklist entry**. Alternatively, open an indicator's details, then select the **Take action** menu → **Add blocklist entry**. [NOTE] ==== -Refer to <> for more information about blocklist entries. +Refer to <> for more information about blocklist entries. ==== diff --git a/docs/serverless/investigate/investigate-events.asciidoc b/docs/serverless/investigate/investigate-events.asciidoc index 1578ae5256..dd0e3d8126 100644 --- a/docs/serverless/investigate/investigate-events.asciidoc +++ b/docs/serverless/investigate/investigate-events.asciidoc @@ -1,4 +1,4 @@ -[[investigate-events]] +[[security-investigate-events]] = Investigation tools :description: Investigate security events and track security issues in {elastic-sec}. @@ -10,7 +10,7 @@ The following sections describe tools for investigating security events and trac These features are available in the {security-app}'s side navigation menu: -* <>: Track investigation details about security issues. -* **Investigations** → <>: Workspace for investigations and threat hunting. -* **Investigations** → <>: Run live and scheduled queries on operating systems. -* <>: Indicators of compromise used for threat intelligence. +* <>: Track investigation details about security issues. +* **Investigations** → <>: Workspace for investigations and threat hunting. +* **Investigations** → <>: Run live and scheduled queries on operating systems. +* <>: Indicators of compromise used for threat intelligence. diff --git a/docs/serverless/investigate/timeline-object-schema.asciidoc b/docs/serverless/investigate/timeline-object-schema.asciidoc index 70d9e7200a..2f57581e3e 100644 --- a/docs/serverless/investigate/timeline-object-schema.asciidoc +++ b/docs/serverless/investigate/timeline-object-schema.asciidoc @@ -1,4 +1,4 @@ -[[timeline-object-schema]] +[[security-timeline-object-schema]] = Timeline schema :description: A list of JSON elements inside the timeline object. @@ -19,21 +19,21 @@ This screenshot maps the Timeline UI components to their JSON objects: [role="screenshot"] image::images/timeline-object-schema/-reference-timeline-object-ui.png[] -. <> (`title`) -. <> (`globalNotes`) -. <> (`dataViewId`) -. <> (`kqlQuery`) -. <> (`dateRange`) -. <> (`filters`) -. <> (`kqlMode`) -. <> (each clause is contained in its own `dataProviders` object) -. <> (`columns`) -. <> (`eventNotes`) +. <> (`title`) +. <> (`globalNotes`) +. <> (`dataViewId`) +. <> (`kqlQuery`) +. <> (`dateRange`) +. <> (`filters`) +. <> (`kqlMode`) +. <> (each clause is contained in its own `dataProviders` object) +. <> (`columns`) +. <> (`eventNotes`) |=== | Name | Type | Description -| [[timeline-object-schema-timeline-object-columns]] +| [[security-timeline-object-schema-timeline-object-columns]] `columns` | <> @@ -49,18 +49,18 @@ timestamp. | String | The user who created the Timeline. -| [[timeline-object-schema-timeline-object-dropzone]] `dataProviders` +| [[security-timeline-object-schema-timeline-object-dropzone]] `dataProviders` | <> | Object containing dropzone query clauses. -| [[timeline-object-schema-timeline-object-dataViewId]] +| [[security-timeline-object-schema-timeline-object-dataViewId]] `dataViewId` | String | ID of the Timeline's Data View, for example: `"dataViewId":"security-solution-default"`. -| [[timeline-object-schema-timeline-object-daterange]] +| [[security-timeline-object-schema-timeline-object-daterange]] `dateRange` | dateRange @@ -76,7 +76,7 @@ timestamp. | String | The Timeline's description. -| [[timeline-object-schema-timeline-object-event-notes]] +| [[security-timeline-object-schema-timeline-object-event-notes]] `eventNotes` | <> @@ -96,18 +96,18 @@ the Timeline, which can be: | Indicates when and who marked a Timeline as a favorite. -| [[timeline-object-schema-timeline-object-filters]] +| [[security-timeline-object-schema-timeline-object-filters]] `filters` | <> | Filters used in addition to the dropzone query. -| [[timeline-object-schema-timeline-object-global-notes]] `globalNotes` +| [[security-timeline-object-schema-timeline-object-global-notes]] `globalNotes` | <> | Global notes added to the Timeline. -| [[timeline-object-schema-timeline-object-kqlmode]] +| [[security-timeline-object-schema-timeline-object-kqlmode]] `kqlMode` | String @@ -117,7 +117,7 @@ filters the dropzone query results or searches for additional results, where: * `filter`: filters dropzone query results * `search`: displays additional search results -| [[timeline-object-schema-timeline-object-kqlquery]] +| [[security-timeline-object-schema-timeline-object-kqlquery]] `kqlQuery` | <> @@ -156,7 +156,7 @@ Timelines, the value is `null`. | Timeline template version number. For Timelines, the value is `null`. -| [[timeline-object-schema-timeline-object-typeField]] +| [[security-timeline-object-schema-timeline-object-typeField]] `timelineType` | String @@ -167,7 +167,7 @@ Timeline is a template or not, where: * `template`: Indicates a Timeline template used when detection rule alerts are investigated in Timeline. -| [[timeline-object-schema-timeline-object-title]] +| [[security-timeline-object-schema-timeline-object-title]] `title` | String diff --git a/docs/serverless/investigate/timeline-templates-ui.asciidoc b/docs/serverless/investigate/timeline-templates-ui.asciidoc index 7b5c56f861..9e54cb7a93 100644 --- a/docs/serverless/investigate/timeline-templates-ui.asciidoc +++ b/docs/serverless/investigate/timeline-templates-ui.asciidoc @@ -1,4 +1,4 @@ -[[timeline-templates-ui]] +[[security-timeline-templates-ui]] = Timeline templates :description: Attach Timeline templates to detection rules to streamline investigations. @@ -21,7 +21,7 @@ For example, if you define the `host.name: "{host.name}"` template filter, when [NOTE] ==== -For information on how to add Timeline templates to rules, refer to <>. +For information on how to add Timeline templates to rules, refer to <>. ==== When you load {elastic-sec} prebuilt rules, {elastic-sec} also loads a selection of prebuilt Timeline templates, which you can attach to detection rules. **Generic** templates use broad KQL queries to retrieve event data, and **Comprehensive** templates use detailed KQL queries to retrieve additional information. The following prebuilt templates appear by default: diff --git a/docs/serverless/investigate/timelines-ui.asciidoc b/docs/serverless/investigate/timelines-ui.asciidoc index 4c6c5a55df..7154b1dc83 100644 --- a/docs/serverless/investigate/timelines-ui.asciidoc +++ b/docs/serverless/investigate/timelines-ui.asciidoc @@ -1,4 +1,4 @@ -[[timelines-ui]] +[[security-timelines-ui]] = Timeline :description: Investigate events and complex threats in your network. @@ -18,10 +18,10 @@ by expanding the <> and clicking **+ Add field**. image::images/timelines-ui/-events-timeline-ui-updated.png[example Timeline with several events] In addition to Timelines, you can create and attach Timeline templates to -<>. Timeline templates allow you to +<>. Timeline templates allow you to define the source event fields used when you investigate alerts in Timeline. You can select whether the fields use predefined values or values -retrieved from the alert. For more information, refer to <>. +retrieved from the alert. For more information, refer to <>. [discrete] [[open-create-timeline]] @@ -56,7 +56,7 @@ You can select whether Timeline displays detection alerts and other raw events, [[timeline-inspect-events-alerts]] == Inspect an event or alert -To further inspect an event or detection alert, click the **View details** button. A flyout with event or <> appears. +To further inspect an event or detection alert, click the **View details** button. A flyout with event or <> appears. [discrete] [[conf-timeline-display]] @@ -75,7 +75,7 @@ interests you, you can drag it up to the drop zone below the query bar for furth You can also modify a Timeline's display in other ways: * <> from Timeline -* Create <> and display them in the Timeline +* Create <> and display them in the Timeline * Reorder and resize columns * Copy a column name or values to a clipboard * Change how the name, value, or description of a field are displayed in Timeline @@ -147,7 +147,7 @@ Converts a `field with value` filter to a `field exists` filter. [NOTE] ==== -When you convert a <> to a +When you convert a <> to a Timeline, some fields may be disabled. For more information, refer to <>. ==== @@ -159,7 +159,7 @@ Timeline, some fields may be disabled. For more information, refer to To attach a Timeline to a new or existing case, open it, click **Attach to case** in the upper right corner, then select either **Attach to new case** or **Attach to existing case**. -To learn more about cases, refer to <>. +To learn more about cases, refer to <>. [discrete] [[manage-timelines-ui]] @@ -170,7 +170,7 @@ You can view, duplicate, export, delete, and create templates from existing Time . Go to **Investigations** → **Timelines**. . Click the **All actions** menu in the desired row, then select an action: -* **Create template from timeline** (refer to <>) +* **Create template from timeline** (refer to <>) * **Duplicate timeline** * **Export selected** (refer to <>) * **Delete selected** diff --git a/docs/serverless/osquery/alerts-run-osquery.asciidoc b/docs/serverless/osquery/alerts-run-osquery.asciidoc index 6ee3910bed..bd0bebc1dd 100644 --- a/docs/serverless/osquery/alerts-run-osquery.asciidoc +++ b/docs/serverless/osquery/alerts-run-osquery.asciidoc @@ -1,4 +1,4 @@ -[[alerts-run-osquery]] +[[security-alerts-run-osquery]] = Run Osquery from alerts :description: Run live queries against an alert's host to investigate potential security threats and system compromises. @@ -40,7 +40,7 @@ Overwriting the query's default timeout period allows you to support queries tha + [TIP] ==== -Use <> to dynamically add existing alert data to your query. +Use <> to dynamically add existing alert data to your query. ==== ** **Pack**: Select from available query packs. After you select a pack, all of the queries in the pack are displayed. + @@ -55,6 +55,6 @@ image:images/alerts-run-osquery/-osquery-setup-query.png[Shows how to set up a s + [NOTE] ==== -Refer to <> for more information about query results. +Refer to <> for more information about query results. ==== . Click **Save for later** to save the query for future use (optional). diff --git a/docs/serverless/osquery/invest-guide-run-osquery.asciidoc b/docs/serverless/osquery/invest-guide-run-osquery.asciidoc index 93067ab587..a643f30804 100644 --- a/docs/serverless/osquery/invest-guide-run-osquery.asciidoc +++ b/docs/serverless/osquery/invest-guide-run-osquery.asciidoc @@ -1,4 +1,4 @@ -[[invest-guide-run-osquery]] +[[security-invest-guide-run-osquery]] = Run Osquery from investigation guides :description: Add and run live queries from a rule's investigation guide. @@ -38,7 +38,7 @@ image:images/invest-guide-run-osquery/-osquery-osquery-button.png[Click the Osqu + [TIP] ==== -Use <> to dynamically add existing alert data to your query. +Use <> to dynamically add existing alert data to your query. ==== .. Expand the **Advanced** section to set a timeout period for the query, and view or set {kibana-ref}/osquery.html#osquery-map-fields[mapped ECS fields] included in the results from the live query (optional). + @@ -70,7 +70,7 @@ Overwriting the query's default timeout period allows you to support queries tha + [NOTE] ==== -Refer to <> for more information about query results. +Refer to <> for more information about query results. ==== . Click **Save for later** to save the query for future use (optional). + diff --git a/docs/serverless/osquery/osquery-placeholder-fields.asciidoc b/docs/serverless/osquery/osquery-placeholder-fields.asciidoc index e59c9530d5..d7f803f446 100644 --- a/docs/serverless/osquery/osquery-placeholder-fields.asciidoc +++ b/docs/serverless/osquery/osquery-placeholder-fields.asciidoc @@ -1,4 +1,4 @@ -[[osquery-placeholder-fields]] +[[security-osquery-placeholder-fields]] = Use placeholder fields in Osquery queries :description: Pass data into queries dynamically, to enhance their flexibility and reusability. @@ -10,9 +10,9 @@ Instead of hard-coding alert and event values into Osquery queries, you can use Placeholder fields work in single queries or query packs. They're also supported in the following features: -* <> -* <> -* <> +* <> +* <> +* <> [discrete] [[placeholder-field-syntax]] diff --git a/docs/serverless/osquery/osquery-response-action.asciidoc b/docs/serverless/osquery/osquery-response-action.asciidoc index 61adb94252..e112e92a96 100644 --- a/docs/serverless/osquery/osquery-response-action.asciidoc +++ b/docs/serverless/osquery/osquery-response-action.asciidoc @@ -1,4 +1,4 @@ -[[osquery-response-action]] +[[security-osquery-response-action]] = Add Osquery Response Actions :description: Osquery Response Actions allow you to add live queries to custom query rules so you can automatically collect data on systems the rules are monitoring. @@ -49,7 +49,7 @@ Overwriting the query's default timeout period allows you to support queries tha + [TIP] ==== -You can use <> to dynamically add alert data to your query. +You can use <> to dynamically add alert data to your query. ==== ** **Pack**: Select from available query packs. After you select a pack, all of the queries in the pack are displayed. + @@ -86,7 +86,7 @@ When a rule generates an alert, Osquery automatically collects data on the host. [NOTE] ==== -Refer to <> for more information about query results. +Refer to <> for more information about query results. ==== [role="screenshot"] diff --git a/docs/serverless/osquery/use-osquery.asciidoc b/docs/serverless/osquery/use-osquery.asciidoc index 97faa53e19..91ceda027e 100644 --- a/docs/serverless/osquery/use-osquery.asciidoc +++ b/docs/serverless/osquery/use-osquery.asciidoc @@ -1,4 +1,4 @@ -[[query-operating-systems]] +[[security-query-operating-systems]] = Osquery :description: Integrate Osquery with {elastic-sec} for comprehensive data collection and security monitoring. @@ -10,7 +10,7 @@ Osquery is an open source tool that lets you use SQL to query operating systems Osquery is supported for Linux, macOS, and Windows. You can use it with {elastic-sec} to perform real-time incident response, threat hunting, and monitoring to detect vulnerability or compliance issues. The following Osquery features are available from {elastic-sec}: -* <> - Use Osquery Response Actions to add live queries to custom query rules. -* <> - Incorporate live queries into investigation guides to enhance your research capabilities while investigating possible security issues. -* <> - Run live queries against an alert's host to learn more about your infrastructure and operating systems. +* <> - Use Osquery Response Actions to add live queries to custom query rules. +* <> - Incorporate live queries into investigation guides to enhance your research capabilities while investigating possible security issues. +* <> - Run live queries against an alert's host to learn more about your infrastructure and operating systems. * {kibana-ref}/osquery.html[Osquery settings] - Navigate to **Investigations** → **Osquery** to manage project-level Osquery settings. diff --git a/docs/serverless/osquery/view-osquery-results.asciidoc b/docs/serverless/osquery/view-osquery-results.asciidoc index eb0050715e..1c073f6193 100644 --- a/docs/serverless/osquery/view-osquery-results.asciidoc +++ b/docs/serverless/osquery/view-osquery-results.asciidoc @@ -1,4 +1,4 @@ -[[examine-osquery-results]] +[[security-examine-osquery-results]] = Examine Osquery results :description: Analyze results from queries and query packs. diff --git a/docs/serverless/projects-create/create-project.asciidoc b/docs/serverless/projects-create/create-project.asciidoc index 0d53b122ce..5b9cef0745 100644 --- a/docs/serverless/projects-create/create-project.asciidoc +++ b/docs/serverless/projects-create/create-project.asciidoc @@ -1,4 +1,4 @@ -[[create-project]] +[[security-create-project]] = Create a Security project :description: Get started with {serverless-short} {elastic-sec} in a few steps. @@ -9,7 +9,7 @@ preview:[] A {serverless-short} project allows you to run {elastic-sec} in an autoscaled and fully-managed environment, where you don't have to manage the underlying {es} cluster and {kib} instances. [discrete] -[[create-project-create-project]] +[[security-create-project-create-project]] == Create project Use your {ecloud} account to create a fully-managed {elastic-sec} project: diff --git a/docs/serverless/rules/about-rules.asciidoc b/docs/serverless/rules/about-rules.asciidoc index 3e377e48b7..033db1e348 100644 --- a/docs/serverless/rules/about-rules.asciidoc +++ b/docs/serverless/rules/about-rules.asciidoc @@ -1,4 +1,4 @@ -[[about-rules]] +[[security-about-rules]] = About detection rules :description: Learn about detection rule types and how they work. @@ -58,7 +58,7 @@ image::images/about-rules/-detections-all-rules.png[Shows the Rules page] [[views-index-patterns]] == Data views and index patterns -When you create a rule, you must either specify the {es} index pattens for which you'd like the rule to run, or select a <> as the data source. If you select a data view, you can select <> associated with that data view to create a query for the rule (with the exception of {ml} rules, which do not use queries). +When you create a rule, you must either specify the {es} index pattens for which you'd like the rule to run, or select a <> as the data source. If you select a data view, you can select <> associated with that data view to create a query for the rule (with the exception of {ml} rules, which do not use queries). [NOTE] ==== @@ -86,7 +86,7 @@ If a rule requires certain privileges to run, such as index privileges, keep in [[about-exceptions]] == Exceptions -When modifying rules or managing detection alerts, you can <> that prevent a rule from generating alerts even when its criteria are met. This is useful for reducing noise, such as preventing alerts from trusted processes and internal IP addresses. +When modifying rules or managing detection alerts, you can <> that prevent a rule from generating alerts even when its criteria are met. This is useful for reducing noise, such as preventing alerts from trusted processes and internal IP addresses. [NOTE] ==== diff --git a/docs/serverless/rules/add-exceptions.asciidoc b/docs/serverless/rules/add-exceptions.asciidoc index 2fbfe59e1f..1958292fe1 100644 --- a/docs/serverless/rules/add-exceptions.asciidoc +++ b/docs/serverless/rules/add-exceptions.asciidoc @@ -1,4 +1,4 @@ -[[add-exceptions]] +[[security-add-exceptions]] = Add and manage exceptions :description: Learn how to create and manage rule exceptions. @@ -72,7 +72,7 @@ When you create a new exception from an alert, exception conditions are auto-pop + [NOTE] ==== -A warning displays for fields with conflicts. Using these fields might cause unexpected exceptions behavior. Refer to <> for more information. +A warning displays for fields with conflicts. Using these fields might cause unexpected exceptions behavior. Refer to <> for more information. ==== .. **Operator**: Select an operator to define the condition: + @@ -111,7 +111,7 @@ In the following example, the exception was created from the Rules page and prev image::images/add-exceptions/-detections-add-exception-ui.png[] . Click **AND** or **OR** to create multiple conditions and define their relationships. . Click **Add nested condition** to create conditions using nested fields. This is only required for -<>. For all other fields, nested conditions should not be used. +<>. For all other fields, nested conditions should not be used. . Choose to add the exception to a rule or a shared exception list. + [NOTE] @@ -121,7 +121,7 @@ If you are creating an exception from the Shared Exception Lists page, you can a + [TIP] ==== -If a shared exception list doesn't exist, you can <> from the Shared Exception Lists page. +If a shared exception list doesn't exist, you can <> from the Shared Exception Lists page. ==== . (Optional) Enter a comment describing the exception. . (Optional) Enter a future expiration date and time for the exception. @@ -193,7 +193,7 @@ Rule exceptions are case-sensitive, which means that any character that's entere + [NOTE] ==== -* Fields with conflicts are marked with a warning icon (image:images/icons/warning.svg[Warning]). Using these fields might cause unexpected exceptions behavior. For more information, refer to <>. +* Fields with conflicts are marked with a warning icon (image:images/icons/warning.svg[Warning]). Using these fields might cause unexpected exceptions behavior. For more information, refer to <>. * Identical, case-sensitive values are supported for the `is one of` and `is not one of` operators. For example, if you want to match the values `Windows` and `windows`, add both values to the **Value** field. ==== . (Optional) Add a comment to the exception. @@ -260,7 +260,7 @@ correctly: * `process.thread.Ext.token.privileges` [discrete] -[[add-exceptions-nested-condition-example]] +[[security-add-exceptions-nested-condition-example]] === Nested condition example Creates an exception that excludes all LFC-signed trusted processes: diff --git a/docs/serverless/rules/alerts-ui-monitor.asciidoc b/docs/serverless/rules/alerts-ui-monitor.asciidoc index 7b8bc18ed8..f0c2622d30 100644 --- a/docs/serverless/rules/alerts-ui-monitor.asciidoc +++ b/docs/serverless/rules/alerts-ui-monitor.asciidoc @@ -1,4 +1,4 @@ -[[alerts-ui-monitor]] +[[security-alerts-ui-monitor]] = Monitor and troubleshoot rule executions :description: Find out how your rules are performing, and troubleshoot common rule issues. @@ -10,7 +10,7 @@ Several tools can help you gain insight into the performance of your detection r * <> — The current state of all detection rules and their most recent executions. Go to the **Rule Monitoring** tab to get an overview of which rules are running, how long they're taking, and if they're having any trouble. * <> — Historical data for a single detection rule's executions over time. Consult the execution results to understand how a particular rule is running and whether it's creating the alerts you expect. -* <> — Visualizations to help you monitor the overall health and performance of {elastic-sec}'s detection rules. Consult this dashboard for a high-level view of whether your rules are running successfully and how long they're taking to run, search data, and create alerts. +* <> — Visualizations to help you monitor the overall health and performance of {elastic-sec}'s detection rules. Consult this dashboard for a high-level view of whether your rules are running successfully and how long they're taking to run, search data, and create alerts. Refer to the <> section below for strategies on adjusting rules if they aren't creating the expected alerts. @@ -32,7 +32,7 @@ On the **Rule Monitoring** tab, you can <>, such as modifying or deleting rules, activating or deactivating rules, exporting or importing rules, and duplicating prebuilt rules. +For detailed information on a rule, the alerts it generated, and associated errors, click on its name in the table. This also allows you to perform the same actions that are available on the <>, such as modifying or deleting rules, activating or deactivating rules, exporting or importing rules, and duplicating prebuilt rules. [discrete] [[rule-execution-logs]] @@ -113,7 +113,7 @@ You can also use Task Manager in {kib} to troubleshoot background tasks and proc When a rule reaches the maximum number of alerts it can generate during a single rule execution, the following warning appears on the rule's details page and in the rule execution log: `This rule reached the maximum alert limit for the rule execution. Some alerts were not created.` -If you receive this warning, go to the rule's **Alerts** tab and check for anything unexpected. Unexpected alerts might be created from data source issues or queries that are too broadly scoped. To further reduce alert volume, you can also add <> or <>. +If you receive this warning, go to the rule's **Alerts** tab and check for anything unexpected. Unexpected alerts might be created from data source issues or queries that are too broadly scoped. To further reduce alert volume, you can also add <> or <>. [discrete] [[troubleshoot-gaps]] diff --git a/docs/serverless/rules/building-block-rule.asciidoc b/docs/serverless/rules/building-block-rule.asciidoc index fc4b00b730..c9feaf6048 100644 --- a/docs/serverless/rules/building-block-rule.asciidoc +++ b/docs/serverless/rules/building-block-rule.asciidoc @@ -1,4 +1,4 @@ -[[building-block-rules]] +[[security-building-block-rules]] = Use building block rules :description: Set up building block rules and view building block alerts. @@ -15,7 +15,7 @@ You can then use building block rules to create hidden alerts that act as a basis for an 'ordinary' rule to generate visible alerts. [discrete] -[[building-block-rules-set-up-rules-that-run-on-alert-indices]] +[[security-building-block-rules-set-up-rules-that-run-on-alert-indices]] == Set up rules that run on alert indices To create a rule that searches alert indices, select **Index Patterns** as the rule's **Source** and enter the index pattern for alert indices (`.alerts-security.alerts-*`): @@ -24,7 +24,7 @@ To create a rule that searches alert indices, select **Index Patterns** as the r image::images/building-block-rule/-detections-alert-indices-ui.png[] [discrete] -[[building-block-rules-view-building-block-alerts-in-the-ui]] +[[security-building-block-rules-view-building-block-alerts-in-the-ui]] == View building block alerts in the UI By default, building block alerts are excluded from the Overview and Alerts pages. diff --git a/docs/serverless/rules/detection-engine-overview.asciidoc b/docs/serverless/rules/detection-engine-overview.asciidoc index 9b1e785a84..f35994f4c5 100644 --- a/docs/serverless/rules/detection-engine-overview.asciidoc +++ b/docs/serverless/rules/detection-engine-overview.asciidoc @@ -1,4 +1,4 @@ -[[detection-engine-overview]] +[[security-detection-engine-overview]] = Detection engine overview :description: Learn about the detection engine and its features. @@ -16,10 +16,10 @@ track investigations, an alert's <> can be set as [role="screenshot"] image::images/detection-engine-overview/-detections-alert-page.png[Alerts page] -In addition to creating <>, enable +In addition to creating <>, enable <> to immediately start detecting -suspicious activity. For detailed information on all the prebuilt rules, see the <>. Once the prebuilt rules are loaded and -running, <> and <> explain +suspicious activity. For detailed information on all the prebuilt rules, see the <>. Once the prebuilt rules are loaded and +running, <> and <> explain how to modify the rules to reduce false positives and get a better set of actionable alerts. You can also use exceptions and value lists when creating or modifying your own rules. @@ -31,7 +31,7 @@ There are two special prebuilt rules you need to know about: * **Endpoint Security**: Automatically creates an alert from all incoming Elastic Endpoint alerts. To receive Elastic Endpoint alerts, you must install the Endpoint agent on your -hosts (see <>). +hosts (see <>). + When this rule is enabled, the following Endpoint events are displayed as detection alerts: @@ -55,7 +55,7 @@ email, when alerts are created, use the {kibana-ref}/alerting-getting-started.ht After rules have started running, you can monitor their executions to verify they are functioning correctly, as well as view, manage, and troubleshoot -alerts (see <> and <>). +alerts (see <> and <>). You can create and manage rules and alerts via the UI or the {security-guide}/rule-api-overview.html[Detections API]. @@ -64,7 +64,7 @@ You can create and manage rules and alerts via the UI or the {security-guide}/ru [IMPORTANT] ==== To make sure you can access Detections and manage rules, see -<>. +<>. ==== [discrete] @@ -79,7 +79,7 @@ In addition, indicator match rules with an additional look-back time value great [[detections-permissions]] == Detections configuration and prerequisites -<> provides detailed information on all the +<> provides detailed information on all the permissions required to initiate and use the Detections feature. [discrete] @@ -109,7 +109,7 @@ are passed to a machine-learning algorithm that distinguishes a benign file from model is updated as new data is procured and analyzed. [discrete] -[[detection-engine-overview-threshold]] +[[security-detection-engine-overview-threshold]] === Threshold A malware threshold determines the action the agent should take if malware is detected. The Elastic Agent uses a recommended threshold level that generates a balanced number of alerts with a low probability of undetected malware. This threshold also minimizes the number of false positive alerts. @@ -126,7 +126,7 @@ Behavioral ransomware prevention on the Elastic Endpoint detects and stops ranso For information on how to enable ransomware protection on your host, see <>. [discrete] -[[detection-engine-overview-resolve-ui-error-messages]] +[[security-detection-engine-overview-resolve-ui-error-messages]] === Resolve UI error messages Depending on your user role privileges and whether detection system indices have already been created, you might get one of these error messages when you diff --git a/docs/serverless/rules/detections-permissions-section.asciidoc b/docs/serverless/rules/detections-permissions-section.asciidoc index 111c6df0fe..adec2ed64d 100644 --- a/docs/serverless/rules/detections-permissions-section.asciidoc +++ b/docs/serverless/rules/detections-permissions-section.asciidoc @@ -1,4 +1,4 @@ -[[detections-requirements]] +[[security-detections-requirements]] = Detections requirements :description: Requirements for setting up and configuring the detections feature. @@ -6,12 +6,12 @@ preview:[] -To use the <>, you first need to +To use the <>, you first need to configure a few settings. You also need the appropriate role to send -<> when detection alerts are generated. +<> when detection alerts are generated. -Additionally, there are some <> used to -configure <> upload limits. +Additionally, there are some <> used to +configure <> upload limits. [discrete] [[enable-detections-ui]] @@ -21,11 +21,11 @@ To use the Detections feature, it must be enabled and you must have either the a [NOTE] ==== -For instructions about using {ml} jobs and rules, refer to <>. +For instructions about using {ml} jobs and rules, refer to <>. ==== [discrete] -[[detections-requirements-custom-role-privileges]] +[[security-detections-requirements-custom-role-privileges]] === Custom role privileges The following table describes the required custom role privileges to access the Detections feature, including rules and alerts. For more information on {kib} privileges, refer to https://www.elastic.co/docs/current/serverless/custom-roles[]. diff --git a/docs/serverless/rules/detections-ui-exceptions.asciidoc b/docs/serverless/rules/detections-ui-exceptions.asciidoc index 4b76651e8c..5ca673220d 100644 --- a/docs/serverless/rules/detections-ui-exceptions.asciidoc +++ b/docs/serverless/rules/detections-ui-exceptions.asciidoc @@ -1,4 +1,4 @@ -[[rule-exceptions]] +[[security-rule-exceptions]] = Rule exceptions :description: Understand the different types of rule exceptions. @@ -16,21 +16,21 @@ When creating exceptions, you can assign them to <>. +You can create exceptions that apply exclusively to a single rule. These types of exceptions can't be used by other rules, and you must manage them from the rule’s details page. To learn more about creating and managing single-rule exceptions, refer to <>. [role="screenshot"] image::images/detections-ui-exceptions/-detections-exception-item-example.png[An exception item] [NOTE] ==== -You can also use <> to define exceptions for detection rules. Value lists allow you to match an exception against a list of possible values. +You can also use <> to define exceptions for detection rules. Value lists allow you to match an exception against a list of possible values. ==== [discrete] [[shared-exception-list-intro]] == Exceptions shared among multiple rules -If you want an exception to apply to multiple rules, you can add an exception to a shared exception list. Shared exception lists allow you to group exceptions together and then associate them with multiple rules. Refer to <> to learn more. +If you want an exception to apply to multiple rules, you can add an exception to a shared exception list. Shared exception lists allow you to group exceptions together and then associate them with multiple rules. Refer to <> to learn more. [role="screenshot"] image::images/detections-ui-exceptions/-detections-rule-exceptions-page.png[Shared Exception Lists page] diff --git a/docs/serverless/rules/interactive-investigation-guides.asciidoc b/docs/serverless/rules/interactive-investigation-guides.asciidoc index ef363f7a31..03ecb43650 100644 --- a/docs/serverless/rules/interactive-investigation-guides.asciidoc +++ b/docs/serverless/rules/interactive-investigation-guides.asciidoc @@ -1,4 +1,4 @@ -[[interactive-investigation-guides]] +[[security-interactive-investigation-guides]] = Launch Timeline from investigation guides :description: Pivot from detection alerts to investigations with interactive investigation guide actions. @@ -6,7 +6,7 @@ preview:[] -Detection rule investigation guides suggest steps for triaging, analyzing, and responding to potential security issues. For custom rules, you can create an interactive investigation guide that includes buttons for launching runtime queries in <>, using alert data and hard-coded literal values. This allows you to start detailed Timeline investigations directly from an alert using relevant data. +Detection rule investigation guides suggest steps for triaging, analyzing, and responding to potential security issues. For custom rules, you can create an interactive investigation guide that includes buttons for launching runtime queries in <>, using alert data and hard-coded literal values. This allows you to start detailed Timeline investigations directly from an alert using relevant data. [role="screenshot"] image::images/interactive-investigation-guides/-detections-ig-alert-flyout.png[Alert details flyout with interactive investigation guide] @@ -30,7 +30,7 @@ image::images/interactive-investigation-guides/-detections-ig-timeline.png[Timel You can only create interactive investigation guides with custom rules because Elastic prebuilt rules can't be edited. However, you can duplicate a prebuilt rule, then configure the investigation guide for the duplicated rule. ==== -You can configure an interactive investigation guide when you <> or <>. +You can configure an interactive investigation guide when you <> or <>. . When configuring the rule's settings (the **About rule** step for a new rule, or the **About** tab for an existing rule), expand the **Advanced settings**, then scroll down to the **Investigation guide** Markdown editor. + @@ -98,7 +98,7 @@ Some characters must be escaped with a backslash, such as `\"` for a quotation m ==== [discrete] -[[interactive-investigation-guides-example-syntax]] +[[security-interactive-investigation-guides-example-syntax]] === Example syntax [source,json] @@ -129,10 +129,10 @@ This example creates the following Timeline query, as illustrated below: image::images/interactive-investigation-guides/-detections-ig-timeline-query.png[Timeline query] [discrete] -[[interactive-investigation-guides-timeline-template-fields]] +[[security-interactive-investigation-guides-timeline-template-fields]] === Timeline template fields -When viewing an interactive investigation guide in contexts unconnected to a specific alert (such a rule's details page), queries open as <>, and `parameter` fields are treated as Timeline template fields. +When viewing an interactive investigation guide in contexts unconnected to a specific alert (such a rule's details page), queries open as <>, and `parameter` fields are treated as Timeline template fields. [role="screenshot"] image::images/interactive-investigation-guides/-detections-ig-timeline-template-fields.png[Timeline template] diff --git a/docs/serverless/rules/prebuilt-rules/prebuilt-rules-management.asciidoc b/docs/serverless/rules/prebuilt-rules/prebuilt-rules-management.asciidoc index ca79152b6f..1efaba7970 100644 --- a/docs/serverless/rules/prebuilt-rules/prebuilt-rules-management.asciidoc +++ b/docs/serverless/rules/prebuilt-rules/prebuilt-rules-management.asciidoc @@ -1,4 +1,4 @@ -[[prebuilt-rules-management]] +[[security-prebuilt-rules-management]] = Install and manage Elastic prebuilt rules :description: Start detections quickly with prebuilt rules designed and updated by Elastic. @@ -10,7 +10,7 @@ preview:[] -Follow these guidelines to start using the {security-app}'s <>, keep them updated, and make sure they have the data needed to run successfully. +Follow these guidelines to start using the {security-app}'s <>, keep them updated, and make sure they have the data needed to run successfully. * <> * <> @@ -21,7 +21,7 @@ Follow these guidelines to start using the {security-app}'s <> and <>. If you want to modify other settings on a prebuilt rule, you must first duplicate it, then make your changes to the duplicated rule. However, your customized rule is entirely separate from the original prebuilt rule, and will not get updates from Elastic if the prebuilt rule is updated. +* You can't modify most settings on Elastic prebuilt rules. You can only edit <> and <>. If you want to modify other settings on a prebuilt rule, you must first duplicate it, then make your changes to the duplicated rule. However, your customized rule is entirely separate from the original prebuilt rule, and will not get updates from Elastic if the prebuilt rule is updated. ==== [discrete] diff --git a/docs/serverless/rules/prebuilt-rules/prebuilt-rules.asciidoc b/docs/serverless/rules/prebuilt-rules/prebuilt-rules.asciidoc index c6bf785c70..8be07a1904 100644 --- a/docs/serverless/rules/prebuilt-rules/prebuilt-rules.asciidoc +++ b/docs/serverless/rules/prebuilt-rules/prebuilt-rules.asciidoc @@ -1,4 +1,4 @@ -[[prebuilt-rules]] +[[security-prebuilt-rules]] = Prebuilt rule reference :description: Learn more about Elastic's prebuilt detection rules. diff --git a/docs/serverless/rules/rules-coverage.asciidoc b/docs/serverless/rules/rules-coverage.asciidoc index 64c3a9a0f0..e2eeabed3e 100644 --- a/docs/serverless/rules/rules-coverage.asciidoc +++ b/docs/serverless/rules/rules-coverage.asciidoc @@ -1,4 +1,4 @@ -[[rules-coverage]] +[[security-rules-coverage]] = MITRE ATT&CK® coverage :description: Review your current coverage of MITRE ATT&CK® tactics and techniques, based on installed rules. @@ -21,7 +21,7 @@ You can map custom rules to tactics in **Advanced settings** when creating or ed image::images/rules-coverage/-detections-rules-coverage.png[MITRE ATT&CK® coverage page] [discrete] -[[rules-coverage-filter-rules]] +[[security-rules-coverage-filter-rules]] == Filter rules Use the drop-down filters at the top of the page to control which of your installed detection rules are included in calculating coverage. @@ -37,7 +37,7 @@ Searches for tactics and techniques must match exactly, are case sensitive, and ==== [discrete] -[[rules-coverage-expand-and-collapse-cells]] +[[security-rules-coverage-expand-and-collapse-cells]] == Expand and collapse cells Click **Collapse cells** or **Expand cells** to change how much information the cells display. Cells always include the technique's name and the number of sub-techniques covered by enabled rules. Expand the cells to also display counts of disabled and enabled rules for each technique. @@ -48,13 +48,13 @@ The counts inside cells are affected by how you filter the page. For example, if ==== [discrete] -[[rules-coverage-enable-rules]] +[[security-rules-coverage-enable-rules]] == Enable rules You can quickly enable all the rules for a specific technique that you've installed, but not enabled. Click the technique's cell, then click **Enable all disabled** in the popup that appears. [discrete] -[[rules-coverage-learn-more-about-techniques-and-sub-techniques]] +[[security-rules-coverage-learn-more-about-techniques-and-sub-techniques]] == Learn more about techniques and sub-techniques For more information on a specific technique and its sub-techniques, click the technique's cell, then click the title in the popup that appears. This opens a new browser tab with the technique's MITRE ATT&CK® documentation. diff --git a/docs/serverless/rules/rules-ui-create.asciidoc b/docs/serverless/rules/rules-ui-create.asciidoc index 07927c9922..f602e5d344 100644 --- a/docs/serverless/rules/rules-ui-create.asciidoc +++ b/docs/serverless/rules/rules-ui-create.asciidoc @@ -1,4 +1,4 @@ -[[rules-create]] +[[security-rules-create]] = Create a detection rule :description: Create detection rules to monitor your environment for suspicious and malicious behavior. @@ -19,7 +19,7 @@ To create a new detection rule, follow these steps: [NOTE] ==== * To create detection rules, you must have access to data views, which requires the appropriate user role. -* You'll also need permissions to enable and view detections, manage rules, manage alerts, and preview rules. These permissions depend on the user role. Refer to <> for more information. +* You'll also need permissions to enable and view detections, manage rules, manage alerts, and preview rules. These permissions depend on the user role. Refer to <> for more information. ==== [TIP] @@ -47,7 +47,7 @@ then select: If a required job isn't currently running, it will automatically start when you finish configuring and enable the rule. ==== .. The anomaly score threshold above which alerts are created. -. (Optional) Use **Suppress alerts by** to reduce the number of repeated or duplicate alerts created by the rule. Refer to <> for more information. +. (Optional) Use **Suppress alerts by** to reduce the number of repeated or duplicate alerts created by the rule. Refer to <> for more information. + [NOTE] ==== @@ -96,7 +96,7 @@ When you use a saved query, the **Load saved query "_query name_" dynamically on + *** Select this to use the saved query every time the rule runs. This links the rule to the saved query, and you won't be able to modify the rule's **Custom query** field or filters because the rule will only use settings from the saved query. To make changes, modify the saved query itself. *** Deselect this to load the saved query as a one-time way of populating the rule's **Custom query** field and filters. This copies the settings from the saved query to the rule, so you can then further adjust the rule's query and filters as needed. If the saved query is later changed, the rule will not inherit those changes. -. (Optional) Use **Suppress alerts by** to reduce the number of repeated or duplicate alerts created by the rule. Refer to <> for more information. +. (Optional) Use **Suppress alerts by** to reduce the number of repeated or duplicate alerts created by the rule. Refer to <> for more information. + //// /* The following steps are repeated across multiple rule types. If you change anything @@ -138,7 +138,7 @@ You can also leave the **Group by** field undefined. The rule then creates an al ==== Alerts created by threshold rules are synthetic alerts that do not resemble the source documents. The alert itself only contains data about the fields that were aggregated over (the **Group by** fields). Other fields are omitted, because they can vary across all source documents that were counted toward the threshold. Additionally, you can reference the actual count of documents that exceeded the threshold from the `kibana.alert.threshold_result.count` field. ==== -. (Optional) Select **Suppress alerts** to reduce the number of repeated or duplicate alerts created by the rule. Refer to <> for more information. +. (Optional) Select **Suppress alerts** to reduce the number of repeated or duplicate alerts created by the rule. Refer to <> for more information. + //// /* The following steps are repeated across multiple rule types. If you change anything @@ -205,7 +205,7 @@ For sequence events, the {security-app} generates a single alert when all events ** **Event category field**: Contains the event classification, such as `process`, `file`, or `network`. This field is typically mapped as a field type in the {ref}/keyword.html[keyword family]. Defaults to the `event.category` ECS field. ** **Tiebreaker field**: Sets a secondary field for sorting events (in ascending, lexicographic order) if they have the same timestamp. ** **Timestamp field**: Contains the event timestamp used for sorting a sequence of events. This is different from the **Timestamp override** advanced setting, which is used for querying events within a range. Defaults to the `@timestamp` ECS field. -. preview:[] (Optional) Use **Suppress alerts by** to reduce the number of repeated or duplicate alerts created by the rule. Refer to <> for more information. +. preview:[] (Optional) Use **Suppress alerts by** to reduce the number of repeated or duplicate alerts created by the rule. Refer to <> for more information. + //// /* The following steps are repeated across multiple rule types. If you change anything @@ -251,7 +251,7 @@ You can use saved queries (image:images/icons/filterInCircle.svg[Filter]) and qu + [IMPORTANT] ==== -Data in indicator indices must be <>, and so it must contain a `@timestamp` field. +Data in indicator indices must be <>, and so it must contain a `@timestamp` field. ==== .. **Indicator index query**: The query and filters used to filter the fields from the indicator index patterns. The default query `@timestamp > "now-30d/d"` searches specified indicator indices for indicators ingested during the past 30 days and rounds the start time down to the nearest day (resolves to UTC `00:00:00`). @@ -280,10 +280,10 @@ image::images/rules-ui-create/-detections-indicator-rule-example.png[Indicator m + [TIP] ==== -Before you create rules, create <> so +Before you create rules, create <> so they can be selected here. When alerts generated by the rule are investigated in the Timeline, Timeline query values are replaced with their corresponding alert field values. ==== -. (Optional) Use **Suppress alerts by** to reduce the number of repeated or duplicate alerts created by the rule. Refer to <> for more information. +. (Optional) Use **Suppress alerts by** to reduce the number of repeated or duplicate alerts created by the rule. Refer to <> for more information. + //// /* The following steps are repeated across multiple rule types. If you change anything @@ -351,7 +351,7 @@ When checking multiple fields, each unique combination of values from those fiel .. Use the **History Window Size** menu to specify the time range to search in minutes, hours, or days to determine if a term is new. The history window size must be larger than the rule interval plus additional look-back time, because the rule will look for terms where the only time(s) the term appears within the history window is _also_ within the rule interval and additional look-back time. + For example, if a rule has an interval of 5 minutes, no additional look-back time, and a history window size of 7 days, a term will be considered new only if the time it appears within the last 7 days is also within the last 5 minutes. Configure the rule interval and additional look-back time when you <>. -. (Optional) Use **Suppress alerts by** to reduce the number of repeated or duplicate alerts created by the rule. Refer to <> for more information. +. (Optional) Use **Suppress alerts by** to reduce the number of repeated or duplicate alerts created by the rule. Refer to <> for more information. + //// /* The following steps are repeated across multiple rule types. If you change anything @@ -387,7 +387,7 @@ Refer to the sections below to learn more about <> for more information. +. (Optional) Use **Suppress alerts by** to reduce the number of repeated or duplicate alerts created by the rule. Refer to <> for more information. + //// /* The following steps are repeated across multiple rule types. If you change anything @@ -517,7 +517,7 @@ If the `LIMIT` value and **Max alerts per run** value are different, the rule us [[esql-rule-limitations]] === {esql} rule limitations -If your {esql} query creates new fields that aren’t part of the ECS schema, they aren't mapped to the alerts index, so you can't search for or filter them in the Alerts table. As a workaround, create <>. +If your {esql} query creates new fields that aren’t part of the ECS schema, they aren't mapped to the alerts index, so you can't search for or filter them in the Alerts table. As a workaround, create <>. [discrete] [[custom-highlighted-esql-fields]] @@ -594,7 +594,7 @@ false-positive alerts. After you create the rule, you can find all custom highlighted fields in the About section of the rule details page. If the rule has alerts, you can find custom highlighted fields in the <> section of the alert details flyout. .. **Setup guide** (optional): Instructions on rule prerequisites such as required integrations, configuration steps, and anything else needed for the rule to work correctly. .. **Investigation guide** (optional): Information for analysts investigating -alerts created by the rule. You can also add action buttons to <> or <> using alert data. +alerts created by the rule. You can also add action buttons to <> or <> using alert data. .. **Author** (optional): The rule's authors. .. **License** (optional): The rule's license. .. **Elastic endpoint exceptions** (optional): Adds all Elastic Endpoint Security @@ -604,7 +604,7 @@ rule exceptions to this rule (refer to <> on the Rule details page. Additionally, all future exceptions added to the Endpoint Security rule also affect this rule. ==== -.. **Building block** (optional): Select to create a building-block rule. By default, alerts generated from a building-block rule are not displayed in the UI. See <> for more information. +.. **Building block** (optional): Select to create a building-block rule. By default, alerts generated from a building-block rule are not displayed in the UI. See <> for more information. .. **Max alerts per run** (optional): Specify the maximum number of alerts the rule can create each time it runs. Default is 100. .. **Indicator prefix override**: Define the location of indicator data within the structure of indicator documents. When the indicator match rule executes, it queries specified indicator indices and references this setting to locate fields with indicator data. This data is used to enrich indicator match alerts with metadata about matched threat indicators. The default value for this setting is `threat.indicator`. + @@ -660,7 +660,7 @@ run exactly at its scheduled time. . Click **Continue**. The **Rule actions** pane is displayed. . Do either of the following: + -** Continue onto <> and <> (optional). +** Continue onto <> and <> (optional). ** Create the rule (with or without activation). [discrete] @@ -671,7 +671,7 @@ Use actions to set up notifications sent via other systems when alerts are gener [NOTE] ==== -To use actions for alert notifications, you need the appropriate user role. For more information, see <>. +To use actions for alert notifications, you need the appropriate user role. For more information, see <>. ==== . Select a connector type to determine how notifications are sent. For example, if you select the {jira} connector, notifications are sent to your {jira} system. @@ -715,7 +715,7 @@ minutes at 14:03 but it does not run until 14:04, it will run again at 14:09. [IMPORTANT] ==== After you activate a rule, you can check if it is running as expected -using the <> on the Rules page. If you see +using the <> on the Rules page. If you see values in the `Gap` column, you can <>. When a rule fails to run, the {security-app} tries to rerun it at its next @@ -829,8 +829,8 @@ Example using the mustache "current element" notation `{{.}}` to output all the Use response actions to set up additional functionality that will run whenever a rule executes: -* **Osquery**: Include live Osquery queries with a custom query rule. When an alert is generated, Osquery automatically collects data on the system related to the alert. Refer to <> to learn more. -* **{elastic-defend}**: Automatically run response actions on an endpoint when rule conditions are met. For example, you can automatically isolate a host or terminate a process when specific activities or events are detected on the host. Refer to <> to learn more. +* **Osquery**: Include live Osquery queries with a custom query rule. When an alert is generated, Osquery automatically collects data on the system related to the alert. Refer to <> to learn more. +* **{elastic-defend}**: Automatically run response actions on an endpoint when rule conditions are met. For example, you can automatically isolate a host or terminate a process when specific activities or events are detected on the host. Refer to <> to learn more. [IMPORTANT] ==== @@ -845,7 +845,7 @@ You can preview any custom or prebuilt rule to find out how noisy it will be. Fo [NOTE] ==== -To preview rules, you must have the appropriate user role. Refer to <> for more information. +To preview rules, you must have the appropriate user role. Refer to <> for more information. ==== Click the **Rule preview** button while creating or editing a rule. The preview opens in a side panel, showing a histogram and table with the alerts you can expect, based on the defined rule settings and past events in your indices. diff --git a/docs/serverless/rules/rules-ui-management.asciidoc b/docs/serverless/rules/rules-ui-management.asciidoc index df2e9f8e92..1cba647572 100644 --- a/docs/serverless/rules/rules-ui-management.asciidoc +++ b/docs/serverless/rules/rules-ui-management.asciidoc @@ -1,4 +1,4 @@ -[[rules-ui-management]] +[[security-rules-ui-management]] = Manage detection rules :description: Manage your detection rules and enable Elastic prebuilt rules on the Rules page. @@ -64,7 +64,7 @@ You can edit an existing rule's settings, and can bulk edit settings for multipl [NOTE] ==== -For prebuilt Elastic rules, you can't modify most settings. You can only edit <> and <>. If you try to bulk edit with both prebuilt and custom rules selected, the action will affect only the rules that can be modified. +For prebuilt Elastic rules, you can't modify most settings. You can only edit <> and <>. If you try to bulk edit with both prebuilt and custom rules selected, the action will affect only the rules that can be modified. Similarly, rules will be skipped if they can't be modified by a bulk edit. For example, if you try to apply a tag to rules that already have that tag, or apply an index pattern to rules that use data views. ==== @@ -72,20 +72,20 @@ Similarly, rules will be skipped if they can't be modified by a bulk edit. For e . Go to **Rules** → **Detection rules (SIEM)**. . Do one of the following: + -** **Edit a single rule**: Select the **All actions** menu (image:images/icons/boxesHorizontal.svg[Actions menu]) on a rule, then select **Edit rule settings**. The **Edit rule settings** view opens, where you can modify the <>. +** **Edit a single rule**: Select the **All actions** menu (image:images/icons/boxesHorizontal.svg[Actions menu]) on a rule, then select **Edit rule settings**. The **Edit rule settings** view opens, where you can modify the <>. ** **Bulk edit multiple rules**: Select the rules you want to edit, then select an action from the **Bulk actions** menu: + *** **Index patterns**: Add or delete the index patterns used by all selected rules. *** **Tags**: Add or delete tags on all selected rules. *** **Custom highlighted fields**: Add custom highlighted fields on all selected rules. You can choose any fields that are available in the <>, or enter field names from other indices. To overwrite a rule's current set of custom highlighted fields, select the **Overwrite all selected rules' custom highlighted fields** option, then click **Save**. -*** **Add rule actions**: Add <> on all selected rules. If you add multiple actions, you can specify an action frequency for each of them. To overwrite the frequency of existing actions select the option to **Overwrite all selected rules actions**. +*** **Add rule actions**: Add <> on all selected rules. If you add multiple actions, you can specify an action frequency for each of them. To overwrite the frequency of existing actions select the option to **Overwrite all selected rules actions**. + [NOTE] ==== Rule actions won't run during a {kibana-ref}/maintenance-windows.html[maintenance window]. They'll resume running after the maintenance window ends. ==== ** **Update rule schedules**: Update the <> and look-back times on all selected rules. -** **Apply Timeline template**: Apply a specified <> to the selected rules. You can also choose **None** to remove Timeline templates from the selected rules. +** **Apply Timeline template**: Apply a specified <> to the selected rules. You can also choose **None** to remove Timeline templates from the selected rules. . On the page or flyout that opens, update the rule settings and actions. + [TIP] @@ -103,7 +103,7 @@ You can duplicate, enable, disable, delete, and snooze actions for rules: [NOTE] ==== -When duplicating a rule with exceptions, you can choose to duplicate the rule and its exceptions (active and expired), the rule and active exceptions only, or only the rule. If you duplicate the rule and its exceptions, copies of the exceptions are created and added to the duplicated rule's <>. If the original rule used exceptions from a shared exception list, the duplicated rule will reference the same shared exception list. +When duplicating a rule with exceptions, you can choose to duplicate the rule and its exceptions (active and expired), the rule and active exceptions only, or only the rule. If you duplicate the rule and its exceptions, copies of the exceptions are created and added to the duplicated rule's <>. If the original rule used exceptions from a shared exception list, the duplicated rule will reference the same shared exception list. ==== . Go to **Rules** → **Detection rules (SIEM)**. diff --git a/docs/serverless/rules/shared-exception-lists.asciidoc b/docs/serverless/rules/shared-exception-lists.asciidoc index 651ddec562..0e3fabb132 100644 --- a/docs/serverless/rules/shared-exception-lists.asciidoc +++ b/docs/serverless/rules/shared-exception-lists.asciidoc @@ -1,4 +1,4 @@ -[[shared-exception-lists]] +[[security-shared-exception-lists]] = Create and manage shared exception lists :description: Learn how to create and manage shared exception lists. @@ -61,7 +61,7 @@ Using wildcards can impact performance. To create a more efficient exception usi .. **Value**: Enter the value associated with the **Field**. To enter multiple values (when using `is one of` or `is not one of`), enter each value, then press **Return**. . Click **AND** or **OR** to create multiple conditions and define their relationships. . Click **Add nested condition** to create conditions using nested fields. This is only required for -<>. For all other fields, nested conditions should not be used. +<>. For all other fields, nested conditions should not be used. . Choose to add the exception to shared exception lists. + [NOTE] diff --git a/docs/serverless/rules/tuning-detection-signals.asciidoc b/docs/serverless/rules/tuning-detection-signals.asciidoc index 5747497219..fc4a3c9016 100644 --- a/docs/serverless/rules/tuning-detection-signals.asciidoc +++ b/docs/serverless/rules/tuning-detection-signals.asciidoc @@ -1,4 +1,4 @@ -[[tune-detection-signals]] +[[security-tune-detection-signals]] = Tune detection rules :description: Tune prebuilt and custom detection rules to optimize alert generation. @@ -8,7 +8,7 @@ preview:[] Using the {security-app}, you can tune prebuilt and custom detection rules to optimize alert generation. To reduce noise, you can: -* Add <> to detection rules. +* Add <> to detection rules. + [TIP] ==== @@ -22,7 +22,7 @@ aligned with local policy exceptions. This reduces noise while retaining actionable alerts. * Clone and modify detection rule risk scores, and use branching logic to map higher risk scores to higher priority workflows. -* Enable <> for custom query rules to reduce the number of repeated or duplicate alerts. +* Enable <> for custom query rules to reduce the number of repeated or duplicate alerts. For details about tuning rules for specific categories: @@ -180,7 +180,7 @@ Take the following steps to tune indicator match rules: ==== [discrete] -[[tune-detection-signals-noise-from-common-cloud-based-network-traffic]] +[[security-tune-detection-signals-noise-from-common-cloud-based-network-traffic]] === Noise from common cloud-based network traffic In cloud-based organizations, remote workers sometimes access services over the diff --git a/docs/serverless/rules/value-lists-exceptions.asciidoc b/docs/serverless/rules/value-lists-exceptions.asciidoc index c5a4d15692..5381c3c142 100644 --- a/docs/serverless/rules/value-lists-exceptions.asciidoc +++ b/docs/serverless/rules/value-lists-exceptions.asciidoc @@ -1,4 +1,4 @@ -[[value-lists-exceptions]] +[[security-value-lists-exceptions]] = Create and manage value lists :description: Make and manage value lists. @@ -15,7 +15,7 @@ Value lists are lists of items with the same {es} {ref}/mapping-types.html[data * `IP Ranges` * `Text` -After creating value lists, you can use `is in list` and `is not in list` operators to <>. +After creating value lists, you can use `is in list` and `is not in list` operators to <>. [TIP] ==== diff --git a/docs/serverless/sec-requirements.asciidoc b/docs/serverless/sec-requirements.asciidoc index 0e486f1878..d981f71552 100644 --- a/docs/serverless/sec-requirements.asciidoc +++ b/docs/serverless/sec-requirements.asciidoc @@ -1,4 +1,4 @@ -[[requirements-overview]] +[[security-requirements-overview]] = {elastic-sec} requirements :description: Requirements for using and configuring {elastic-sec}. @@ -10,47 +10,47 @@ The https://www.elastic.co/support/matrix[Support Matrix] page lists officially supported operating systems, platforms, and browsers on which components such as {beats}, {agent}, {elastic-defend}, and {elastic-endpoint} have been tested. [discrete] -[[requirements-overview-space-and-index-privileges]] +[[security-requirements-overview-space-and-index-privileges]] == Space and index privileges Provide access to {elastic-sec} by assigning a user the appropriate https://www.elastic.co/docs/current/serverless/general/assign-user-roles[predefined user role] or a https://www.elastic.co/docs/current/serverless/custom-roles[custom role] with specific privileges. To use {elastic-sec}, your role must have at least: -* `Read` privilege for the `Security` feature in the {kibana-ref}/xpack-spaces.html[space]. This grants you `Read` access to all features in {elastic-sec} except cases. You need additional <> to use cases. +* `Read` privilege for the `Security` feature in the {kibana-ref}/xpack-spaces.html[space]. This grants you `Read` access to all features in {elastic-sec} except cases. You need additional <> to use cases. * `Read` and `view_index_metadata` privileges for all {elastic-sec} indices, such as `filebeat-*`, `packetbeat-*`, `logs-*`, and `endgame-*` indices. [NOTE] ==== -<> describes how to modify {elastic-sec} indices. +<> describes how to modify {elastic-sec} indices. ==== For more information about index privileges, refer to {ref}/security-privileges.html[{es} security privileges]. [discrete] -[[requirements-overview-feature-specific-requirements]] +[[security-requirements-overview-feature-specific-requirements]] == Feature-specific requirements There are some additional requirements for specific features: -* <> -* <> -* <> -* <> -* <> -* <> +* <> +* <> +* <> +* <> +* <> +* <> [discrete] -[[requirements-overview-advanced-configuration-and-ui-options]] +[[security-requirements-overview-advanced-configuration-and-ui-options]] == Advanced configuration and UI options -<> describes how to modify advanced settings, such as the +<> describes how to modify advanced settings, such as the {elastic-sec} indices, default time intervals used in filters, and IP reputation links. [discrete] -[[requirements-overview-third-party-collectors-mapped-to-ecs]] +[[security-requirements-overview-third-party-collectors-mapped-to-ecs]] == Third-party collectors mapped to ECS The {ecs-ref}[Elastic Common Schema (ECS)] defines a common set of fields to be used for storing event data in Elasticsearch. ECS helps users normalize their event data @@ -59,5 +59,5 @@ events. {elastic-sec} can ingest and normalize events from any ECS-compliant dat [IMPORTANT] ==== -{elastic-sec} requires {ecs-ref}[ECS-compliant data]. If you use third-party data collectors to ship data to {es}, the data must be mapped to ECS. <> lists ECS fields used in {elastic-sec}. +{elastic-sec} requires {ecs-ref}[ECS-compliant data]. If you use third-party data collectors to ship data to {es}, the data must be mapped to ECS. <> lists ECS fields used in {elastic-sec}. ==== diff --git a/docs/serverless/security-overview.asciidoc b/docs/serverless/security-overview.asciidoc index ca1d58a2a2..06a559f4a8 100644 --- a/docs/serverless/security-overview.asciidoc +++ b/docs/serverless/security-overview.asciidoc @@ -1,4 +1,4 @@ -[[overview]] +[[security-overview]] = {elastic-sec} overview :keywords: serverless, security, reference @@ -19,11 +19,11 @@ preview:[] == Learn more * <>: Navigate {elastic-sec}'s various tools and interfaces. -* <>: Use {elastic-sec}'s detection engine with custom and prebuilt rules. -* <>: Enable cloud native security capabilities such as Cloud and Kubernetes security posture management, cloud native vulnerability management, and cloud workload protection for Kubernetes and VMs. -* <>: Enable key endpoint protection capabilities like event collection and malicious activity prevention. +* <>: Use {elastic-sec}'s detection engine with custom and prebuilt rules. +* <>: Enable cloud native security capabilities such as Cloud and Kubernetes security posture management, cloud native vulnerability management, and cloud workload protection for Kubernetes and VMs. +* <>: Enable key endpoint protection capabilities like event collection and malicious activity prevention. * https://www.elastic.co/products/stack/machine-learning[{ml-cap}]: Enable built-in {ml} tools to help you identify malicious behavior. -* <>: Leverage {elastic-sec}'s detection engine and {ml} capabilities to generate comprehensive risk analytics for hosts and users. +* <>: Leverage {elastic-sec}'s detection engine and {ml} capabilities to generate comprehensive risk analytics for hosts and users. * <>: Ask AI Assistant questions about how to use {elastic-sec}, how to understand particular alerts and other documents, and how to write {esql} queries. [discrete] @@ -42,4 +42,4 @@ view, analyze and visualize data stored in {es} indices. [[self-protection]] === {elastic-endpoint} self-protection -For information about {elastic-endpoint}'s tamper-protection features, refer to <>. +For information about {elastic-endpoint}'s tamper-protection features, refer to <>. diff --git a/docs/serverless/security-ui.asciidoc b/docs/serverless/security-ui.asciidoc index b04a7941ad..545029f20c 100644 --- a/docs/serverless/security-ui.asciidoc +++ b/docs/serverless/security-ui.asciidoc @@ -86,7 +86,7 @@ Use the https://www.elastic.co/docs/current/serverless/elasticsearch/explore-you [[security-ui-dashboards]] === Dashboards -Expand this section to access the Overview, Detection & Response, Kubernetes, Cloud Security Posture, Cloud Native Vulnerability Management, and Entity Analytics dashboards, which provide interactive visualizations that summarize your data. You can also create and view custom dashboards. Refer to <> for more information. +Expand this section to access the Overview, Detection & Response, Kubernetes, Cloud Security Posture, Cloud Native Vulnerability Management, and Entity Analytics dashboards, which provide interactive visualizations that summarize your data. You can also create and view custom dashboards. Refer to <> for more information. [role="screenshot"] image::images/es-ui-overview/-dashboards-dashboards-landing-page.png[The dashboards landing page, 75%] @@ -97,11 +97,11 @@ image::images/es-ui-overview/-dashboards-dashboards-landing-page.png[The dashboa Expand this section to access the following pages: -* <>: Create and manage rules to monitor suspicious events. +* <>: Create and manage rules to monitor suspicious events. + [role="screenshot"] image::images/es-ui-overview/-detections-all-rules.png[Rules page] -* <>: View, enable, or disable benchmark rules. +* <>: View, enable, or disable benchmark rules. + [role="screenshot"] image::images/es-ui-overview/-cloud-native-security-benchmark-rules.png[Benchmark Rules page] @@ -109,7 +109,7 @@ image::images/es-ui-overview/-cloud-native-security-benchmark-rules.png[Benchmar + [role="screenshot"] image::images/es-ui-overview/-detections-rule-exceptions-page.png[Shared Exception Lists page] -* <>: Review your coverage of MITRE ATT&CK® tactics and techniques, based on installed rules. +* <>: Review your coverage of MITRE ATT&CK® tactics and techniques, based on installed rules. + [role="screenshot"] image::images/es-ui-overview/-detections-rules-coverage.png[MITRE ATT&CK® coverage page] @@ -118,7 +118,7 @@ image::images/es-ui-overview/-detections-rules-coverage.png[MITRE ATT&CK® cover [[security-ui-alerts]] === Alerts -View and manage alerts to monitor activity within your network. Refer to <> for more information. +View and manage alerts to monitor activity within your network. Refer to <> for more information. [role="screenshot"] image::images/es-ui-overview/-detections-alert-page.png[] @@ -127,7 +127,7 @@ image::images/es-ui-overview/-detections-alert-page.png[] [[security-ui-findings]] === Findings -Identify misconfigurations and vulnerabilities in your cloud infrastructure. For setup instructions, refer to <>, <>, or <>. +Identify misconfigurations and vulnerabilities in your cloud infrastructure. For setup instructions, refer to <>, <>, or <>. [role="screenshot"] image::images/findings-page/-cloud-native-security-findings-page.png[Findings page] @@ -136,7 +136,7 @@ image::images/findings-page/-cloud-native-security-findings-page.png[Findings pa [[security-ui-cases]] === Cases -Open and track security issues. Refer to <> to learn more. +Open and track security issues. Refer to <> to learn more. [role="screenshot"] image::images/es-ui-overview/-cases-cases-home-page.png[Cases page] @@ -147,7 +147,7 @@ image::images/es-ui-overview/-cases-cases-home-page.png[Cases page] Expand this section to access the following pages: -* <>: Investigate alerts and complex threats — such as lateral movement — in your network. Timelines are interactive and allow you to share your findings with other team members. +* <>: Investigate alerts and complex threats — such as lateral movement — in your network. Timelines are interactive and allow you to share your findings with other team members. + [role="screenshot"] image::images/es-ui-overview/-events-timeline-ui.png[Timeline page] @@ -156,13 +156,13 @@ image::images/es-ui-overview/-events-timeline-ui.png[Timeline page] ==== Click the **Timeline** button at the bottom of the {security-app} to start an investigation. ==== -* <>: Deploy Osquery with {agent}, then run and schedule queries. +* <>: Deploy Osquery with {agent}, then run and schedule queries. [discrete] [[security-ui-intelligence]] === Intelligence -The Intelligence section contains the Indicators page, which collects data from enabled threat intelligence feeds and provides a centralized view of indicators of compromise (IoCs). Refer to <> to learn more. +The Intelligence section contains the Indicators page, which collects data from enabled threat intelligence feeds and provides a centralized view of indicators of compromise (IoCs). Refer to <> to learn more. [role="screenshot"] image::images/es-ui-overview/-cases-indicators-table.png[Indicators page] @@ -173,15 +173,15 @@ image::images/es-ui-overview/-cases-indicators-table.png[Indicators page] Expand this section to access the following pages: -* <>: Examine key metrics for host-related security events using graphs, charts, and interactive data tables. +* <>: Examine key metrics for host-related security events using graphs, charts, and interactive data tables. + [role="screenshot"] image::images/es-ui-overview/-management-hosts-hosts-ov-pg.png[Hosts page] -* <>: Explore the interactive map to discover key network activity metrics and investigate network events further in Timeline. +* <>: Explore the interactive map to discover key network activity metrics and investigate network events further in Timeline. + [role="screenshot"] image::images/es-ui-overview/-getting-started-network-ui.png[Network page] -* <>: Access a comprehensive overview of user data to help you understand authentication and user behavior within your environment. +* <>: Access a comprehensive overview of user data to help you understand authentication and user behavior within your environment. + [role="screenshot"] image::images/es-ui-overview/-getting-started-users-users-page.png[Users page] @@ -194,18 +194,18 @@ The Assets section allows you to manage the following features: * {fleet-guide}/manage-agents-in-fleet.html[{fleet}] * {fleet-guide}/integrations.html[{integrations}] -* <> +* <> + -** <>: View and manage hosts running {elastic-defend}. -** <>: View and manage {elastic-defend} integration policies. -** <>: View and manage trusted Windows, macOS, and Linux applications. -** <>: View and manage event filters, which allow you to filter endpoint events you don't need to want stored in {es}. -** <>: View and manage host isolation exceptions, which specify IP addresses that can communicate with your hosts even when those hosts are blocked from your network. -** <>: View and manage the blocklist, which allows you to prevent specified applications from running on hosts, extending the list of processes that {elastic-defend} considers malicious. -** <>: Find the history of response actions performed on hosts. -* <> +** <>: View and manage hosts running {elastic-defend}. +** <>: View and manage {elastic-defend} integration policies. +** <>: View and manage trusted Windows, macOS, and Linux applications. +** <>: View and manage event filters, which allow you to filter endpoint events you don't need to want stored in {es}. +** <>: View and manage host isolation exceptions, which specify IP addresses that can communicate with your hosts even when those hosts are blocked from your network. +** <>: View and manage the blocklist, which allows you to prevent specified applications from running on hosts, extending the list of processes that {elastic-defend} considers malicious. +** <>: Find the history of response actions performed on hosts. +* <> + -** <>: Identify and block unexpected system behavior in Kubernetes containers. +** <>: Identify and block unexpected system behavior in Kubernetes containers. [discrete] [[security-ui-ml-cap]] diff --git a/docs/serverless/settings/advanced-settings.asciidoc b/docs/serverless/settings/advanced-settings.asciidoc index 1c15e82c0c..dcdefce296 100644 --- a/docs/serverless/settings/advanced-settings.asciidoc +++ b/docs/serverless/settings/advanced-settings.asciidoc @@ -1,4 +1,4 @@ -[[advanced-settings]] +[[security-advanced-settings]] = Advanced settings :description: Update advanced {elastic-sec} settings. @@ -11,10 +11,10 @@ The advanced settings determine: * Which indices {elastic-sec} uses to retrieve data * {ml-cap} anomaly score display threshold * The navigation menu style used throughout the {security-app} -* Whether the news feed is displayed on the <> +* Whether the news feed is displayed on the <> * The default time interval used to filter {elastic-sec} pages * The default {elastic-sec} pages refresh time -* Which IP reputation links appear on <> pages +* Which IP reputation links appear on <> pages * Whether cross-cluster search (CCS) privilege warnings are displayed * Whether related integrations are displayed on the Rules page tables * The options provided in the alert tag menu @@ -31,7 +31,7 @@ permanently. ==== [discrete] -[[advanced-settings-access-advanced-settings]] +[[security-advanced-settings-access-advanced-settings]] == Access advanced settings To access advanced settings, go to **Project Settings** → **Management** → **Advanced Settings**, then scroll down to **Security Solution** settings. @@ -83,7 +83,7 @@ If you leave the `-*elastic-cloud-logs-*` index pattern selected, all Elastic cl ==== {elastic-sec} requires {ecs-ref}[ECS-compliant data]. If you use third-party data collectors to ship data to {es}, the data must be mapped to ECS. -<> lists ECS fields used in {elastic-sec}. +<> lists ECS fields used in {elastic-sec}. ==== [discrete] @@ -114,7 +114,7 @@ Elastic transmits certain information about Elastic Security when users interact To learn more, refer to our https://www.elastic.co/legal/privacy-statement[Privacy Statement]. [discrete] -[[advanced-settings-set-machine-learning-score-threshold]] +[[security-advanced-settings-set-machine-learning-score-threshold]] == Set machine learning score threshold When security <> are enabled, this setting @@ -123,7 +123,7 @@ determines the threshold above which anomaly scores appear in {elastic-sec}: * `securitySolution:defaultAnomalyScore` [discrete] -[[advanced-settings-modify-news-feed-settings]] +[[security-advanced-settings-modify-news-feed-settings]] == Modify news feed settings You can change these settings, which affect the news feed displayed on the @@ -135,19 +135,19 @@ Security **Overview** page. retrieved. [discrete] -[[advanced-settings-enable-asset-criticality-workflows]] +[[security-advanced-settings-enable-asset-criticality-workflows]] == Enable asset criticality workflows The `securitySolution:enableAssetCriticality` setting determines whether asset criticality is included as a risk input to entity risk scoring. This setting is turned off by default. Turn it on to enable asset criticality workflows and to use asset criticality as part of entity risk scoring. [discrete] -[[advanced-settings-exclude-cold-and-frozen-tier-data-from-analyzer-queries]] +[[security-advanced-settings-exclude-cold-and-frozen-tier-data-from-analyzer-queries]] == Exclude cold and frozen tier data from analyzer queries -Including data from cold and frozen {ref}/data-tiers.html[data tiers] in <> queries may result in performance degradation. The `securitySolution:excludeColdAndFrozenTiersInAnalyzer` setting allows you to exclude this data from analyzer queries. This setting is turned off by default. +Including data from cold and frozen {ref}/data-tiers.html[data tiers] in <> queries may result in performance degradation. The `securitySolution:excludeColdAndFrozenTiersInAnalyzer` setting allows you to exclude this data from analyzer queries. This setting is turned off by default. [discrete] -[[advanced-settings-change-the-default-search-interval-and-data-refresh-time]] +[[security-advanced-settings-change-the-default-search-interval-and-data-refresh-time]] == Change the default search interval and data refresh time These settings determine the default time interval and refresh rate {elastic-sec} diff --git a/docs/serverless/settings/manage-settings.asciidoc b/docs/serverless/settings/manage-settings.asciidoc index 6b52cfc82c..d944c50f15 100644 --- a/docs/serverless/settings/manage-settings.asciidoc +++ b/docs/serverless/settings/manage-settings.asciidoc @@ -1,4 +1,4 @@ -[[manage-settings]] +[[security-manage-settings]] = Manage settings :keywords: serverless, security, overview @@ -8,5 +8,5 @@ preview:[] These pages explain how to manage settings in various areas of the {security-app}: * <>: Configure project-wide settings related to users, billing, data management, and more. -* <>: Update advanced {elastic-sec} settings. -* <>: Learn about requirements for specific features. +* <>: Update advanced {elastic-sec} settings. +* <>: Learn about requirements for specific features. diff --git a/docs/serverless/troubleshooting/troubleshoot-endpoints.asciidoc b/docs/serverless/troubleshooting/troubleshoot-endpoints.asciidoc index 41203803cd..4d98f25ccf 100644 --- a/docs/serverless/troubleshooting/troubleshoot-endpoints.asciidoc +++ b/docs/serverless/troubleshooting/troubleshoot-endpoints.asciidoc @@ -1,4 +1,4 @@ -[[troubleshoot-endpoints]] +[[security-troubleshoot-endpoints]] = Troubleshoot {elastic-defend} :keywords: serverless, security, troubleshooting @@ -9,7 +9,7 @@ preview:[] -This topic covers common troubleshooting issues when using {elastic-defend}'s <>. +This topic covers common troubleshooting issues when using {elastic-defend}'s <>. [discrete] [[ts-endpoints]] @@ -32,7 +32,7 @@ Common causes of failure in the {elastic-defend} integration policy include miss * <> (macOS) * <> (macOS) -* <> (Linux) +* <> (Linux) [TIP] ==== @@ -45,7 +45,7 @@ If the {elastic-defend} integration policy is not the cause of the `Unhealthy` a ===== If you have an `Unhealthy` {agent} status with the message `Disabled due to potential system deadlock`, that means malware protection was disabled on the {elastic-defend} integration policy due to errors while monitoring a Linux host. -You can resolve the issue by configuring the policy's <> related to **fanotify**, a Linux feature that monitors file system events. By default, {elastic-defend} works with fanotify to monitor specific file system types that Elastic has tested for compatibility, and ignores other unknown file system types. +You can resolve the issue by configuring the policy's <> related to **fanotify**, a Linux feature that monitors file system events. By default, {elastic-defend} works with fanotify to monitor specific file system types that Elastic has tested for compatibility, and ignores other unknown file system types. If your network includes nonstandard, proprietary, or otherwise unrecognized Linux file systems that cause errors while being monitored, you can configure {elastic-defend} to ignore those file systems. This allows {elastic-defend} to resume monitoring and protecting the hosts on the integration policy. @@ -93,7 +93,7 @@ image::images/ts-management/-troubleshooting-transforms-start.png[Transforms pag After {agent} installs Endpoint, Endpoint connects to {agent} over a local relay connection to report its health status and receive policy updates and response action requests. If that connection cannot be established, the {elastic-defend} integration will cause {agent} to be in an `Unhealthy` status, and Endpoint won't operate properly. [discrete] -[[troubleshoot-endpoints-identify-if-the-issue-is-happening]] +[[security-troubleshoot-endpoints-identify-if-the-issue-is-happening]] === Identify if the issue is happening You can identify if this issue is happening in the following ways: @@ -119,7 +119,7 @@ If this problem starts happening after Endpoint has already been installed and w ==== [discrete] -[[troubleshoot-endpoints-examine-endpoint-logs]] +[[security-troubleshoot-endpoints-examine-endpoint-logs]] === Examine Endpoint logs If you've confirmed that the issue is happening, you can look at Endpoint log messages to identify the cause: @@ -128,7 +128,7 @@ If you've confirmed that the issue is happening, you can look at Endpoint log me * `Unable to make GRPC connection in deadline(60s). Fetching connection info again` means that Endpoint's original connection to {agent} over port `6788` worked, but the connection over port `6789` is failing. [discrete] -[[troubleshoot-endpoints-resolve-the-issue]] +[[security-troubleshoot-endpoints-resolve-the-issue]] === Resolve the issue To debug and resolve the issue, follow these steps: @@ -152,12 +152,12 @@ To debug and resolve the issue, follow these steps: After deploying {elastic-defend}, you might encounter warnings or errors in the endpoint's **Policy status** in {fleet} if your mobile device management (MDM) is misconfigured or certain permissions for {elastic-endpoint} aren't granted. The following sections explain issues that can cause warnings or failures in the endpoint's policy status. [discrete] -[[troubleshoot-endpoints-connect-kernel-has-failed]] +[[security-troubleshoot-endpoints-connect-kernel-has-failed]] === Connect Kernel has failed This means that the system extension or kernel extension was not approved. Consult the following topics for approving the system extension, either with MDM or without MDM: -* <> +* <> * <> You can validate the system extension is loaded by running @@ -170,12 +170,12 @@ sudo systemextensionsctl list | grep co.elastic.systemextension In the command output, the system extension should be marked as "active enabled". [discrete] -[[troubleshoot-endpoints-connect-kernel-has-failed-and-the-system-extension-is-loaded]] +[[security-troubleshoot-endpoints-connect-kernel-has-failed-and-the-system-extension-is-loaded]] === Connect Kernel has failed and the system extension is loaded If the system extension is loaded and kernel connection still fails, this means that Full Disk Access was not granted. {elastic-endpoint} requires Full Disk Access to subscribe to system events via the {elastic-defend} framework, which is one of the primary sources of eventing information used by {elastic-endpoint}. Consult the following topics for granting Full Disk Access, either with MDM or without MDM: -* <> +* <> * <> You can validate that Full Disk Access is approved by running @@ -188,12 +188,12 @@ sudo /Library/Elastic/Endpoint/elastic-endpoint test install If the command output doesn't contain a message about enabling Full Disk Access, the approval was successful. [discrete] -[[troubleshoot-endpoints-detect-network-events-has-failed]] +[[security-troubleshoot-endpoints-detect-network-events-has-failed]] === Detect Network Events has failed This means that the network extension content filtering was not approved. Consult the following topics for approving network content filtering, either with MDM or without MDM: -* <> +* <> * <> You can validate that network content filtering is approved by running @@ -206,12 +206,12 @@ sudo /Library/Elastic/Endpoint/elastic-endpoint test install If the command output doesn't contain a message about approving network content filtering, the approval was successful. [discrete] -[[troubleshoot-endpoints-full-disk-access-has-a-warning]] +[[security-troubleshoot-endpoints-full-disk-access-has-a-warning]] === Full Disk Access has a warning This means that Full Disk Access was not granted for one or all {elastic-endpoint} components. Consult the following topics for granting Full Disk Access, either with MDM or without MDM: -* <> +* <> * <> You can validate that Full Disk Access is approved by running diff --git a/docs/serverless/troubleshooting/troubleshooting-intro.asciidoc b/docs/serverless/troubleshooting/troubleshooting-intro.asciidoc index 3ef3f512e8..e1438ed8f8 100644 --- a/docs/serverless/troubleshooting/troubleshooting-intro.asciidoc +++ b/docs/serverless/troubleshooting/troubleshooting-intro.asciidoc @@ -1,4 +1,4 @@ -[[troubleshooting-ov]] +[[security-troubleshooting-ov]] = Troubleshooting :description: Resolve issues in {elastic-sec}. @@ -6,5 +6,5 @@ This section covers common {elastic-sec} related issues and how to resolve them. -* <> -* <> +* <> +* <> diff --git a/docs/serverless/troubleshooting/ts-detection-rules.asciidoc b/docs/serverless/troubleshooting/ts-detection-rules.asciidoc index 160a749017..7056b3c5d4 100644 --- a/docs/serverless/troubleshooting/ts-detection-rules.asciidoc +++ b/docs/serverless/troubleshooting/ts-detection-rules.asciidoc @@ -1,4 +1,4 @@ -[[ts-detection-rules]] +[[security-ts-detection-rules]] = Troubleshoot detection rules :description: Covers common troubleshooting issues when creating or managing detection rules. @@ -10,7 +10,7 @@ preview:[] -This topic covers common troubleshooting issues when creating or managing <>. +This topic covers common troubleshooting issues when creating or managing <>. [discrete] [[ML-rules-ts]] diff --git a/docs/serverless/what-is-security-serverless.asciidoc b/docs/serverless/what-is-security-serverless.asciidoc index 884f8b349b..d10b3af932 100644 --- a/docs/serverless/what-is-security-serverless.asciidoc +++ b/docs/serverless/what-is-security-serverless.asciidoc @@ -17,15 +17,15 @@ Serverless projects provide you with the existing {elastic-sec} on-premise and E [discrete] == Get started -* <>: Create your first {serverless-short} Security project. -* <>: Learn how to add your own data to {elastic-sec}. +* <>: Create your first {serverless-short} Security project. +* <>: Learn how to add your own data to {elastic-sec}. [discrete] == How to -* <>: Activate prebuilt rules from Elastic, and create your own custom rules. -* <>: Install and configure real-time endpoint protection with {elastic-defend}. -* <>: Improve cloud security posture, scan for vulnerabilities, and monitor workloads. -* <>: Analyze potential threats and launch investigations. -* <>: Query security event data and hunt for threats. -* <>: Use prebuilt dashboards and create your own visualizations. +* <>: Activate prebuilt rules from Elastic, and create your own custom rules. +* <>: Install and configure real-time endpoint protection with {elastic-defend}. +* <>: Improve cloud security posture, scan for vulnerabilities, and monitor workloads. +* <>: Analyze potential threats and launch investigations. +* <>: Query security event data and hunt for threats. +* <>: Use prebuilt dashboards and create your own visualizations. From 08ef6a5ffa077ba9d2d8f695a6b7423c4f763fff Mon Sep 17 00:00:00 2001 From: Colleen McGinnis Date: Wed, 30 Oct 2024 08:27:34 -0500 Subject: [PATCH 05/14] fix attributes in parentheses --- .../AI-for-security/ai-assistant-esql-queries.asciidoc | 2 +- .../response-actions-history.asciidoc | 2 +- docs/serverless/investigate/cases-open-manage.asciidoc | 6 +++--- docs/serverless/investigate/timelines-ui.asciidoc | 2 +- docs/serverless/rules/rules-ui-create.asciidoc | 4 ++-- 5 files changed, 8 insertions(+), 8 deletions(-) diff --git a/docs/serverless/AI-for-security/ai-assistant-esql-queries.asciidoc b/docs/serverless/AI-for-security/ai-assistant-esql-queries.asciidoc index b0ec85cbc8..bb6ef027cc 100644 --- a/docs/serverless/AI-for-security/ai-assistant-esql-queries.asciidoc +++ b/docs/serverless/AI-for-security/ai-assistant-esql-queries.asciidoc @@ -4,7 +4,7 @@ :description: AI Assistant has specialized {esql} capabilities. :keywords: security, overview, get-started -Elastic AI Assistant can help you learn about and leverage the Elasticsearch Query Language {(esql}). +Elastic AI Assistant can help you learn about and leverage the Elasticsearch Query Language ({esql}). With AI Assistant's <> enabled, AI Assistant benefits from specialized training data that enables it to answer questions related to {esql} at an expert level. diff --git a/docs/serverless/endpoint-response-actions/response-actions-history.asciidoc b/docs/serverless/endpoint-response-actions/response-actions-history.asciidoc index a998a8fe5d..2ed372886d 100644 --- a/docs/serverless/endpoint-response-actions/response-actions-history.asciidoc +++ b/docs/serverless/endpoint-response-actions/response-actions-history.asciidoc @@ -36,6 +36,6 @@ To filter and expand the information in the response actions history: ** **Hosts**: Show actions performed on specific endpoints. (This menu is only available on the **Response actions history** page for all endpoints.) ** **Actions**: Show specific actions types. ** **Statuses**: Show actions with a specific status. -** **Types**: Show actions based on the endpoint protection agent type {(elastic-defend} or a third-party agent), and how the action was triggered (manually by a user or automatically by a detection rule). +** **Types**: Show actions based on the endpoint protection agent type ({elastic-defend} or a third-party agent), and how the action was triggered (manually by a user or automatically by a detection rule). * Use the date and time picker to display actions within a specific time range. * Click the expand arrow on the right to display more details about an action. diff --git a/docs/serverless/investigate/cases-open-manage.asciidoc b/docs/serverless/investigate/cases-open-manage.asciidoc index 8fcf399de1..352c8509b1 100644 --- a/docs/serverless/investigate/cases-open-manage.asciidoc +++ b/docs/serverless/investigate/cases-open-manage.asciidoc @@ -59,7 +59,7 @@ You can configure email notifications that occur when users are assigned to case For hosted {kib} on {ess}: 1. Add the email addresses to the monitoring email allowlist. Follow the steps in - [Send alerts by email]{(cloud}/ec-watcher.html#ec-watcher-allowlist). + [Send alerts by email]({cloud}/ec-watcher.html#ec-watcher-allowlist). You do not need to take any more steps to configure an email connector or update {kib} user settings, since the preconfigured Elastic-Cloud-SMTP connector is @@ -70,7 +70,7 @@ For self-managed {kib}: 1. Create a preconfigured email connector. - At this time, email notifications support only [preconfigured email connectors]{(kibana-ref}/pre-configured-connectors.html), + At this time, email notifications support only [preconfigured email connectors]({kibana-ref}/pre-configured-connectors.html), which are defined in the `kibana.yml` file. @@ -78,7 +78,7 @@ For self-managed {kib}: your email connector. 1. If you want the email notifications to contain links back to the case, you - must configure the [server.publicBaseUrl]{(kibana-ref}/settings.html#server-publicBaseUrl) setting. + must configure the [server.publicBaseUrl]({kibana-ref}/settings.html#server-publicBaseUrl) setting. When you subsequently add assignees to cases, they receive an email. diff --git a/docs/serverless/investigate/timelines-ui.asciidoc b/docs/serverless/investigate/timelines-ui.asciidoc index 7154b1dc83..3cf19435fa 100644 --- a/docs/serverless/investigate/timelines-ui.asciidoc +++ b/docs/serverless/investigate/timelines-ui.asciidoc @@ -226,7 +226,7 @@ From the **Correlation** tab, you can also do the following: [[esql-in-timeline]] == Use {esql} to investigate events -The {ref}/esql.html[Elasticsearch Query Language {(esql})] provides a powerful way to filter, transform, and analyze event data stored in {es}. {esql} queries use "pipes" to manipulate and transform data in a step-by-step fashion. This approach allows you to compose a series of operations, where the output of one operation becomes the input for the next, enabling complex data transformations and analysis. +The {ref}/esql.html[Elasticsearch Query Language ({esql})] provides a powerful way to filter, transform, and analyze event data stored in {es}. {esql} queries use "pipes" to manipulate and transform data in a step-by-step fashion. This approach allows you to compose a series of operations, where the output of one operation becomes the input for the next, enabling complex data transformations and analysis. You can use {esql} in Timeline by opening the **{esql}** tab. From there, you can: diff --git a/docs/serverless/rules/rules-ui-create.asciidoc b/docs/serverless/rules/rules-ui-create.asciidoc index f602e5d344..1cddaa73c7 100644 --- a/docs/serverless/rules/rules-ui-create.asciidoc +++ b/docs/serverless/rules/rules-ui-create.asciidoc @@ -738,14 +738,14 @@ Refer to {kibana-ref}/rule-action-variables.html#alert-summary-action-variables[ * `{{context.alerts}}`: Array of detected alerts * `{{{context.results_link}}}`: URL to the alerts * `{{context.rule.anomaly_threshold}}`: Anomaly threshold score above which -alerts are generated {(ml} rules only) +alerts are generated ({ml} rules only) * `{{context.rule.description}}`: Rule description * `{{context.rule.false_positives}}`: Rule false positives * `{{context.rule.filters}}`: Rule filters (query rules only) * `{{context.rule.id}}`: Unique rule ID returned after creating the rule * `{{context.rule.index}}`: Indices rule runs on (query rules only) * `{{context.rule.language}}`: Rule query language (query rules only) -* `{{context.rule.machine_learning_job_id}}`: ID of associated {ml} job {(ml} +* `{{context.rule.machine_learning_job_id}}`: ID of associated {ml} job ({ml} rules only) * `{{context.rule.max_signals}}`: Maximum allowed number of alerts per rule execution From cac5e67258a58ce444a7d4752f1b833cc9eb887e Mon Sep 17 00:00:00 2001 From: Colleen McGinnis Date: Wed, 30 Oct 2024 10:06:41 -0500 Subject: [PATCH 06/14] fix invalid ids --- .../AI-for-security/ai-assistant-alert-triage.asciidoc | 4 ++-- .../AI-for-security/ai-assistant-alert-triage.mdx | 8 ++++---- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/serverless/AI-for-security/ai-assistant-alert-triage.asciidoc b/docs/serverless/AI-for-security/ai-assistant-alert-triage.asciidoc index b1e92f3b71..44c30779c5 100644 --- a/docs/serverless/AI-for-security/ai-assistant-alert-triage.asciidoc +++ b/docs/serverless/AI-for-security/ai-assistant-alert-triage.asciidoc @@ -11,7 +11,7 @@ Elastic AI Assistant can help you enhance and streamline your alert triage workf AI Assistant can help you interpret an alert and understand its context. When you view an alert in {elastic-sec}, details such as related documents, hosts, and users appear alongside a synopsis of the events that triggered the alert. This data provides a starting point for understanding a potential threat. AI Assistant can answer questions about this data and offer insights and actionable recommendations to remediate the issue. [discrete] -[[Use AI Assistant to triage an alert]] +[[use-ai-assistant-to-triage-an-alert]] == Use AI Assistant to triage an alert . Choose an alert to investigate, then click the **View details** button from the Alerts table. @@ -22,7 +22,7 @@ Once you’ve submitted your query, the AI Assistant will process the informatio . (Optional) Ask follow-up questions, provide additional information for further analysis, and request clarification. The response is not a static report. [discrete] -[[Generate triage reports]] +[[generate-triage-reports]] == Generate triage reports Elastic AI Assistant can streamline the documentation and report generation process by providing clear records of security incidents, their scope and impact, and your remediation efforts. You can use AI Assistant to create summaries or reports for stakeholders that include key event details, findings, and diagrams. Once the AI Assistant has finished analyzing one or more alerts, you can generate reports by using prompts such as: diff --git a/docs/serverless/AI-for-security/ai-assistant-alert-triage.mdx b/docs/serverless/AI-for-security/ai-assistant-alert-triage.mdx index 6251add6f9..9833729339 100644 --- a/docs/serverless/AI-for-security/ai-assistant-alert-triage.mdx +++ b/docs/serverless/AI-for-security/ai-assistant-alert-triage.mdx @@ -14,18 +14,18 @@ Elastic AI Assistant can help you enhance and streamline your alert triage workf AI Assistant can help you interpret an alert and understand its context. When you view an alert in ((elastic-sec)), details such as related documents, hosts, and users appear alongside a synopsis of the events that triggered the alert. This data provides a starting point for understanding a potential threat. AI Assistant can answer questions about this data and offer insights and actionable recommendations to remediate the issue. -
+
## Use AI Assistant to triage an alert 1. Choose an alert to investigate, then click the **View details** button from the Alerts table. -2. On the details flyout, click **Chat** to launch AI Assistant. Data related to the selected alert is automatically added to the prompt. +2. On the details flyout, click **Chat** to launch AI Assistant. Data related to the selected alert is automatically added to the prompt. 3. Click **Alert (from summary)** to view which alert fields will be shared with AI Assistant. (For more information about selecting which fields to send, and to learn about anonymizing your data, refer to AI Assistant.) 4. (Optional) Click a quick prompt to use it as a starting point for your query, for example, **Alert summarization**. Customize the prompt and add detail to improve AI Assistant's response. Once you’ve submitted your query, the AI Assistant will process the information and provide a detailed response. Depending on your prompt and which alert data you included, its response can include a thorough analysis of the alert that highlights key elements such as the nature of the potential threat, potential impact, and suggested response actions. 6. (Optional) Ask follow-up questions, provide additional information for further analysis, and request clarification. The response is not a static report. -
+
## Generate triage reports Elastic AI Assistant can streamline the documentation and report generation process by providing clear records of security incidents, their scope and impact, and your remediation efforts. You can use AI Assistant to create summaries or reports for stakeholders that include key event details, findings, and diagrams. Once the AI Assistant has finished analyzing one or more alerts, you can generate reports by using prompts such as: @@ -34,6 +34,6 @@ Elastic AI Assistant can streamline the documentation and report generation proc * “Generate a summary of this incident/alert and include diagrams of events.” * “Provide more details on the mitigation strategies used.” -After you review the report, click **Add to existing case** at the top of AI Assistant's response. This allows you to save a record of the report and make it available to your team. +After you review the report, click **Add to existing case** at the top of AI Assistant's response. This allows you to save a record of the report and make it available to your team. \ No newline at end of file From 3c0a3fd6c7ec0c3adf2443755cd0d83a5a9896c9 Mon Sep 17 00:00:00 2001 From: Colleen McGinnis Date: Fri, 1 Nov 2024 15:07:26 -0500 Subject: [PATCH 07/14] qa security --- .../AI-for-security/ai-assistant.asciidoc | 2 +- .../AI-for-security/attack-discovery.asciidoc | 6 +- .../AI-for-security/attack-discovery.mdx | 22 ++-- .../connect-to-azure-openai.asciidoc | 4 - .../connect-to-azure-openai.mdx | 4 +- .../connect-to-bedrock.asciidoc | 4 - .../AI-for-security/connect-to-bedrock.mdx | 4 +- .../connect-to-byo-llm.asciidoc | 2 +- .../connect-to-openai.asciidoc | 4 - .../AI-for-security/connect-to-openai.mdx | 2 - .../analyze-risk-score-data.asciidoc | 2 +- .../analyze-risk-score-data.mdx | 10 +- .../asset-criticality.asciidoc | 2 +- .../asset-criticality.mdx | 8 +- .../behavioral-detection-use-cases.asciidoc | 2 +- .../entity-risk-scoring.asciidoc | 2 +- .../entity-risk-scoring.mdx | 2 +- .../ers-req.asciidoc | 12 +- .../ml-requirements.asciidoc | 4 +- .../tuning-anomaly-results.asciidoc | 9 +- .../tuning-anomaly-results.mdx | 28 ++-- .../alerts/alerts-ui-manage.asciidoc | 4 +- docs/serverless/alerts/alerts-ui-manage.mdx | 52 ++++---- .../alerts/view-alert-details.asciidoc | 4 +- docs/serverless/billing.asciidoc | 8 +- docs/serverless/billing.mdx | 18 +-- .../cspm-get-started.asciidoc | 20 +-- .../cspm-get-started.mdx | 120 +++++++++--------- .../enable-cloudsec.asciidoc | 4 +- .../cloud-native-security/enable-cloudsec.mdx | 8 +- .../get-started-with-kspm.asciidoc | 2 +- .../get-started-with-kspm.mdx | 4 +- .../vuln-management-findings.mdx | 10 +- .../agent-tamper-protection.asciidoc | 2 +- ...igure-endpoint-integration-policy.asciidoc | 14 +- .../defend-feature-privs.asciidoc | 2 +- .../deploy-with-mdm.asciidoc | 10 +- .../edr-install-config/deploy-with-mdm.mdx | 20 +-- .../linux-file-monitoring.asciidoc | 12 +- .../linux-file-monitoring.mdx | 52 ++++---- .../self-healing-rollback.asciidoc | 2 +- .../uninstall-agent.asciidoc | 30 +++-- .../edr-install-config/uninstall-agent.mdx | 9 +- .../edr-manage/endpoint-command-ref.asciidoc | 28 ++-- .../edr-manage/endpoint-command-ref.mdx | 28 ++-- .../host-isolation-exceptions.asciidoc | 2 +- .../automated-response-actions.asciidoc | 2 +- .../host-isolation-ov.asciidoc | 16 +-- .../host-isolation-ov.mdx | 16 +-- .../response-actions-config.asciidoc | 4 +- .../response-actions.asciidoc | 4 +- .../third-party-actions.asciidoc | 2 +- docs/serverless/explore/conf-map-ui.asciidoc | 78 ++++++------ docs/serverless/explore/conf-map-ui.mdx | 76 +++++------ .../explore/data-views-in-sec.asciidoc | 2 +- docs/serverless/explore/data-views-in-sec.mdx | 4 +- .../explore/hosts-overview.asciidoc | 2 +- docs/serverless/explore/users-page.asciidoc | 2 +- docs/serverless/ingest/auto-import.asciidoc | 4 +- docs/serverless/ingest/auto-import.mdx | 36 +++--- .../investigate/case-permissions.asciidoc | 6 +- .../investigate/cases-settings.asciidoc | 3 +- .../serverless/investigate/cases-settings.mdx | 1 + .../indicators-of-compromise.asciidoc | 2 +- .../timeline-templates-ui.asciidoc | 11 +- .../investigate/timeline-templates-ui.mdx | 16 ++- .../investigate/timelines-ui.asciidoc | 24 ++-- docs/serverless/investigate/timelines-ui.mdx | 82 ++++++------ .../osquery/invest-guide-run-osquery.asciidoc | 3 +- .../osquery/osquery-response-action.asciidoc | 2 +- .../projects-create/create-project.asciidoc | 2 +- .../detections-permissions-section.asciidoc | 4 +- .../interactive-investigation-guides.asciidoc | 2 +- .../serverless/rules/rules-ui-create.asciidoc | 5 +- docs/serverless/sec-requirements.asciidoc | 2 +- docs/serverless/security-ui.asciidoc | 2 +- .../settings/advanced-settings.asciidoc | 2 +- .../troubleshoot-endpoints.asciidoc | 8 +- .../troubleshoot-endpoints.mdx | 14 +- 79 files changed, 530 insertions(+), 509 deletions(-) diff --git a/docs/serverless/AI-for-security/ai-assistant.asciidoc b/docs/serverless/AI-for-security/ai-assistant.asciidoc index db73fbebe0..a296c69bd8 100644 --- a/docs/serverless/AI-for-security/ai-assistant.asciidoc +++ b/docs/serverless/AI-for-security/ai-assistant.asciidoc @@ -19,7 +19,7 @@ Elastic AI Assistant is designed to enhance your analysis with smart dialogues. .Requirements [NOTE] ==== -* This feature requires the Security Analytics Complete https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature]. +* This feature requires the Security Analytics Complete <>. * You need an account with a third-party generative AI provider, which AI Assistant uses to generate responses. Supported providers are OpenAI, Azure OpenAI Service, and Amazon Bedrock. ==== diff --git a/docs/serverless/AI-for-security/attack-discovery.asciidoc b/docs/serverless/AI-for-security/attack-discovery.asciidoc index e07afb28a5..e20c76fde2 100644 --- a/docs/serverless/AI-for-security/attack-discovery.asciidoc +++ b/docs/serverless/AI-for-security/attack-discovery.asciidoc @@ -42,16 +42,16 @@ When you access Attack discovery for the first time, you'll need to select an LL . Click the **Attack discovery** page from {elastic-sec}'s navigation menu. . Select an existing connector from the dropdown menu, or add a new one. - ++ .Recommended models [NOTE] ==== While Attack discovery is compatible with many different models, our testing found increased performance with Claude 3.5 Sonnet. In general, models with larger context windows are more effective for Attack discovery. ==== - ++ [role="screenshot"] image::images/attack-discovery/attck-disc-select-model-empty-state.png[Attack discovery empty state] - ++ . Once you've selected a connector, click **Generate** to start the analysis. It may take from a few seconds up to several minutes to generate discoveries, depending on the number of alerts and the model you selected. diff --git a/docs/serverless/AI-for-security/attack-discovery.mdx b/docs/serverless/AI-for-security/attack-discovery.mdx index 1fda68845a..ee5fa84a10 100644 --- a/docs/serverless/AI-for-security/attack-discovery.mdx +++ b/docs/serverless/AI-for-security/attack-discovery.mdx @@ -29,19 +29,19 @@ This page describes: When you access Attack discovery for the first time, you'll need to select an LLM connector before you can analyze alerts. Attack discovery uses the same LLM connectors as Elastic AI Assistant. To get started: -1. Click the **Attack discovery** page from ((elastic-sec))'s navigation menu. +1. Click the **Attack discovery** page from ((elastic-sec))'s navigation menu. -2. Select an existing connector from the dropdown menu, or add a new one. +1. Select an existing connector from the dropdown menu, or add a new one. - -While Attack discovery is compatible with many different models, our testing found increased performance with Claude 3.5 Sonnet. In general, models with larger context windows are more effective for Attack discovery. - + + While Attack discovery is compatible with many different models, our testing found increased performance with Claude 3.5 Sonnet. In general, models with larger context windows are more effective for Attack discovery. + -![Attack discovery empty state](../images/attack-discovery/attck-disc-select-model-empty-state.png) + ![Attack discovery empty state](../images/attack-discovery/attck-disc-select-model-empty-state.png) -3. Once you've selected a connector, click **Generate** to start the analysis. +1. Once you've selected a connector, click **Generate** to start the analysis. -It may take from a few seconds up to several minutes to generate discoveries, depending on the number of alerts and the model you selected. +It may take from a few seconds up to several minutes to generate discoveries, depending on the number of alerts and the model you selected. Attack discovery is in technical preview and will only analyze opened and acknowleged alerts from the past 24 hours. By default it analyzes up to 100 alerts within this timeframe, but you can expand this up to 500 by clicking the settings icon next to the model selection menu and adjusting the **Alerts** slider. Note that sending more alerts than your chosen LLM can handle may result in an error. @@ -51,7 +51,7 @@ Attack discovery is in technical preview and will only analyze opened and acknow -Attack discovery uses the same data anonymization settings as Elastic AI Assistant. To configure which alert fields are sent to the LLM and which of those fields are obfuscated, use the Elastic AI Assistant settings. Consider the privacy policies of third-party LLMs before sending them sensitive data. +Attack discovery uses the same data anonymization settings as Elastic AI Assistant. To configure which alert fields are sent to the LLM and which of those fields are obfuscated, use the Elastic AI Assistant settings. Consider the privacy policies of third-party LLMs before sending them sensitive data. Once the analysis is complete, any threats it identifies appear as discoveries. Click each one's title to expand or collapse it. Click **Generate** at any time to start the Attack discovery process again with the most current alerts. @@ -73,9 +73,9 @@ Each discovery includes the following information describing the potential threa There are several ways you can incorporate discoveries into your ((elastic-sec)) workflows: - Click an entity's name to open the user or host details flyout and view more details that may be relevant to your investigation. -- Hover over an entity's name to either add the entity to Timeline () or copy its field name and value to the clipboard (). +- Hover over an entity's name to either add the entity to Timeline () or copy its field name and value to the clipboard (). - Click **Take action**, then select **Add to new case** or **Add to existing case** to add a discovery to a case. This makes it easy to share the information with your team and other stakeholders. - Click **Investigate in timeline** to explore the discovery in Timeline. -- Click **View in AI Assistant** to attach the discovery to a conversation with AI Assistant. You can then ask follow up questions about the discovery or associated alerts. +- Click **View in AI Assistant** to attach the discovery to a conversation with AI Assistant. You can then ask follow up questions about the discovery or associated alerts. ![Attack discovery view in AI Assistant](../images/attack-discovery/add-discovery-to-conversation.gif) diff --git a/docs/serverless/AI-for-security/connect-to-azure-openai.asciidoc b/docs/serverless/AI-for-security/connect-to-azure-openai.asciidoc index ab94776e5d..d540021d27 100644 --- a/docs/serverless/AI-for-security/connect-to-azure-openai.asciidoc +++ b/docs/serverless/AI-for-security/connect-to-azure-openai.asciidoc @@ -4,10 +4,6 @@ :description: Set up an Azure OpenAI LLM connector. :keywords: security, overview, get-started -[discrete] -[[security-connect-to-azure-openai-connect-to-azure-openai]] -= Connect to Azure OpenAI - This page provides step-by-step instructions for setting up an Azure OpenAI connector for the first time. This connector type enables you to leverage large language models (LLMs) within {kib}. You'll first need to configure Azure, then configure the connector in {kib}. [discrete] diff --git a/docs/serverless/AI-for-security/connect-to-azure-openai.mdx b/docs/serverless/AI-for-security/connect-to-azure-openai.mdx index 79f9d8630d..8f00b228a2 100644 --- a/docs/serverless/AI-for-security/connect-to-azure-openai.mdx +++ b/docs/serverless/AI-for-security/connect-to-azure-openai.mdx @@ -6,8 +6,6 @@ tags: ["security", "overview", "get-started"] status: in review --- -# Connect to Azure OpenAI - This page provides step-by-step instructions for setting up an Azure OpenAI connector for the first time. This connector type enables you to leverage large language models (LLMs) within ((kib)). You'll first need to configure Azure, then configure the connector in ((kib)). ## Configure Azure @@ -48,7 +46,7 @@ Now, set up the Azure OpenAI model: 1. From within your Azure OpenAI deployment, select **Model deployments**, then click **Manage deployments**. 2. On the **Deployments** page, select **Create new deployment**. 3. Under **Select a model**, choose `gpt-4o` or `gpt-4 turbo`. -4. Set the model version to "Auto-update to default". +4. Set the model version to "Auto-update to default". 5. Under **Deployment type**, select **Standard**. 6. Name your deployment. 7. Slide the **Tokens per Minute Rate Limit** to the maximum. The following example supports 80,000 TPM, but other regions might support higher limits. diff --git a/docs/serverless/AI-for-security/connect-to-bedrock.asciidoc b/docs/serverless/AI-for-security/connect-to-bedrock.asciidoc index 3072cbbaac..cb947fb629 100644 --- a/docs/serverless/AI-for-security/connect-to-bedrock.asciidoc +++ b/docs/serverless/AI-for-security/connect-to-bedrock.asciidoc @@ -4,10 +4,6 @@ :description: Set up an Amazon Bedrock LLM connector. :keywords: security, overview, get-started -[discrete] -[[security-connect-to-bedrock-connect-to-amazon-bedrock]] -= Connect to Amazon Bedrock - This page provides step-by-step instructions for setting up an Amazon Bedrock connector for the first time. This connector type enables you to leverage large language models (LLMs) within {kib}. You'll first need to configure AWS, then configure the connector in {kib}. [NOTE] diff --git a/docs/serverless/AI-for-security/connect-to-bedrock.mdx b/docs/serverless/AI-for-security/connect-to-bedrock.mdx index 7c8609b043..d60e2fca9a 100644 --- a/docs/serverless/AI-for-security/connect-to-bedrock.mdx +++ b/docs/serverless/AI-for-security/connect-to-bedrock.mdx @@ -6,8 +6,6 @@ tags: ["security","overview","get-started"] status: in review --- -# Connect to Amazon Bedrock - This page provides step-by-step instructions for setting up an Amazon Bedrock connector for the first time. This connector type enables you to leverage large language models (LLMs) within ((kib)). You'll first need to configure AWS, then configure the connector in ((kib)). @@ -16,7 +14,7 @@ Only Amazon Bedrock's `Anthropic` models are supported: `Claude` and `Claude ins ## Configure AWS -### Configure an IAM policy +### Configure an IAM policy First, configure an IAM policy with the necessary permissions: diff --git a/docs/serverless/AI-for-security/connect-to-byo-llm.asciidoc b/docs/serverless/AI-for-security/connect-to-byo-llm.asciidoc index ca31fee9bf..9f30562c45 100644 --- a/docs/serverless/AI-for-security/connect-to-byo-llm.asciidoc +++ b/docs/serverless/AI-for-security/connect-to-byo-llm.asciidoc @@ -32,7 +32,7 @@ You need to set up a reverse proxy to enable communication between LM Studio and The following is an example Nginx configuration file: -[source] +[source,txt] ---- server { listen 80; diff --git a/docs/serverless/AI-for-security/connect-to-openai.asciidoc b/docs/serverless/AI-for-security/connect-to-openai.asciidoc index 83559b3944..21c0134009 100644 --- a/docs/serverless/AI-for-security/connect-to-openai.asciidoc +++ b/docs/serverless/AI-for-security/connect-to-openai.asciidoc @@ -4,10 +4,6 @@ :description: Set up an OpenAI LLM connector. :keywords: security, overview, get-started -[discrete] -[[security-connect-to-openai-connect-to-openai]] -= Connect to OpenAI - This page provides step-by-step instructions for setting up an OpenAI connector for the first time. This connector type enables you to leverage OpenAI's large language models (LLMs) within {kib}. You'll first need to create an OpenAI API key, then configure the connector in {kib}. [discrete] diff --git a/docs/serverless/AI-for-security/connect-to-openai.mdx b/docs/serverless/AI-for-security/connect-to-openai.mdx index 57a24d97b1..ea05df5579 100644 --- a/docs/serverless/AI-for-security/connect-to-openai.mdx +++ b/docs/serverless/AI-for-security/connect-to-openai.mdx @@ -6,8 +6,6 @@ tags: ["security", "overview", "get-started"] status: in review --- -# Connect to OpenAI - This page provides step-by-step instructions for setting up an OpenAI connector for the first time. This connector type enables you to leverage OpenAI's large language models (LLMs) within ((kib)). You'll first need to create an OpenAI API key, then configure the connector in ((kib)). ## Configure OpenAI diff --git a/docs/serverless/advanced-entity-analytics/analyze-risk-score-data.asciidoc b/docs/serverless/advanced-entity-analytics/analyze-risk-score-data.asciidoc index cbb69fd414..39093e8f50 100644 --- a/docs/serverless/advanced-entity-analytics/analyze-risk-score-data.asciidoc +++ b/docs/serverless/advanced-entity-analytics/analyze-risk-score-data.asciidoc @@ -97,7 +97,7 @@ image::images/analyze-risk-score-data/group-by-asset-criticality.png[Alerts grou ... Select **Sort fields** → **Pick fields to sort by**. ... Select fields in the following order: + -.... `host.risk.calculated_score_norm`or `user.risk.calculated_score_norm`: **High-Low** +.... `host.risk.calculated_score_norm` or `user.risk.calculated_score_norm`: **High-Low** .... `Risk score`: **High-Low** .... `@timestamp`: **New-Old** + diff --git a/docs/serverless/advanced-entity-analytics/analyze-risk-score-data.mdx b/docs/serverless/advanced-entity-analytics/analyze-risk-score-data.mdx index 30a28bfdd6..056525881c 100644 --- a/docs/serverless/advanced-entity-analytics/analyze-risk-score-data.mdx +++ b/docs/serverless/advanced-entity-analytics/analyze-risk-score-data.mdx @@ -26,10 +26,10 @@ We recommend that you prioritize host details page and user details page: - ![Assign asset criticality from the host details page](../images/asset-criticality/-assign-asset-criticality-host-details.png) + ![Assign asset criticality from the host details page](../images/asset-criticality/-assign-asset-criticality-host-details.png) * The host details flyout and user details flyout: @@ -69,7 +69,7 @@ The maximum file size is 1 MB. File structure example: -``` +```txt user,user-001,low_impact user,user-002,medium_impact host,host-001,extreme_impact @@ -83,7 +83,7 @@ To import a file: The file validation step highlights any lines that don't follow the required file structure. The asset criticality levels for those entities won't be assigned. We recommend that you fix any invalid lines and re-upload the file. -1. Click **Assign**. +1. Click **Assign**. This process overwrites any previously assigned asset criticality levels for the entities included in the imported file. The newly assigned or updated asset criticality levels are immediately visible within all asset criticality workflows. @@ -104,7 +104,7 @@ Once you assign a criticality level to an entity, all subsequent alerts related ### Monitor an entity's risk -The risk scoring engine dynamically factors in an entity's asset criticality, along with `Open` and `Acknowledged` detection alerts to calculate the entity's overall risk score. This dynamic risk scoring allows you to monitor changes in the risk profiles of your most sensitive entities, and quickly escalate high-risk threats. +The risk scoring engine dynamically factors in an entity's asset criticality, along with `Open` and `Acknowledged` detection alerts to calculate the entity's overall risk score. This dynamic risk scoring allows you to monitor changes in the risk profiles of your most sensitive entities, and quickly escalate high-risk threats. To view the impact of asset criticality on an entity's risk score, follow these steps: diff --git a/docs/serverless/advanced-entity-analytics/behavioral-detection-use-cases.asciidoc b/docs/serverless/advanced-entity-analytics/behavioral-detection-use-cases.asciidoc index 83ee759958..44c5bf5da2 100644 --- a/docs/serverless/advanced-entity-analytics/behavioral-detection-use-cases.asciidoc +++ b/docs/serverless/advanced-entity-analytics/behavioral-detection-use-cases.asciidoc @@ -19,7 +19,7 @@ Behavioral detection integrations provide a convenient way to enable behavioral .Requirements [NOTE] ==== -* Behavioral detection integrations require the Security Analytics Complete https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature]. +* Behavioral detection integrations require the Security Analytics Complete <>. * To learn more about the requirements for using {ml} jobs, refer to <>. ==== diff --git a/docs/serverless/advanced-entity-analytics/entity-risk-scoring.asciidoc b/docs/serverless/advanced-entity-analytics/entity-risk-scoring.asciidoc index 38b2a2fa29..fc778fc9a5 100644 --- a/docs/serverless/advanced-entity-analytics/entity-risk-scoring.asciidoc +++ b/docs/serverless/advanced-entity-analytics/entity-risk-scoring.asciidoc @@ -98,7 +98,7 @@ There are 5 open alerts associated with `User_A`: * Alert 4 with alert risk score 70 * Alert 5 with alert risk score 21 -*** +''' To calculate the user risk score, the risk scoring engine: diff --git a/docs/serverless/advanced-entity-analytics/entity-risk-scoring.mdx b/docs/serverless/advanced-entity-analytics/entity-risk-scoring.mdx index afac426c31..2294b2fbef 100644 --- a/docs/serverless/advanced-entity-analytics/entity-risk-scoring.mdx +++ b/docs/serverless/advanced-entity-analytics/entity-risk-scoring.mdx @@ -111,5 +111,5 @@ To calculate the user risk score, the risk scoring engine: If `User_A` had no asset criticality level assigned, the user risk score would remain unchanged at 36.16. - + Learn how to turn on the risk scoring engine. diff --git a/docs/serverless/advanced-entity-analytics/ers-req.asciidoc b/docs/serverless/advanced-entity-analytics/ers-req.asciidoc index 9bab34151c..6e05b6801c 100644 --- a/docs/serverless/advanced-entity-analytics/ers-req.asciidoc +++ b/docs/serverless/advanced-entity-analytics/ers-req.asciidoc @@ -4,7 +4,7 @@ :description: Requirements for using entity risk scoring and asset criticality. :keywords: serverless, security, reference, manage -To use entity risk scoring and asset criticality, you need the appropriate user roles. These features require the Security Analytics Complete https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature]. +To use entity risk scoring and asset criticality, you need the appropriate user roles. These features require the Security Analytics Complete <>. This page covers the requirements for using the entity risk scoring and asset criticality features, as well as their known limitations. @@ -16,7 +16,7 @@ This page covers the requirements for using the entity risk scoring and asset cr [[security-ers-requirements-user-roles]] === User roles -To turn on the risk scoring engine, you need either the appropriate https://www.elastic.co/docs/current/serverless/general/assign-user-roles[predefined Security user role] or a https://www.elastic.co/docs/current/serverless/custom-roles[custom role] with the right privileges: +To turn on the risk scoring engine, you need either the appropriate <> or a <> with the right privileges: **Predefined roles** @@ -29,7 +29,7 @@ To turn on the risk scoring engine, you need either the appropriate https://www. |=== | Cluster | Index | {kib} -| * `manage_index_templates` +a| * `manage_index_templates` * `manage_transform` | `all` privilege for `risk-score.risk-score-*` | **Read** for the **Security** feature @@ -52,7 +52,7 @@ To use the asset criticality feature, turn on the `securitySolution:enableAssetC [[security-ers-requirements-user-roles-1]] === User roles -To use asset criticality, you need either the appropriate https://www.elastic.co/docs/current/serverless/general/assign-user-roles[predefined Security user role] or a https://www.elastic.co/docs/current/serverless/custom-roles[custom role] with the right privileges: +To use asset criticality, you need either the appropriate <> or a <> with the right privileges: **Predefined roles** @@ -60,11 +60,11 @@ To use asset criticality, you need either the appropriate https://www.elastic.co | Action | Predefined role | View asset criticality -| * Viewer +a| * Viewer * Tier 1 analyst | View, assign, change, or unassign asset criticality -| * Editor +a| * Editor * Tier 2 analyst * Tier 3 analyst * Threat intelligence analyst diff --git a/docs/serverless/advanced-entity-analytics/ml-requirements.asciidoc b/docs/serverless/advanced-entity-analytics/ml-requirements.asciidoc index 0a672625c4..656e38d25f 100644 --- a/docs/serverless/advanced-entity-analytics/ml-requirements.asciidoc +++ b/docs/serverless/advanced-entity-analytics/ml-requirements.asciidoc @@ -6,9 +6,9 @@ preview:[] -To run and create {ml} jobs and rules, you need the appropriate https://www.elastic.co/docs/current/serverless/general/assign-user-roles[user role]. +To run and create {ml} jobs and rules, you need the appropriate <>. -Additionally, for https://www.elastic.co/docs/current/serverless/custom-roles[custom roles], to configure <> for {ml} rules, your role needs the following index privilege: +Additionally, for <>, to configure <> for {ml} rules, your role needs the following index privilege: * `read` permission for the `.ml-anomalies-*` index diff --git a/docs/serverless/advanced-entity-analytics/tuning-anomaly-results.asciidoc b/docs/serverless/advanced-entity-analytics/tuning-anomaly-results.asciidoc index 0ad10c8f5b..10dd07b150 100644 --- a/docs/serverless/advanced-entity-analytics/tuning-anomaly-results.asciidoc +++ b/docs/serverless/advanced-entity-analytics/tuning-anomaly-results.asciidoc @@ -94,18 +94,16 @@ have completed all job rule changes. . Go to **Machine learning** → **Anomaly Detection** → **Jobs**. . Navigate to the job for which you configured the rule. - ++ // Should this be "Navigate to the job that you want to clone"? - . Optionally, expand the job row and click **JSON** to verify the configured filter appears under `custom rules` in the JSON code. . In the **actions** column, click the options menu (image:images/icons/boxesHorizontal.svg[Options menu]) and select **Clone job**. + The **Configure datafeed** page is displayed. . Click **Data Preview** and check the data is displayed without errors. - ++ // Unable to verify this step - don't think it exists anymore. - . Click **Next** until the **Job details** page is displayed. . Enter a Job ID for the cloned job that indicates it is an iteration of the original one. For example, append a number or a username to the original job @@ -124,9 +122,8 @@ The **Start ** window is displayed. [role="screenshot"] image::images/tuning-anomaly-results/-detections-machine-learning-start-job-window.png[] . Select the point of time from which the job will analyze anomalies. - ++ // Users can't do this. I think their only option is to start the job in real time. - . Click **Start**. + After a while, results will start to appear on the **Anomaly Explorer** page. diff --git a/docs/serverless/advanced-entity-analytics/tuning-anomaly-results.mdx b/docs/serverless/advanced-entity-analytics/tuning-anomaly-results.mdx index 511876c4f8..bcb42fe0d6 100644 --- a/docs/serverless/advanced-entity-analytics/tuning-anomaly-results.mdx +++ b/docs/serverless/advanced-entity-analytics/tuning-anomaly-results.mdx @@ -1,7 +1,7 @@ --- slug: /serverless/security/tuning-anomaly-results title: Optimizing anomaly results -description: Learn how to fine-tune and filter anomaly results. +description: Learn how to fine-tune and filter anomaly results. tags: [ 'serverless', 'security', 'how-to' ] status: in review --- @@ -9,7 +9,7 @@ status: in review
-To gain clearer insights into real threats, you can tune the anomaly results. The following procedures help to reduce the number of false positives: +To gain clearer insights into real threats, you can tune the anomaly results. The following procedures help to reduce the number of false positives: * Tune results for rare applications and processes * Define an anomaly threshold for a job @@ -97,7 +97,7 @@ have completed all job rule changes. 1. Go to **Machine learning** → **Anomaly Detection** → **Jobs**. 1. Navigate to the job for which you configured the rule. -{/* Should this be "Navigate to the job that you want to clone"? */} + {/* Should this be "Navigate to the job that you want to clone"? */} 1. Optionally, expand the job row and click **JSON** to verify the configured filter appears under `custom rules` in the JSON code. @@ -106,7 +106,7 @@ have completed all job rule changes. The **Configure datafeed** page is displayed. 1. Click **Data Preview** and check the data is displayed without errors. -{/* Unable to verify this step - don't think it exists anymore. */} + {/* Unable to verify this step - don't think it exists anymore. */} 1. Click **Next** until the **Job details** page is displayed. 1. Enter a Job ID for the cloned job that indicates it is an iteration of the original one. For example, append a number or a username to the original job @@ -119,13 +119,13 @@ have completed all job rule changes. 1. Click **Next** and then **Create job**. - The **Start \** window is displayed. - {/* This page doesn't display. */} + The **Start \** window is displayed. + {/* This page doesn't display. */} ![](../images/tuning-anomaly-results/-detections-machine-learning-start-job-window.png) 1. Select the point of time from which the job will analyze anomalies. -{/* Users can't do this. I think their only option is to start the job in real time. */} + {/* Users can't do this. I think their only option is to start the job in real time. */} 1. Click **Start**. After a while, results will start to appear on the **Anomaly Explorer** page. @@ -134,21 +134,21 @@ have completed all job rule changes. ## Define an anomaly threshold for a job -{/* Unable to test these steps because I don't have the privs needed to enable/run ML jobs */} +{/* Unable to test these steps because I don't have the privs needed to enable/run ML jobs */} -Certain jobs use a high-count function to look for unusual spikes in +Certain jobs use a high-count function to look for unusual spikes in process events. For some processes, a burst of activity is a normal, such as automation and housekeeping jobs running on server fleets. However, sometimes a high-delta event count is unlikely to be the result of routine behavior. In these cases, you can define a minimum threshold for when a high-event count is considered an anomaly. -Depending on your anomaly detection results, you may want to set a +Depending on your anomaly detection results, you may want to set a minimum event count threshold for the `packetbeat_dns_tunneling` job: 1. Go to **Machine learning** → **Anomaly Detection** → **Anomaly Explorer**. -1. Navigate to the job results for the `packetbeat_dns_tunneling` job. If the - job results are not listed, click **Edit job selection** and select +1. Navigate to the job results for the `packetbeat_dns_tunneling` job. If the + job results are not listed, click **Edit job selection** and select `packetbeat_dns_tunneling`. 1. In the **actions** column, click the gear icon and then select @@ -158,7 +158,7 @@ minimum event count threshold for the `packetbeat_dns_tunneling` job: ![](../images/tuning-anomaly-results/-detections-machine-learning-ml-rule-threshold.png) -1. Select **Add numeric conditions for when the rule applies** and the following +1. Select **Add numeric conditions for when the rule applies** and the following `when` statement: _WHEN actual IS GREATER THAN \_ @@ -167,5 +167,5 @@ minimum event count threshold for the `packetbeat_dns_tunneling` job: 1. Click **Save**. 1. To apply the new threshold, rerun the job (**Job Management** → **Actions** → **Start datafeed**). -{/* Re-added the part that was missing from this step (might've not been migrated over), but am unable to verify this step because idk where the Job Management page is. */} +{/* Re-added the part that was missing from this step (might've not been migrated over), but am unable to verify this step because idk where the Job Management page is. */} diff --git a/docs/serverless/alerts/alerts-ui-manage.asciidoc b/docs/serverless/alerts/alerts-ui-manage.asciidoc index 8f91765f77..799f9a8d23 100644 --- a/docs/serverless/alerts/alerts-ui-manage.asciidoc +++ b/docs/serverless/alerts/alerts-ui-manage.asciidoc @@ -187,7 +187,7 @@ To apply or remove alert tags on individual alerts, do one of the following: To apply or remove alert tags on multiple alerts, select the alerts you want to change, then click **Selected _x_ alerts** at the upper-left above the table. Click **Apply alert tags**, select or unselect tags, then click **Apply tags**. [role="screenshot"] -image::images/alerts-ui-manage/-detections-bulk-apply-alert-tag.png[Bulk action menu with multiple alerts selected, 450] +image::images/alerts-ui-manage/-detections-bulk-apply-alert-tag.png[Bulk action menu with multiple alerts selected] [discrete] [[assign-users-to-alerts]] @@ -198,7 +198,7 @@ Assign users to alerts that you want them to investigate, and manage alert assig .Requirements [NOTE] ==== -All https://www.elastic.co/docs/current/serverless/general/assign-user-roles[Security roles], except for the Viewer role, can assign and unassign users to alerts. +All <>, except for the Viewer role, can assign and unassign users to alerts. ==== [IMPORTANT] diff --git a/docs/serverless/alerts/alerts-ui-manage.mdx b/docs/serverless/alerts/alerts-ui-manage.mdx index f398a48750..11dce01ae6 100644 --- a/docs/serverless/alerts/alerts-ui-manage.mdx +++ b/docs/serverless/alerts/alerts-ui-manage.mdx @@ -9,7 +9,7 @@ status: in review
-The Alerts page displays all detection alerts. +The Alerts page displays all detection alerts. ![Alerts page overview](../images/alerts-ui-manage/-detections-alert-page.png) @@ -155,7 +155,7 @@ From the Alerts table or the alert details flyout, you can: You can set an alert's status to indicate whether it needs to be investigated (**Open**), is under active investigation (**Acknowledged**), or has been resolved -(**Closed**). By default, the Alerts page displays open alerts. To filter alerts that are **Acknowledged** or **Closed**, use the **Status** drop-down filter at the top of the Alerts page. +(**Closed**). By default, the Alerts page displays open alerts. To filter alerts that are **Acknowledged** or **Closed**, use the **Status** drop-down filter at the top of the Alerts page. To change an alert's status, do one of the following: @@ -164,7 +164,7 @@ To change an alert's status, do one of the following: * In the Alerts table, select the alerts you want to change, click **Selected _x_ alerts** at the upper-left above the table, and then select a status. - + * To bulk-change the status of grouped alerts, select the **Take actions** menu for the group, then select a status. * In an alert's details flyout, click **Take action** and select a status. @@ -173,37 +173,37 @@ To change an alert's status, do one of the following: ### Apply and filter alert tags -Use alert tags to organize related alerts into categories that you can filter and group. For example, use the `False Positive` alert tag to label a group of alerts as false positives. Then, search for them by entering the `kibana.alert.workflow_tags : "False Positive"` query into the KQL bar. Alternatively, use the Alert table's drop-down filters to filter for tagged alerts. +Use alert tags to organize related alerts into categories that you can filter and group. For example, use the `False Positive` alert tag to label a group of alerts as false positives. Then, search for them by entering the `kibana.alert.workflow_tags : "False Positive"` query into the KQL bar. Alternatively, use the Alert table's drop-down filters to filter for tagged alerts. -You can manage alert tag options by updating the `securitySolution:alertTags` advanced setting. Refer to Manage alert tag options for more information. +You can manage alert tag options by updating the `securitySolution:alertTags` advanced setting. Refer to Manage alert tag options for more information. -To display alert tags in the Alerts table, click **Fields** and add the `kibana.alert.workflow_tags` field. +To display alert tags in the Alerts table, click **Fields** and add the `kibana.alert.workflow_tags` field. To apply or remove alert tags on individual alerts, do one of the following: - * In the Alerts table, click **More actions** (**...**) in an alert's row, then click **Apply alert tags**. Select or unselect tags, then click **Apply tags**. - * In an alert’s details flyout, click **Take action → Apply alert tags**. Select or unselect tags, then click **Apply tags**. + * In the Alerts table, click **More actions** (**...**) in an alert's row, then click **Apply alert tags**. Select or unselect tags, then click **Apply tags**. + * In an alert’s details flyout, click **Take action → Apply alert tags**. Select or unselect tags, then click **Apply tags**. -To apply or remove alert tags on multiple alerts, select the alerts you want to change, then click **Selected _x_ alerts** at the upper-left above the table. Click **Apply alert tags**, select or unselect tags, then click **Apply tags**. +To apply or remove alert tags on multiple alerts, select the alerts you want to change, then click **Selected _x_ alerts** at the upper-left above the table. Click **Apply alert tags**, select or unselect tags, then click **Apply tags**. -![Bulk action menu with multiple alerts selected, 450](../images/alerts-ui-manage/-detections-bulk-apply-alert-tag.png) +![Bulk action menu with multiple alerts selected](../images/alerts-ui-manage/-detections-bulk-apply-alert-tag.png)
-### Assign users to alerts +### Assign users to alerts -Assign users to alerts that you want them to investigate, and manage alert assignees throughout an alert's lifecycle. +Assign users to alerts that you want them to investigate, and manage alert assignees throughout an alert's lifecycle. All Security roles, except for the Viewer role, can assign and unassign users to alerts. -Users are not notified when they've been assigned to, or unassigned from, alerts. +Users are not notified when they've been assigned to, or unassigned from, alerts. Assign users to an alert - + Choose one of the following: - * **Alerts table** - Click **More actions** (**...**) in an alert's row, then click **Assign alert**. Select users, then click **Apply**. + * **Alerts table** - Click **More actions** (**...**) in an alert's row, then click **Assign alert**. Select users, then click **Apply**. + + * **Alert details flyout** - Click **Take action → Assign alert**. Alternatively, click the **Assign alert** icon () at the top of the alert details flyout, select users, then click **Apply**. - * **Alert details flyout** - Click **Take action → Assign alert**. Alternatively, click the **Assign alert** icon () at the top of the alert details flyout, select users, then click **Apply**. - @@ -231,16 +231,16 @@ Users are not notified when they've been assigned to, or unassigned from, alerts Unassign all users from an alert Choose one of the following: - * **Alerts table** - Click **More actions** (**...**) in an alert's row, then click **Unassign alert**. - * **Alert details flyout** - Click **Take action → Unassign alert**. - + * **Alerts table** - Click **More actions** (**...**) in an alert's row, then click **Unassign alert**. + * **Alert details flyout** - Click **Take action → Unassign alert**. + Assign users to multiple alerts - From the Alerts table, select the alerts you want to change. Click **Selected _x_ alerts** at the upper-left above the table, then click **Assign alert**. Select users, then click **Apply**. + From the Alerts table, select the alerts you want to change. Click **Selected _x_ alerts** at the upper-left above the table, then click **Assign alert**. Select users, then click **Apply**. Users assigned to some of the selected alerts will be displayed as unassigned in the selection list. Selecting said users will assign them to all alerts they haven't been assigned to yet. @@ -252,13 +252,13 @@ Users are not notified when they've been assigned to, or unassigned from, alerts Unassign users from multiple alerts - From the Alerts table, select the alerts you want to change and click **Selected _x_ alerts** at the upper-left above the table. Click **Unassign alert** to remove users from the alert. + From the Alerts table, select the alerts you want to change and click **Selected _x_ alerts** at the upper-left above the table. Click **Unassign alert** to remove users from the alert. -Show users that have been assigned to alerts by adding the **Assignees** column to the Alerts table (**Fields** → `kibana.alert.workflow_assignee_ids`). Up to four assigned users can appear in the **Assignees** column. If an alert is assigned to five or more users, a number appears instead. +Show users that have been assigned to alerts by adding the **Assignees** column to the Alerts table (**Fields** → `kibana.alert.workflow_assignee_ids`). Up to four assigned users can appear in the **Assignees** column. If an alert is assigned to five or more users, a number appears instead. @@ -268,9 +268,9 @@ Assigned users are automatically displayed in the alert details flyout. Up to tw
-### Filter assigned alerts +### Filter assigned alerts -Click the **Assignees** filter above the Alerts table, then select the users you want to filter by. +Click the **Assignees** filter above the Alerts table, then select the users you want to filter by. @@ -295,7 +295,7 @@ For information about exceptions and how to use them, refer to * To view a single alert in Timeline, click the **Investigate in timeline** button in the Alerts table. Alternatively, select **Take action** → **Investigate in timeline** in the alert details flyout. - + * To view multiple alerts in Timeline (up to 2,000), select the checkboxes next to the alerts, then click **Selected _x_ alerts** → **Investigate in timeline**. diff --git a/docs/serverless/alerts/view-alert-details.asciidoc b/docs/serverless/alerts/view-alert-details.asciidoc index c8365cd7d6..84f078f254 100644 --- a/docs/serverless/alerts/view-alert-details.asciidoc +++ b/docs/serverless/alerts/view-alert-details.asciidoc @@ -147,7 +147,7 @@ image::images/view-alert-details/-detections-insights-section-rp.png[Insights se [[entities-overview]] === Entities -The Entities overview provides high-level details about the user and host that are related to the alert. Host and user risk classifications are also available if you have the Security Analytics Complete https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature]. +The Entities overview provides high-level details about the user and host that are related to the alert. Host and user risk classifications are also available if you have the Security Analytics Complete <>. [role="screenshot"] image::images/view-alert-details/-detections-entities-overview.png[Overview of the entity details section in the right panel] @@ -156,7 +156,7 @@ image::images/view-alert-details/-detections-entities-overview.png[Overview of t [[expanded-entities-view]] ==== Expanded entities view -From the right panel, click **Entities** to open a detailed view of the host and user associated with the alert. The expanded view also includes risk scores and classifications (if you have the Security Analytics Complete https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature]) and activity on related hosts and users. +From the right panel, click **Entities** to open a detailed view of the host and user associated with the alert. The expanded view also includes risk scores and classifications (if you have the Security Analytics Complete <>) and activity on related hosts and users. [role="screenshot"] image::images/view-alert-details/-detections-expanded-entities-view.png[Expanded view of entity details] diff --git a/docs/serverless/billing.asciidoc b/docs/serverless/billing.asciidoc index 9dcbb13318..2244efd77c 100644 --- a/docs/serverless/billing.asciidoc +++ b/docs/serverless/billing.asciidoc @@ -40,7 +40,7 @@ Cloud Protection is an _optional_ add-on to Security Analytics that provides val Your total cost depends on the number of protected cloud workloads and other billable cloud assets you configure for use with Elastic Cloud Security. -For <>, billing is based on how many billable resources (`resource.id`s) you monitor. The following types of assets are considered billable: +For <>, billing is based on how many billable resources (`resource.id` s) you monitor. The following types of assets are considered billable: * VMs: + @@ -58,11 +58,11 @@ For <>, billing is based on how many billable resources (`re ** **Azure:** SQL database, Cosmos DB, Synapse Analytics ** **GCP:** Cloud SQL, Firestore, BigQuery -For <>, billing is based on how many Kubernetes nodes (`agent.id`s) you monitor. +For <>, billing is based on how many Kubernetes nodes (`agent.id` s) you monitor. -For <>, billing is based on how many cloud assets (`cloud.instance.id`s) you monitor. +For <>, billing is based on how many cloud assets (`cloud.instance.id` s) you monitor. -For <>, billing is based on how many agents (`agent.id`s) you use. +For <>, billing is based on how many agents (`agent.id` s) you use. Logs, events, alerts, and configuration data ingested into your security project are billed using the **Ingest** and **Retention** pricing described above. diff --git a/docs/serverless/billing.mdx b/docs/serverless/billing.mdx index 613b14db70..9358064d6a 100644 --- a/docs/serverless/billing.mdx +++ b/docs/serverless/billing.mdx @@ -25,7 +25,7 @@ Endpoint Protection is an _optional_ add-on to Security Analytics that provides * **Endpoint Protection Essentials** — Includes robust protection against malware, ransomware, and other malicious behaviors. * **Endpoint Protection Complete** — Adds endpoint response actions and advanced policy management. -You pay based on the number of protected endpoints you configure with the ((elastic-defend)) integration. Note that logs, events, and alerts ingested into your Security project from endpoints running ((elastic-defend)) are billed using the **Ingest** and **Retention** pricing described above. +You pay based on the number of protected endpoints you configure with the ((elastic-defend)) integration. Note that logs, events, and alerts ingested into your Security project from endpoints running ((elastic-defend)) are billed using the **Ingest** and **Retention** pricing described above. ## Cloud Protection @@ -33,28 +33,28 @@ Cloud Protection is an _optional_ add-on to Security Analytics that provides val * **Cloud Protection Essentials** — Protects your cloud workloads, continuously tracks posture of your cloud assets, and helps you manage risks by detecting configuration issues per CIS benchmarks. * **Cloud Protection Complete** — Adds response capabilities and configuration drift prevention for Cloud Workloads. -Your total cost depends on the number of protected cloud workloads and other billable cloud assets you configure for use with Elastic Cloud Security. +Your total cost depends on the number of protected cloud workloads and other billable cloud assets you configure for use with Elastic Cloud Security. -For , billing is based on how many billable resources (`resource.id`s) you monitor. The following types of assets are considered billable: +For , billing is based on how many billable resources (`resource.id` s) you monitor. The following types of assets are considered billable: - VMs: - **AWS:** EC2 instances - **Azure:** Virtual machines - **GCP:** Compute engine instances - Storage resources: - - **AWS:** S3, S3 Glacier, EBS + - **AWS:** S3, S3 Glacier, EBS - **Azure:** Archive, Blob, Managed disk - - **GCP:** Cloud storage, Persistent disk, Coldline storage -- SQL databases and servers: + - **GCP:** Cloud storage, Persistent disk, Coldline storage +- SQL databases and servers: - **AWS:** RDS, DynamoDB, Redshift - **Azure:** SQL database, Cosmos DB, Synapse Analytics - **GCP:** Cloud SQL, Firestore, BigQuery -For , billing is based on how many Kubernetes nodes (`agent.id`s) you monitor. +For , billing is based on how many Kubernetes nodes (`agent.id` s) you monitor. -For , billing is based on how many cloud assets (`cloud.instance.id`s) you monitor. +For , billing is based on how many cloud assets (`cloud.instance.id` s) you monitor. -For , billing is based on how many agents (`agent.id`s) you use. +For , billing is based on how many agents (`agent.id` s) you use. Logs, events, alerts, and configuration data ingested into your security project are billed using the **Ingest** and **Retention** pricing described above. diff --git a/docs/serverless/cloud-native-security/cspm-get-started.asciidoc b/docs/serverless/cloud-native-security/cspm-get-started.asciidoc index df3b2b27c2..11ab7e8a64 100644 --- a/docs/serverless/cloud-native-security/cspm-get-started.asciidoc +++ b/docs/serverless/cloud-native-security/cspm-get-started.asciidoc @@ -82,11 +82,11 @@ When using manual authentication to onboard at the organization level, you need * In the organization's management account (root account), create an IAM role called `cloudbeat-root` (the name is important). The role needs several policies: + ** The following inline policy: - ++ .Click to expand policy [%collapsible] ===== -[source] +[source,json] ---- { "Version": "2012-10-17", @@ -110,13 +110,13 @@ When using manual authentication to onboard at the organization level, you need } ---- ===== - -* The following trust policy: - ++ +** The following trust policy: ++ .Click to expand policy [%collapsible] ===== -[source] +[source,json] ---- { "Version": "2012-10-17", @@ -139,8 +139,8 @@ When using manual authentication to onboard at the organization level, you need } ---- ===== - -* The AWS-managed `SecurityAudit` policy. ++ +** The AWS-managed `SecurityAudit` policy. [IMPORTANT] ==== @@ -151,11 +151,11 @@ You must replace `` in the trust policy with your AWS acc + ** The AWS-managed `SecurityAudit` policy. ** The following trust policy: - ++ .Click to expand policy [%collapsible] ===== -[source] +[source,json] ---- { "Version": "2012-10-17", diff --git a/docs/serverless/cloud-native-security/cspm-get-started.mdx b/docs/serverless/cloud-native-security/cspm-get-started.mdx index 0bfd0242cf..6ac973a038 100644 --- a/docs/serverless/cloud-native-security/cspm-get-started.mdx +++ b/docs/serverless/cloud-native-security/cspm-get-started.mdx @@ -17,7 +17,7 @@ This page explains how to get started monitoring the security posture of your cl -* CSPM only works in the `Default` ((kib)) space. Installing the CSPM integration on a different ((kib)) space will not work. +* CSPM only works in the `Default` ((kib)) space. Installing the CSPM integration on a different ((kib)) space will not work. * CSPM is supported only on AWS, GCP, and Azure commercial cloud platforms, and AWS GovCloud. Other government cloud platforms are not supported ([request support](https://github.com/elastic/kibana/issues/new/choose)). * To view posture data, you need the appropriate user role to read the following ((es)) indices: * `logs-cloud_security_posture.findings_latest-*` @@ -81,60 +81,60 @@ When using manual authentication to onboard at the organization level, you need * The following inline policy: - + -``` -{ - "Version": "2012-10-17", - "Statement": [ - { - "Action": [ - "organizations:List*", - "organizations:Describe*" - ], - "Resource": "*", - "Effect": "Allow" - }, + ```json { - "Action": [ - "sts:AssumeRole" - ], - "Resource": "*", - "Effect": "Allow" + "Version": "2012-10-17", + "Statement": [ + { + "Action": [ + "organizations:List*", + "organizations:Describe*" + ], + "Resource": "*", + "Effect": "Allow" + }, + { + "Action": [ + "sts:AssumeRole" + ], + "Resource": "*", + "Effect": "Allow" + } + ] } - ] -} -``` + ``` - + * The following trust policy: - + -``` -{ - "Version": "2012-10-17", - "Statement": [ + ```json { - "Effect": "Allow", - "Principal": { - "AWS": "arn:aws:iam:::root" - }, - "Action": "sts:AssumeRole" - }, - { - "Effect": "Allow", - "Principal": { - "Service": "ec2.amazonaws.com" - }, - "Action": "sts:AssumeRole" + "Version": "2012-10-17", + "Statement": [ + { + "Effect": "Allow", + "Principal": { + "AWS": "arn:aws:iam:::root" + }, + "Action": "sts:AssumeRole" + }, + { + "Effect": "Allow", + "Principal": { + "Service": "ec2.amazonaws.com" + }, + "Action": "sts:AssumeRole" + } + ] } - ] -} -``` + ``` - + * The AWS-managed `SecurityAudit` policy. @@ -146,33 +146,33 @@ You must replace `` in the trust policy with your AWS acc * The AWS-managed `SecurityAudit` policy. * The following trust policy: - + -``` -{ - "Version": "2012-10-17", - "Statement": [ + ```json { - "Effect": "Allow", - "Principal": { - "AWS": "arn:aws:iam:::role/cloudbeat-root" - }, - "Action": "sts:AssumeRole" + "Version": "2012-10-17", + "Statement": [ + { + "Effect": "Allow", + "Principal": { + "AWS": "arn:aws:iam:::role/cloudbeat-root" + }, + "Action": "sts:AssumeRole" + } + ] } - ] -} -``` + ``` - + You must replace `` in the trust policy with your AWS account ID. -After creating the necessary roles, authenticate using one of the manual authentication methods. +After creating the necessary roles, authenticate using one of the manual authentication methods. -When deploying to an organization using any of the authentication methods below, you need to make sure that the credentials you provide grant permission to assume `cloudbeat-root` privileges. +When deploying to an organization using any of the authentication methods below, you need to make sure that the credentials you provide grant permission to assume `cloudbeat-root` privileges.
diff --git a/docs/serverless/cloud-native-security/enable-cloudsec.asciidoc b/docs/serverless/cloud-native-security/enable-cloudsec.asciidoc index 0936736e9b..bcef77a392 100644 --- a/docs/serverless/cloud-native-security/enable-cloudsec.asciidoc +++ b/docs/serverless/cloud-native-security/enable-cloudsec.asciidoc @@ -9,12 +9,12 @@ To use cloud security features in your {elastic-sec} project, you must have the To enable these options or check their current status: . Click your project name in the upper-left corner of {kib}. Select **Manage project**. - ++ [role="screenshot"] image::images/cloud-security-enable/manage-project.png[The project menu with the manage project button highlighted] . To the right of **Project features**, select **Edit**. - ++ [role="screenshot"] image::images/cloud-security-enable/project-features-edit.png[The project menu with the manage project button highlighted] diff --git a/docs/serverless/cloud-native-security/enable-cloudsec.mdx b/docs/serverless/cloud-native-security/enable-cloudsec.mdx index 5a765d5855..8aa48874bb 100644 --- a/docs/serverless/cloud-native-security/enable-cloudsec.mdx +++ b/docs/serverless/cloud-native-security/enable-cloudsec.mdx @@ -12,12 +12,12 @@ To enable these options or check their current status: 1. Click your project name in the upper-left corner of ((kib)). Select **Manage project**. - + -2. To the right of **Project features**, select **Edit**. +2. To the right of **Project features**, select **Edit**. - + -3. Enable the necessary options, then click **Save**. +3. Enable the necessary options, then click **Save**. Continue with cloud security setup. \ No newline at end of file diff --git a/docs/serverless/cloud-native-security/get-started-with-kspm.asciidoc b/docs/serverless/cloud-native-security/get-started-with-kspm.asciidoc index 7d22128fc6..e7382a3b7e 100644 --- a/docs/serverless/cloud-native-security/get-started-with-kspm.asciidoc +++ b/docs/serverless/cloud-native-security/get-started-with-kspm.asciidoc @@ -89,7 +89,7 @@ If you are using the AWS visual editor to create and modify your IAM Policies, y .Click to view JSON object [%collapsible] ===== -[source] +[source,json] ---- { "Version": "2012-10-17", diff --git a/docs/serverless/cloud-native-security/get-started-with-kspm.mdx b/docs/serverless/cloud-native-security/get-started-with-kspm.mdx index f94a28d0d6..7d35f72627 100644 --- a/docs/serverless/cloud-native-security/get-started-with-kspm.mdx +++ b/docs/serverless/cloud-native-security/get-started-with-kspm.mdx @@ -12,7 +12,7 @@ status: in review This page explains how to configure the Kubernetes Security Posture Management (KSPM) integration. -* KSPM only works in the `Default` ((kib)) space. Installing the KSPM integration on a different ((kib)) space will not work. +* KSPM only works in the `Default` ((kib)) space. Installing the KSPM integration on a different ((kib)) space will not work. * KSPM is not supported on EKS clusters in AWS GovCloud ([request support](https://github.com/elastic/kibana/issues/new/choose)). * To view posture data, ensure you have the appropriate user role to read the following ((es)) indices: @@ -88,7 +88,7 @@ If you are using the AWS visual editor to create and modify your IAM Policies, y -``` +```json { "Version": "2012-10-17", "Statement": [ diff --git a/docs/serverless/cloud-native-security/vuln-management-findings.mdx b/docs/serverless/cloud-native-security/vuln-management-findings.mdx index 915b707b7f..df7500fec6 100644 --- a/docs/serverless/cloud-native-security/vuln-management-findings.mdx +++ b/docs/serverless/cloud-native-security/vuln-management-findings.mdx @@ -9,7 +9,7 @@ status: in review
-The **Vulnerabilities** tab on the Findings page displays the vulnerabilities detected by the CNVM integration. +The **Vulnerabilities** tab on the Findings page displays the vulnerabilities detected by the CNVM integration. ![The Vulnerabilities tab of the Findings page](../images/vuln-management-findings/-cloud-native-security-cnvm-findings-page.png) @@ -53,7 +53,7 @@ When grouping is turned off, you can use the toolbar buttons in the upper-left o * **Fields**: Select which fields to display for each finding. Selected fields appear in the table and the **Columns** menu. -You can also click a column's name to open a menu that allows you to perform multiple actions on the column. +You can also click a column's name to open a menu that allows you to perform multiple actions on the column. ## Learn more about a vulnerability @@ -74,7 +74,7 @@ To remediate a vulnerability and reduce your attack surface, update the affected You can create detection rules that detect specific vulnerabilities directly from the Findings page: -. Click a vulnerability to open the vulnerability details flyout flyout. -. Click **Take action**, then **Create a detection rule**. This automatically creates a detection rule that creates alerts when the associated vulnerability is found. -. To review or customize the new rule, click **View rule**. +1. Click a vulnerability to open the vulnerability details flyout flyout. +1. Click **Take action**, then **Create a detection rule**. This automatically creates a detection rule that creates alerts when the associated vulnerability is found. +1. To review or customize the new rule, click **View rule**. diff --git a/docs/serverless/edr-install-config/agent-tamper-protection.asciidoc b/docs/serverless/edr-install-config/agent-tamper-protection.asciidoc index 426de1a096..2c050f4b16 100644 --- a/docs/serverless/edr-install-config/agent-tamper-protection.asciidoc +++ b/docs/serverless/edr-install-config/agent-tamper-protection.asciidoc @@ -13,7 +13,7 @@ When enabled, {agent} and {elastic-endpoint} can only be uninstalled on the host .Requirements [NOTE] ==== -* Agent tamper protection requires the Endpoint Protection Complete https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature]. +* Agent tamper protection requires the Endpoint Protection Complete <>. * Hosts must be enrolled in the {elastic-defend} integration. * {agent}s must be version 8.11.0 or later. * This feature is supported for all operating systems. diff --git a/docs/serverless/edr-install-config/configure-endpoint-integration-policy.asciidoc b/docs/serverless/edr-install-config/configure-endpoint-integration-policy.asciidoc index 4510902f68..40ec314167 100644 --- a/docs/serverless/edr-install-config/configure-endpoint-integration-policy.asciidoc +++ b/docs/serverless/edr-install-config/configure-endpoint-integration-policy.asciidoc @@ -8,7 +8,7 @@ preview:[] After the {agent} is installed with the {elastic-defend} integration, several protections features — including preventions against malware, ransomware, memory threats, and malicious behavior — are automatically enabled -on protected hosts (most features require the Endpoint Protection Essentials or Endpoint Protection Complete https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature]). If needed, you can update the +on protected hosts (most features require the Endpoint Protection Essentials or Endpoint Protection Complete <>). If needed, you can update the integration policy to configure protection settings, event collection, antivirus settings, trusted applications, event filters, host isolation exceptions, and blocked applications to meet your organization's security needs. @@ -73,7 +73,7 @@ To disable malware protection, turn off the **Malware protections** toggle. .Requirements [NOTE] ==== -Malware protection requires the Endpoint Protection Essentials https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature]. +Malware protection requires the Endpoint Protection Essentials <>. ==== Malware protection levels are: @@ -116,7 +116,7 @@ You can access a quarantined file by using the `get-file` <>. ==== [discrete] @@ -130,7 +130,7 @@ ransomware families — including those targeting the system’s master boot rec .Requirements [NOTE] ==== -Ransomware protection requires the Endpoint Protection Essentials https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature]. +Ransomware protection requires the Endpoint Protection Essentials <>. ==== Ransomware protection levels are: @@ -162,7 +162,7 @@ which are used to evade traditional file-based detection techniques. .Requirements [NOTE] ==== -Memory threat protection requires the Endpoint Protection Essentials https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature]. +Memory threat protection requires the Endpoint Protection Essentials <>. ==== Memory threat protection levels are: @@ -193,7 +193,7 @@ for adversaries to evade than traditional file-based detection techniques. .Requirements [NOTE] ==== -Malicious behavior protection requires the Endpoint Protection Essentials https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature]. +Malicious behavior protection requires the Endpoint Protection Essentials <>. ==== Malicious behavior protection levels are: @@ -224,7 +224,7 @@ This section helps you reduce vulnerabilities that attackers can target on Windo .Requirements [NOTE] ==== -Attack surface reduction requires the Endpoint Protection Essentials https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature]. +Attack surface reduction requires the Endpoint Protection Essentials <>. ==== * **Credential hardening**: Prevents attackers from stealing credentials stored in Windows system process memory. Turn on the toggle to remove any overly permissive access rights that aren't required for standard interaction with the Local Security Authority Subsystem Service (LSASS). This feature enforces the principle of least privilege without interfering with benign system activity that is related to LSASS. diff --git a/docs/serverless/edr-install-config/defend-feature-privs.asciidoc b/docs/serverless/edr-install-config/defend-feature-privs.asciidoc index 1cef912803..6c3a573d0c 100644 --- a/docs/serverless/edr-install-config/defend-feature-privs.asciidoc +++ b/docs/serverless/edr-install-config/defend-feature-privs.asciidoc @@ -8,7 +8,7 @@ preview:[] You can create user roles and define privileges to manage feature access in {elastic-sec}. This allows you to use the principle of least privilege while managing access to {elastic-defend}'s features. -Configure roles and privileges in **Stack Management** → **Custom Roles**. For more details on using this UI, refer to https://www.elastic.co/docs/current/serverless/custom-roles[]. +Configure roles and privileges in **Stack Management** → **Custom Roles**. For more details on using this UI, refer to <>. [NOTE] ==== diff --git a/docs/serverless/edr-install-config/deploy-with-mdm.asciidoc b/docs/serverless/edr-install-config/deploy-with-mdm.asciidoc index 77266f154c..b5753bd0b4 100644 --- a/docs/serverless/edr-install-config/deploy-with-mdm.asciidoc +++ b/docs/serverless/edr-install-config/deploy-with-mdm.asciidoc @@ -54,7 +54,7 @@ image::images/deploy-with-mdm/system-extension-jamf.png[] .. **Socket Filter Bundle Identifier**: Enter `co.elastic.systemextension` .. **Socket Filter Designated Requirement**: Enter the following: + -[source] +[source,txt] ---- identifier "co.elastic.systemextension" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "2BT3HPN62Z" ---- @@ -63,7 +63,7 @@ identifier "co.elastic.systemextension" and anchor apple generic and certificate .. **Network Filter Bundle Identifier**: Enter `co.elastic.systemextension` .. **Network Filter Designated Requirement**: Enter the following: + -[source] +[source,txt] ---- identifier "co.elastic.systemextension" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "2BT3HPN62Z" ---- @@ -104,7 +104,7 @@ image::images/deploy-with-mdm/notifications-jamf.png[] .. From the **Identifier Type** dropdown, select **Bundle ID**. .. Under **Code Requirement**, enter the following: + -[source] +[source,txt] ---- identifier "co.elastic.systemextension" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "2BT3HPN62Z" ---- @@ -116,7 +116,7 @@ identifier "co.elastic.systemextension" and anchor apple generic and certificate .. From the **Identifier Type** dropdown, select **Bundle ID**. .. Under **Code Requirement**, enter the following: + -[source] +[source,txt] ---- identifier "co.elastic.endpoint" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "2BT3HPN62Z" ---- @@ -128,7 +128,7 @@ identifier "co.elastic.endpoint" and anchor apple generic and certificate 1[fiel .. From the **Identifier Type** dropdown, select **Bundle ID**. .. Under **Code Requirement**, enter the following: + -[source] +[source,txt] ---- identifier "co.elastic.elastic-agent" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "2BT3HPN62Z" ---- diff --git a/docs/serverless/edr-install-config/deploy-with-mdm.mdx b/docs/serverless/edr-install-config/deploy-with-mdm.mdx index 1e1c32d04a..ecdbb1b0f3 100644 --- a/docs/serverless/edr-install-config/deploy-with-mdm.mdx +++ b/docs/serverless/edr-install-config/deploy-with-mdm.mdx @@ -24,8 +24,8 @@ In Jamf, create a configuration profile for ((elastic-endpoint)). Follow these s ### Approve the system extension -1. Select the **System Extensions** option to configure the system extension policy for the ((elastic-endpoint)) configuration profile. -1. Make sure that **Allow users to approve system extensions** is selected. +1. Select the **System Extensions** option to configure the system extension policy for the ((elastic-endpoint)) configuration profile. +1. Make sure that **Allow users to approve system extensions** is selected. 1. In the **Allowed Team IDs and System Extensions** section, add the ((elastic-endpoint)) system extension: 1. (Optional) Enter a **Display Name** for the ((elastic-endpoint)) system extension. 1. From the **System Extension Types** dropdown, select **Allowed System Extensions**. @@ -43,13 +43,13 @@ In Jamf, create a configuration profile for ((elastic-endpoint)). Follow these s 1. In the **Socket Filter** section, fill in these fields: 1. **Socket Filter Bundle Identifier**: Enter `co.elastic.systemextension` 1. **Socket Filter Designated Requirement**: Enter the following: - ``` + ```txt identifier "co.elastic.systemextension" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "2BT3HPN62Z" ``` 1. In the **Network Filter** section, fill in these fields: 1. **Network Filter Bundle Identifier**: Enter `co.elastic.systemextension` 1. **Network Filter Designated Requirement**: Enter the following: - ``` + ```txt identifier "co.elastic.systemextension" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "2BT3HPN62Z" ``` 1. Save the configuration. @@ -58,7 +58,7 @@ In Jamf, create a configuration profile for ((elastic-endpoint)). Follow these s ### Enable notifications -1. Select the **Notifications** option to configure the Notification Center policy for the ((elastic-endpoint)) configuration profile. +1. Select the **Notifications** option to configure the Notification Center policy for the ((elastic-endpoint)) configuration profile. 1. Under **App Name**, enter `Elastic Security.app`. 1. Under **Bundle ID**, enter `co.elastic.alert`. 1. In the **Settings** section, include these options with the following settings: @@ -80,7 +80,7 @@ In Jamf, create a configuration profile for ((elastic-endpoint)). Follow these s 1. Under **Identifier**, enter `co.elastic.systemextension`. 1. From the **Identifier Type** dropdown, select **Bundle ID**. 1. Under **Code Requirement**, enter the following: - ``` + ```txt identifier "co.elastic.systemextension" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "2BT3HPN62Z" ``` 1. Make sure that **Validate the Static Code Requirement** is selected. @@ -88,7 +88,7 @@ In Jamf, create a configuration profile for ((elastic-endpoint)). Follow these s 1. Under **Identifier**, enter `co.elastic.endpoint`. 1. From the **Identifier Type** dropdown, select **Bundle ID**. 1. Under **Code Requirement**, enter the following: - ``` + ```txt identifier "co.elastic.endpoint" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "2BT3HPN62Z" ``` 1. Make sure that **Validate the Static Code Requirement** is selected. @@ -96,9 +96,9 @@ In Jamf, create a configuration profile for ((elastic-endpoint)). Follow these s 1. Under **Identifier**, enter `co.elastic.elastic-agent`. 1. From the **Identifier Type** dropdown, select **Bundle ID**. 1. Under **Code Requirement**, enter the following: - ``` - identifier "co.elastic.elastic-agent" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "2BT3HPN62Z" - ``` + ```txt + identifier "co.elastic.elastic-agent" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "2BT3HPN62Z" + ``` 1. Make sure that **Validate the Static Code Requirement** is selected. 1. Save the configuration. diff --git a/docs/serverless/edr-install-config/linux-file-monitoring.asciidoc b/docs/serverless/edr-install-config/linux-file-monitoring.asciidoc index 1900170419..a512ec3634 100644 --- a/docs/serverless/edr-install-config/linux-file-monitoring.asciidoc +++ b/docs/serverless/edr-install-config/linux-file-monitoring.asciidoc @@ -26,7 +26,7 @@ Even when configured to monitor all file systems (`ignore_unknown_filesystems` i `linux.advanced.fanotify.ignore_unknown_filesystems`:: Determines whether to ignore unrecognized file systems. Enter one of the following: - ++ * `true`: (Default) Monitor only Elastic-tested file systems, and ignore all others. You can still monitor or ignore specific file systems with `monitored_filesystems` and `ignored_filesystems`, respectively. * `false`: Monitor all file systems. You can still ignore specific file systems with `ignored_filesystems`. + @@ -37,19 +37,19 @@ If you don't need to monitor additional file systems, it's recommended to change `linux.advanced.fanotify.monitored_filesystems`:: Specifies additional file systems to monitor. Enter a comma-separated list of <> as they appear in `/proc/filesystems` (for example: `jfs,ufs,ramfs`). - ++ [NOTE] ==== It's recommended to avoid monitoring network-backed file systems. ==== - ++ This setting isn't recognized if `ignore_unknown_filesystems` is `false`, since that would mean you're already monitoring _all_ file systems. - ++ Entries in this setting are overridden by entries in `ignored_filesystems`. `linux.advanced.fanotify.ignored_filesystems`:: Specifies additional file systems to ignore. Enter a comma-separated list of <> as they appear in `/proc/filesystems` (for example: `ext4,tmpfs`). - ++ Entries in this setting override entries in `monitored_filesystems`. [discrete] @@ -67,7 +67,7 @@ To find the system file name: + [source,shell] ---- -\> findmnt -o FSTYPE -T /etc/passwd +> findmnt -o FSTYPE -T /etc/passwd FSTYPE ext4 ---- diff --git a/docs/serverless/edr-install-config/linux-file-monitoring.mdx b/docs/serverless/edr-install-config/linux-file-monitoring.mdx index 749d11aa36..5beac0666b 100644 --- a/docs/serverless/edr-install-config/linux-file-monitoring.mdx +++ b/docs/serverless/edr-install-config/linux-file-monitoring.mdx @@ -23,39 +23,47 @@ Even when configured to monitor all file systems (`ignore_unknown_filesystems` i
-`linux.advanced.fanotify.ignore_unknown_filesystems` - : Determines whether to ignore unrecognized file systems. Enter one of the following: + + +
+ `linux.advanced.fanotify.ignore_unknown_filesystems` + + + Determines whether to ignore unrecognized file systems. Enter one of the following: * `true`: (Default) Monitor only Elastic-tested file systems, and ignore all others. You can still monitor or ignore specific file systems with `monitored_filesystems` and `ignored_filesystems`, respectively. * `false`: Monitor all file systems. You can still ignore specific file systems with `ignored_filesystems`. - - If you don't need to monitor additional file systems, it's recommended to change `ignore_unknown_filesystems` to `true`. - + + If you don't need to monitor additional file systems, it's recommended to change `ignore_unknown_filesystems` to `true`. + + + +
+ `linux.advanced.fanotify.monitored_filesystems` + + + Specifies additional file systems to monitor. Enter a comma-separated list of file system names as they appear in `/proc/filesystems` (for example: `jfs,ufs,ramfs`). -
+ + It's recommended to avoid monitoring network-backed file systems. + -`linux.advanced.fanotify.monitored_filesystems` - : Specifies additional file systems to monitor. Enter a comma-separated list of file system names as they appear in `/proc/filesystems` (for example: `jfs,ufs,ramfs`). - - - It's recommended to avoid monitoring network-backed file systems. - - - This setting isn't recognized if `ignore_unknown_filesystems` is `false`, since that would mean you're already monitoring _all_ file systems. + This setting isn't recognized if `ignore_unknown_filesystems` is `false`, since that would mean you're already monitoring _all_ file systems. Entries in this setting are overridden by entries in `ignored_filesystems`. - - -
- -`linux.advanced.fanotify.ignored_filesystems` - : Specifies additional file systems to ignore. Enter a comma-separated list of file system names as they appear in `/proc/filesystems` (for example: `ext4,tmpfs`). + + +
+ `linux.advanced.fanotify.ignored_filesystems` + + + Specifies additional file systems to ignore. Enter a comma-separated list of file system names as they appear in `/proc/filesystems` (for example: `ext4,tmpfs`). Entries in this setting override entries in `monitored_filesystems`. - -
+ + ## Find file system names diff --git a/docs/serverless/edr-install-config/self-healing-rollback.asciidoc b/docs/serverless/edr-install-config/self-healing-rollback.asciidoc index 55e119311c..1d775ed1b8 100644 --- a/docs/serverless/edr-install-config/self-healing-rollback.asciidoc +++ b/docs/serverless/edr-install-config/self-healing-rollback.asciidoc @@ -14,7 +14,7 @@ preview:[] This can help contain the impact of malicious activity, as {elastic-defend} not only stops the activity but also erases any attack artifacts deployed prior to detection. -Self-healing rollback requires the Endpoint Protection Complete https://www.elastic.co/docs/current/serverless/elasticsearch/manage-project[project feature] and is only supported for Windows endpoints. +Self-healing rollback requires the Endpoint Protection Complete <> and is only supported for Windows endpoints. [CAUTION] ==== diff --git a/docs/serverless/edr-install-config/uninstall-agent.asciidoc b/docs/serverless/edr-install-config/uninstall-agent.asciidoc index 2ba8134f2d..60cde6ab44 100644 --- a/docs/serverless/edr-install-config/uninstall-agent.asciidoc +++ b/docs/serverless/edr-install-config/uninstall-agent.asciidoc @@ -15,14 +15,26 @@ For example: ++++
- +
-
+
+++++ +[source,shell] +---- +sudo elastic-agent uninstall --uninstall-token 12345678901234567890123456789012 +---- + +++++ +
+