Detection Alerts Migration APIedit
After an upgrade of Kibana, the latest Elastic Security features will be available for any new detection alerts that are generated. However, in order to enable new features on existing detection alerts, migration may be necessary. See Release Notes for instructions specific to your upgrade.
Console supports only Elasticsearch APIs. Console doesn’t allow interactions with Kibana APIs. You must use curl
or another HTTP tool instead. For more information, refer to Run Elasticsearch API requests.
Migrating detection alerts is performed at the index level and requires the following steps:
Determine which indices to migrateedit
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.
Requestedit
GET <kibana host>:<port>/api/detection_engine/signals/migration_status?from=now-30d
Request query parametersedit
Name | Type | Description |
---|---|---|
|
datemath |
Maximum age of qualifying detection alerts |
Response exampleedit
{ "indices": [ { "index": ".siem-signals-default-000002", "version": 15, "signal_versions": [ { "version": 15, "count": 100 }, { "version": 16, "count": 87 } ], "migrations": [ { "id": "924f7c50-505f-11eb-ae0a-3fa2e626a51d", "status": "pending", "version": 16, "updated": "2021-01-06T20:41:37.173Z" } ], "is_outdated": true }, { "index": ".siem-signals-default-000003", "version": 16, "signal_versions": [ { "version": 16, "count": 54 } ], "migrations": [], "is_outdated": false } ] }
The above response shows two indices: .siem-signals-default-000002
is outdated, with multiple versions of detection alerts and a pending migration, and .siem-signals-default-000003
, which is up to date as the current write index.
Indices that do not contain detection alerts in the specified range will be filtered from the response.
With the above info, we can compile a list of indices that we wish to migrate.
Find outdated detection alerts with threat intelligence data
After upgrading to Elastic Stack version 7.15.x from release versions 7.12.0 through 7.14.2, you need to migrate detection alerts enriched with threat intelligence data to ensure threat intelligence properly displays in Elastic Security. Run this query to find outdated detection alerts with threat intelligence data:
GET .siem-signals-{KIBANA SPACE ID}/_search { "query": { "nested": { "path": "threat.indicator", "query": { "exists": { "field": "threat.indicator.matched.*" } } } } }
Initiate migrationsedit
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.
Requestedit
POST <kibana host>:<port>/api/detection_engine/signals/migration
Request bodyedit
Name | Type | Description | Required |
---|---|---|---|
|
String[] |
Array of index names to migrate |
Yes |
|
Integer |
Number of alerts to migrate per batch. Corresponds to the |
No |
|
Integer |
The throttle for the migration task in sub-requests per second. Corresponds to |
No |
|
Integer |
The number of subtasks for the migration task. Corresponds to |
No |
Response exampleedit
{ "indices": [ { "index": ".siem-signals-default-000001", "migration_id": "923f7c50-505f-11eb-ae0a-3fa2e626a51d", "migration_index": ".siem-signals-default-000001-r000016" } ] }
The response will include, for each index specified, an ID and destination index for the migration, and an error if unsuccessful.
Finalize migrationsedit
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.
The original indices are not removed as part of this step. After verifying the integrity of the migrated index, you can use the Migration cleanup endpoint to apply a 30-day deletion policy to the original, outdated index.
If an unsuccessful migration is finalized, a deletion policy will be applied to its index, causing it to be deleted after 30 days.
Requestedit
POST <kibana host>:<port>/api/detection_engine/signals/finalize_migration
Request bodyedit
Name | Type | Description | Required |
---|---|---|---|
|
String[] |
Array of `migration_id`s to finalize |
Yes |
Response exampleedit
{ "migrations": [ { "id": "924f7c50-505f-11eb-ae0a-3fa2e626a51d", "completed": true, "destinationIndex": ".siem-signals-default-000002-r000016", "status": "success", "sourceIndex": ".siem-signals-default-000002", "version": 16, "updated": "2021-01-06T22:05:56.859Z" } ] }
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
.
Migration cleanupedit
Migrations favor data integrity over shard size. Consequently, unused or orphaned indices are artifacts of the migration process. A successful migration will result in both the old and new indices being present. As such, the old, orphaned index can (and likely should) be deleted.
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.
Requestedit
DELETE <kibana host>:<port>/api/detection_engine/signals/migration
Request bodyedit
Name | Type | Description | Required |
---|---|---|---|
|
String[] |
Array of `migration_id`s to finalize |
Yes |
Response exampleedit
{ "migrations": [ { "id": "924f7c50-505f-11eb-ae0a-3fa2e626a51d", "destinationIndex": ".siem-signals-default-000002-r000016", "status": "success", "sourceIndex": ".siem-signals-default-000002", "version": 16, "updated": "2021-01-06T22:05:56.859Z" } ] }
The response will include all migrations that were successfully deleted.