[Security Solution][Platform] - Step 4 of SO migrations, marking as share capable

[yctercero]

As part of 8.0 SO migrations need to mark certain SOs as "share capable".

See docs https://www.elastic.co/guide/en/kibana/master/sharing-saved-objects.html

An example PR of this is here.

Security Solution SOs can be found here.

So what's it means for our SOs? Alerting has marked rules as share-capable, does this mean all our SOs need to now be made share-capable as well?

Do agnostic ones need to be marked?

• ✅ Rules: alerting has marked as share-capable
• ✅ siem-detection-engine-rule-actions
  • [Security Solutions] Makes legacy actions/notification system, legacy action status, and exception lists multiple space shareable #115427
• ✅ exception-list-agnostic
  • ✅ NOTE: need to test if agnostic exceptions were migrated into references [Update - were migrated]
• ✅ exception-list
  • [Security Solutions] Makes legacy actions/notification system, legacy action status, and exception lists multiple space shareable #115427
• ✅ siem-detection-engine-rule-status
  • @spong PR
  • [Security Solutions] Makes legacy actions/notification system, legacy action status, and exception lists multiple space shareable #115427
• ✅ security-rule
  • @peluja1012 followup
  • [UPDATE] - these are all agnostic and so don't need to be touched for 8.0
• ✅ endpoint:user-artifact-manifest
  • @peluja1012 @paul-tavares followup
  • these are agnostic so ll good
• ✅ endpoint:user-artifact
  • @peluja1012 @paul-tavares followup
  • these are agnostic so all good
• ✅ security-solution-signals-migration
  • @rylnd
  • See comment below from Ryland and Joe
• ✅ Timeline template
• ✅ Timeline notes

[elasticmachine]

Pinging @elastic/security-solution (Team: SecuritySolution)

[yctercero]

Confirmed with @michaelolo24 that timeline SOs have been made "share-capable". cc @jonathan-buttner

[michaelolo24]

For reference: #113552

[yctercero]

Also (thanks Mike) - cases is all set here as well ✅

[yctercero]

NOTE: siem-detection-engine-rule-status being taken care of by @spong (thank you!)

[yctercero]

NOTE: security-rules are all agnostic 🚀 Thanks @spong and @peluja1012 for looking into it.

[paul-tavares]

@yctercero I'm about to start looking into this for things associated with Artifacts and Exceptions (for trusted apps, event filters) and want to confirm: Our artifacts and exceptions SOs are all space agnostic, does that mean we don't have to do anything? 😁

[paul-tavares]

Hi @yctercero ,

Here is an update for SO types:

• endpoint:user-artifact-manifest and
• endpoint:user-artifact

Both of these SO types are namespaceType: 'agnostic' (see here ) and my understanding is that for space agnostic objects, we don't need to do any migration.

These, as well as exception-list-agnostic, do reference Fleet Package Policies IDs (SOs as well), but those are also namespaceType: 'agnostic (see here)

[yctercero]

Hi @yctercero ,

Here is an update for SO types:

• endpoint:user-artifact-manifest and
• endpoint:user-artifact

Both of these SO types are namespaceType: 'agnostic' (see here ) and my understanding is that for space agnostic objects, we don't need to do any migration.

These, as well as exception-list-agnostic, do reference Fleet Package Policies IDs (SOs as well), but those are also namespaceType: 'agnostic (see here)

We confirmed that's true, for agnostic we do not need to make them share-capable.

[rylnd]

PR to update our security-solution-signals-migration SOs: #115281

[jportner]

I spoke to @rylnd about the security-solution-signals-migration object type, which are used in the Detection Alerts Migration APIs:

1. These objects are only accessed through these APIs
2. These objects are short-lived (the user will upgrade Kibana, then call these APIs, which creates and subsequently deletes these saved objects)
3. These objects are always isolated to an individual space, they won’t need to be shared in the future (and they will eventually be superseded by “alerts-as-data”)
4. There are no references from other objects to these objects
5. There are no references from these objects to other objects

With that in mind, I don't think we need to convert these to become share-capable, we can leave them as isolated (namespaceType: 'single') 👍

[yctercero]

Closing out as it seems all SOs have been taken care of. Thanks everyone!