Re: [cti-stix] Patterning for Course of Actions

[John-Mark Gurney <jmg@newcontext.com>]

Jyoti Verma (jyoverma) wrote this message on Fri, Oct 21, 2016 at 06:38 +0000:
> On 10/20/16, 4:01 PM, "John-Mark Gurney" <jmg@newcontext.com> wrote:
> 
> >Jyoti Verma (jyoverma) wrote this message on Wed, Oct 19, 2016 at 16:16
> >+0000:
> >> I agree that not everything in observable patterning would apply to CoAs
> >> and having a grammar that is _architecturally similar_ would be the
> >>right
> >> way to go. 
> >> 
> >> The use cases around workflow engines is what motivated my question and
> >>a
> >> ³playbook² object could nicely tie things together. Its a great idea!
> >
> >I am interesting in similar things as part of my work.
> >
> >We don't cover those ideas yet, but I hope that once we start work on
> >the COA, and the OpenC2 work that we'll be able to get something similar
> >to what you describe.
> 
> OpenC2 doesn’t solve this problem today since workflow is an external
> dependency for COA and
> Conditional logic similar to Cybox patterning seems appealing. Other folks
> from the OpenC2 group
> could chime in on this topic when it gets picked up and I’d be happy to
> facilitate any discussions.

I agree...  OpenC2 only solves a small segment of what people will need
for doing automated remediation.

> >The other issue is that doing ochastration may involve many different
> >parts to be effective, and this means that the pattern will need to
> >tie some observations together (such as file hash and registry keys) to
> >a single producer, and the ability to tie in additional items, like the
> >switch that a producer (host) is attached too.
> 
> Observations and producer could be represented in the OpenC2 action itself
> but lets discuss this further with more use cases.

Agreed.  Just wanted to point out that others are also thinking along those
lines too.  I'm glad I'm not the only one.

Thanks.

> >> On 10/19/16, 5:31 AM, "Trey Darley" <trey@kingfisherops.com> wrote:
> >> 
> >> >On 19.10.2016 09:09:07, Jason Keirstead wrote:
> >> >> 
> >> >> It is less clear to me if the observable patterning language is the
> >> >> best means to do that. There is a lot of "weight" in observable
> >> >> patterns that doesn't really apply to action sequences ( you are
> >> >> really only interested in a tiny subset ). And yet even so, there
> >> >> are other things you need that are actually missing from the pattern
> >> >> grammar (such as "in parallel with"). You can't define end-to-end
> >> >> workflows using our grammar, that's not really what it was designed
> >> >> for.
> >> >> 
> >> >
> >> >Hey, Jason -
> >> >
> >> >True, the patterning grammar was not designed to support COA-related
> >> >use cases but I think that we can develop a grammar to support COA
> >> >orchestration that's _architecturally similar_ to how we've defined
> >> >the observable patterning language.
> >> >
> >> >> 
> >> >> IMO the actual thing being sought here is an intermediary "playbook"
> >> >> object in between the Incident object and the individual CoA
> >> >> responses. The playbook defines the workflow of CoA and how they tie
> >> >> together.
> >> >> 
> >> >
> >> >That, my friend, is an *excellent* idea!

-- 
John-Mark