Import and export Detection rules using saved-object management

[kobelb]

End-users will commonly use saved-object management's import/export functionality to move saved-objects from one instance to another. Detections should be included in these exports, so end-users have an easy way to migrate all of their saved-objects in a unified manner.

Since there's already a way to import/export detections, this isn't a hard requirement for removing legacy multi-tenancy. However, it would streamline the process for users migrating from a legacy multi-tenant instance to Spaces.

As far as I'm aware, there is currently blocked by #50266 and #82064.

[kobelb]

@spong - Is there a team label I should be using here?

[spong]

@kobelb Team: SecuritySolution & Team:Detections and Resp should cover it for team labels, so all good there 👍 .

I know this is specific to the SO manager, but just want to note that we do currently provide an export/import feature for Detection Rules within the Security Solution directly, although you can only do one space at a time, so users would have to navigate to each space to bulk export all rules within their cluster.

[kobelb]

@spong awesome, I did not know that! If that's the case, then I think we should treat the import/export via saved-object management as optional for the removing legacy multi-tenancy project. While I do think it creates a better user experience for this to be integrated into saved-object management, as long as the user has a way of migrating their data and not having it locked away a legacy tenant, we're 👍

[spong]

++, definitely agree here @kobelb. We'll continue to provide a 1st class means of importing/exporting these objects within the Security App, and also have public API's for importing/exporting detection rules in case users want to automate it across spaces.

The only other SO's we don't have support for exporting are a Detection Rule's actions and exceptions, but it's something we'll want to support here at some point. For actions we could potentially leverage #50266 once available depending on how the UX shapes up, and for exceptions we'll most likely want to roll our own to better integrate with the general importing/exporting of rules.

[kobelb]

Thanks for your patience on this @spong. I'm afraid I misunderstood you previously and thought we were in the clear here. It's my understanding, that the following is roughly the saved-objects that are created when a Detection Rule is created that's using an exception:

When the detection rule is exported, it only contains the detection rule saved-object, none of the related saved-objects appear to be included. As such, when we remove legacy multi-tenancy, the user won't have a way to migrate all of their data from a legacy tenant to Spaces using detection rule import/export. In my opinion, it's fine if we want to rely on a use-case specific import/export. However, it should be able to be used to migrate all of the necessary data in a reasonable manner.

[spong]

The above diagram looks about right. Only note I think would be that while the Detection Rule SO does have a references array linking to Detection Engine Rule Actions, this isn't exposed (or wasn't at the time) via the Alerting/Actions framework, so we're just relying on our own custom fields within the detections logic for the joins.

When the detection rule is exported, it only contains the detection rule saved-object, none of the related saved-objects appear to be included

Correct, Rule Status, Rule Actions and Exception/Value Lists are not included.

In my opinion, it's fine if we want to rely on a use-case specific import/export. However, it should be able to be used to migrate all of the necessary data in a reasonable manner.

I wholeheartedly agree. We'll be working to resolve some of the referential integrity touch points between these objects here in the near-term, so I'll see if we can't also include the import/export of these remaining objects as part of that effort. In the meantime, I'm 👍 to keep this this issue open for tracking purposes, and if #50266 and #82064 end up getting resolved before we can support the remaining objects we can look to leveraging the saved-object management's import/export functionality.

[kobelb]

The ability to export hidden saved-objects and specify onExport hooks has been addressed. This issue is now only blocked by #50266.

If you do happen to find some other infrastructure that is required to make detection rules importable/exportable, please let us know in #82020.