Ivan I would suggest that the user of SCO as top-level objects just needs to be conceptually verified.
A couple of real-world examples might suffice.
Malware SDO and/or Malware Analysis SDO referencing SCO artifacts Observed Data referencing SCO artifacts as part of a sighting/observed-data/indicator trifecta.
Those 2 examples might be good enough.
Allan Thomson
CTO ( +1-408-331-6646)
LookingGlass Cyber Solutions
From: "cti@lists.oasis-open.org" <
cti@lists.oasis-open.org> on behalf of "Kirillov, Ivan" <
ikirillov@mitre.org>
Date: Friday, August 9, 2019 at 10:16 AM
To: "cti@lists.oasis-open.org" <
cti@lists.oasis-open.org>
Subject: [cti] STIX 2.1 CSD02 Sponsorship?
All,
Now that STIX 2.1 CSD02 is out the door, we can begin the sponsorship process. However, one of the questions that we (MITRE/DHS) have is with regards to the type of sponsorship expected for each item full
(code + interop text) or just working code. If you recall from the last sponsorship period, certain things like confidence only required working code while others such as the Opinion & Note objects required interop text as well.
Here s the list of items for sponsorship, along with my own thoughts as to the type of sponsorship:
COA: full Grouping: full Infrastructure: full Malware: full Malware Analysis: full SCOs as top-level objects: full however, the level of detail on this one is quite open. Maybe different sponsors can choose different SCOs to cover? SCO relationships: working code Deterministic IDs: working code
Also, I would suggest that we don t formally start the sponsorship period until we get this question resolved, so that sponsors have a better understanding of what is expected.
-Ivan