OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [cti] Adding an Incident SDO stub to 2.1


In that situation wouldnât the CoA leverage a playbook to orchestration the remediation or mitigation?  In such a case, the STIX CoA could have an extension for a playbook, such as that defined by CACAO

 

 

Paul Patrick

 

 

From: aa tt <atcyber1000@gmail.com>
Date: Tuesday, November 17, 2020 at 9:53 AM
To: "Mates, Jeffrey CIV DC3/TSD" <Jeffrey.Mates@dc3.mil>
Cc: Paul Patrick <ppatrick@darklight.ai>, Rich Piazza <rpiazza@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Adding an Incident SDO stub to 2.1

 

It is extremely unlikely that a single CoA would suffice to resolve an incident. Most incidents (if not all) require a set of actions often combined with programmatic structure typically applied by a playbook or similar construct.

 

Allan



On Nov 17, 2020, at 3:42 AM, Mates, Jeffrey CIV DC3/TSD <Jeffrey.Mates@dc3.mil> wrote:

 

That was an oversight on my part.  It certainly could be either an embedded or external reference to a CoA instead of a string.  I have to admit that Iâm less familiar with the work being done on the current stub for CoAs, but are we looking to make these more of a shared collection of fixes that can be applied or organization specific ones.

 

I would expect that for incident response some degree of tailored language on mitigations might be needed per incident so if we are going to aim for reusable CoAs then an additional description field (whether it is in a relationship or object) would be needed to describe how the mitigation was applied. 

 

//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 Paul Patrick
Sent: Monday, November 16, 2020 5:37 PM
To: Mates, Jeffrey CIV DC3/TSD <Jeffrey.Mates@dc3.mil>; 'Rich Piazza' <rpiazza@mitre.org>; cti@lists.oasis-open.org
Subject: [Non-DoD Source] Re: [cti] RE: Adding an Incident SDO stub to 2.1

 

Jeff,

 

Was there a reason mitigation was defined as a string rather than a reference to one or more CourseOfAction objects?

 

 

Paul Patrick

 

 

From: <cti@lists.oasis-open.org> on behalf of Paul Patrick <ppatrick@darklight.ai>
Date: Friday, November 13, 2020 at 5:24 PM
To: "Mates, Jeffrey CIV DC3/TSD" <Jeffrey.Mates@dc3.mil>, 'Rich Piazza' <rpiazza@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: 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" <Jeffrey.Mates@dc3.mil>
Date: Friday, November 13, 2020 at 3:45 PM
To: 'Rich Piazza' <rpiazza@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
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

 

<image001.png>

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]