Works for me. This would then track very nicely with the US-CERT Federal Incident Notification guidelines.
Â
Â
Â
Â
From: "Mates, Jeffrey CIV DC3/TSD" <Jeffrey.Mates@dc3.mil>
Date: Friday, November 13, 2020 at 6:03 PM
To: Paul Patrick <ppatrick@darklight.ai>, 'Rich Piazza' <[email protected]>, "[email protected]" <[email protected]>
Subject: Re: [cti] RE: Adding an Incident SDO stub to 2.1Â
I was originally thinking that the Infrastructure would tie to a location, but you're right that might that might end just resulting in an unnecessary layer of indirection and force nearly empty Infrastructure objects to be generated. I think switching it to element_ref would be a lot cleaner.â
Â
From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Paul Patrick <[email protected]>
Sent: Friday, November 13, 2020 5:24 PM
To: Mates, Jeffrey CIV DC3/TSD; 'Rich Piazza'; cti@lists.oasis-open.org
Subject: [Non-DoD Source] Re: [cti] RE: Adding an Incident SDO stub to 2.1Â
Jeff,
Â
While I agree getting consensus on a full definition would be extremely difficult, I think what youâve pulled together is rather good.
Â
Had two comments I wanted to check with you:
Â
 I didnât see, through example, a way to reference the location of activity. Although it would be easy to do with a relationship to a location object
ÂÂÂÂÂÂÂÂÂ I would suggest that the infrastructure_ref property of the impact_element object might better be served if it was an object_ref so that things other than infrastructure objects could be specified.Â
Â
Â
Paul Patrick
Â
Â
From: <cti@lists.oasis-open.org> on behalf of "Mates, Jeffrey CIV DC3/TSD" <[email protected]>
Date: Friday, November 13, 2020 at 3:45 PM
To: 'Rich Piazza' <rpiazza@mitre.org>, "[email protected]" <[email protected]>
Subject: [cti] RE: Adding an Incident SDO stub to 2.1Â
While Iâm very much in favor of creating an Incident object, I am concerned that generating a stub and having everyone put different things to do it may do us more harm than good as I imagine we are all looking at structuring it very differently.
Â
I have attached a draft that I have been working on along with samples of it in use to illustrate just how divergent thoughts on this may be. I know that working through what I have now has certainly run into challenges as balancing current and future needs across multiple systems is extremely challenging which is why I have not put forward much so far on this.
Â
While I am certainly happy to discuss the stub proposal and various potential incidents proposals on the working call I expect that reaching consensus is going to be a challenge.
Â
//SIGNED//
Â
Jeffrey Mates, Civ DC3/TSD
Computer Scientist
Technical Solutions Development
410-694-4335
Â
From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> On Behalf Of Rich Piazza
Sent: Friday, November 13, 2020 2:16 PM
To: cti@lists.oasis-open.org
Subject: [Non-DoD Source] [cti] Adding an Incident SDO stub to 2.1Â
The editors would like to propose an addition to the specification, suggested by Paul Patrick.
Â
Many in the community have commented about the lack of an Incident SDO in STIX 2.1. This has caused them to define their own, as a custom object. With the inclusion of the STIX extension facility into the specification, it has been suggested that the 2.1 spec includes a âstubâ for Incident. This âstubâ would act as a placeholder, from which the members of the community could base the extensions for their Incident content. The text added to the specification to define the Incident SDO would be minimal â similar to the stub for the Course of Action.Â
Â
Please respond if you feel this addition to the specification should not happen. If there is any objections, we can discuss them on the next weekâs call.
Â
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ Rich P.
Â
--Â
Rich Piazza
Lead Cyber Security Engineer
The MITRE Corporation
781-271-3760
Â
Â
Â
Â
Â
