On staging we have the correct source: https://testing.obas.staging.filigran.io/admin/payloads?query=cGFnZT0wJnNpemU9MTAwJmZpbHRlckdyb3VwW2ZpbHRlcnNdW10mZmlsdGVyR3JvdXAlNUJtb2RlJTVEPWFuZCZzb3J0cyU1QjAlNUQlNUJwcm9wZXJ0eSU1RD1wYXlsb2FkX25hbWUmdGV4dFNlYXJjaD1TY2hlZHVsZWQlMjBUYXNrJTIwUGVyc2lzdGVuY2UlMjB2aWElMjBFdmVudHZpZXdlci5tc2Mma2V5PXBheWxvYWRz

So, we need validate the openbas version for https://filigran.obas.filigran.io/admin/payloads and also collector atomic red team version

Hello @EllynBsc and @jborozco
After investigation, it turns out that the payloads mentionned earlier do no longer exist in the atomic red team folder. We now need to figure out what we should when such an event happens. We have three options:

• Delete the payload from the database
• Keep the payload with a "deprecated" or "no longer exist" flag
• Keep things unchanged

Hi @johanah29 👋

2 solutions here IMO:

👉 Solution 1: Keep the payload with a "deprecated in version XX" flag, i think it's important to state to our user that it's deprecated in the current repo version of Atomic Red Team we're using but it might not be the case in a previous version.

👉 Solution 2: Delete the payload from the database, IMO it's not useful for the user to end up on a payload that does not exist in the atomic red team folder. And we should also specify what version of Atomic red team we're using.

=> I'd say we go for solution 1 for now, and then if we realize that atomic red team updates a lot and we end up with a ton of payloads deprecated then we can put solution 2 in place. WDYT ?

@johanah29 @EllynBsc Hello, I would say let's delete the payload to make sure our offer is reflecting functioning payloads.

Hi @jborozco 👋

Good for me!

Solution 2: If we delete the payload, the user might end up with a scenario/simulation/atomic test that no longer exists (possibly while it’s still running), leading to unpleasant surprises.

Proposals:
-> Retain the payload in "read-only" mode (it can no longer be used but can be duplicated) – more complex

-> Convert it to a manual payload (removing all links with Atomic Red Team) with a "deprecated" tag? – easier to implement

1. Duplicate the payload, add the "deprecated" tag, change the source from "community" to "manual"
2. Delete the original payload

Technical brainstorm:

Collector side

1. Call the API with all payloads (batch process with a boolean flag to mark as "clean" or "not clean")
2. OpenBAS platform -> If it doesn’t exist: create it; if it does exist: update it; if removed: duplicate it

Should we apply this approach to the MITRE ATT&CK collector as well?

@helene-nguyen & @flavienSindou
How do you handle the case on your side when the MITRE matrix changes and a phase or an attack pattern is removed? For your MITRE ATT&CK connector.

As discussed during our R&D call, @RomuDeuxfois let's:

-in the UI, display the 'deprecated' tag for the payload not existing (nothing to do in DB)
-some infos in the UI for the possibility to delete the payload (based on updated date and connector updated)

TBD in the longer run, a more generic approach for the payloads deprecated

@isselparra @jborozco @RomuDeuxfois quick recap for the logic of status + sources of our payloads:

• Logic for our payloads status:

  Verified: OpenBAS ensures that the payload works correctly.

  Unverified: OpenBAS has not verified it; the payload may or may not work.

  Deprecated: The source has deprecated the payload, but OpenBAS has kept a record of it; the payload may or may not work.

• Logic for the payloads sources:

  Community: Comes from an external source.

  Manual: Custom payload.

  OpenBAS (our filigran payloads library repo later): Comes from our repository.

After looking at the code on the Atomic Red Team collector, one can see that the payload_source with the value COMMUNITY was set at the beginning of July

On testing, we can see that the Payload indicated as MANUAL was last updated on June and its collector on November:
Payload: Driver Enumeration using DriverQuery
Updated: Jun 28, 2024, 2:15:00 PM
Collector: Atomic Red Team
Collector last update: Nov 15, 2024, 5:20:43 PM

On https://filigran.obas.filigran.io/, the Payload indicated as MANUAL from the Atomic Red Team collector was last updated on June also and its collector on November:
Payload: Driver Enumeration using DriverQuery
Updated: Jun 27, 2024, 2:58:48 PM
Collector: Atomic Red Team
Collector last update: Nov 15, 2024, 5:21:29 PM

For me, we need to make sure that our data is coherent.

I propose a migration that addresses the two problems we have:

• Set payload source as COMMUNITY if from a collector, instead of MANUAL
• Set status as DEPRECATED when a community payload was updated before the update of the collector (proposed interval: one week)

OpenBAS-Platform/openbas#1867

This is the result on the UI, note the filter on the status with DEPRECATED and the enabling of the Delete option but with the Update disabled.

For the longer run, for the payloads depreciation, one approach could be that the Collector at the end of processing all the payloads, provide to the OBAS platform all the updated external IDs and on the OBAS side, based on this list, deprecate the necessary payloads.