Subject: [Cacao] CACAO Google Doc

From: Bret Jordan <[email-masked]>
Date: Mon, 17 Sep 2018 10:03:30 -0600

All,

As I mentioned in my Welcome message last week, we plan to use Google Docs to track all comments and suggestions to this draft and any other drafts that we write for this work. The read-only link for this work can be found here:

https://docs.google.com/document/d/1YluuEIv-SREI1i3BHC2Wp8vnvpUOuOZhbfywiUSn2tI/edit# <https://docs.google.com/document/d/1YluuEIv-SREI1i3BHC2Wp8vnvpUOuOZhbfywiUSn2tI/edit#>

If you want to see comments and suggestions that are being proposed, or if you want to add your own comments and suggestion, please request access from within the Google Docs itself. 

Thanks,
Bret
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

---

From: Barry Greene <[email-masked]>
Date: Tue, 18 Sep 2018 05:46:07 +0800

Hello Bret,

My first suggestion is background work. What you are doing is not new. Pull in all the previous work, describe pros/cons/deployment, then get into the gaps which CACAO seeks to fill.

For example, 

- walk through IODEF (IETF) and explain pros, cons, limitations, and how CACAO would be different.
- Walk through STIX and do the same
- Walk through DOTs and explain why we could not use DOTS as it is today (with an update to the schema). 

Barry

> On Sep 18, 2018, at 00:03, Bret Jordan <[email-masked]> wrote:
> 
> All,
> 
> https://docs.google.com/document/d/1YluuEIv-SREI1i3BHC2Wp8vnvpUOuOZhbfywiUSn2tI/edit#
> 
> -- 
> Cacao mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cacao

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 17 Sep 2018 18:16:40 -0400

Hi Barry & Brett,

Sent from my mobile device

> On Sep 17, 2018, at 5:46 PM, Barry Greene <[email-masked]> wrote:
> 
> Hello Bret,
> 

I agree, there’s been a lot of work in this space over a long time and it’s worth the time to review it as much time was spent gathering requirements and discussing.
> - walk through IODEF (IETF) and explain pros, cons, limitations, and how CACAO would be different.

Much of the COA work and policy for INCH and MILE were in RID (RFC6545).  Some was pulled forward to ROLIE and more may be.

> - Walk through DOTs and explain why we could not use DOTS as it is today (with an update to the schema). 
Earlier versions of DOTS work too.

Best regards,
Kathleen

---

From: Bret Jordan <[email-masked]>
Date: Mon, 17 Sep 2018 17:23:41 -0600

Barry,

Thanks for the email. As we stated in our initial draft document…

“While many attempts have been made over the years in the IETF and other SDOs to address certain elements of this problem space, there is currently no consolidated and standardized language or means that would allow cyber actions to be automatically coordinated, sequenced, processed and shared to enable cyber defenders to respond in machine relevant time. Some efforts such as BPMN have traditionally focused on higher-level non-cyber constructs for process definition, and other efforts like OpenC2 have focused purely on atomic actions, but none have focused on the overlay processes required for this to be used in a broader cyber security response use case.”

As we work through and call out the problem spaces that need to be addressed, I would hope that those of you that are interested in this work will point us to specific elements and specific parts of existing work that we can use or reuse. Also as we called out in the draft, it is critical that this work ties in nicely with STIX and TAXII based Cyber Threat Intelligence.

The reason we are looking to start some work here in the IETF, is we feel like this venue might be a good place given the problems we need to solve and how some groups like SUIT have similar problems they are trying to solve. However, if this community does not agree that this work should be done here, that information is also valuable.

Our high level initial goals are (I would be curious to know if this community supports these):

1) Identify all of the problem areas that need to be solved for this to actually work in practice. 

2) Verify that the IETF is the right SDO in which to do this work
	a) Do we have critical mass?
	b) Do we have the right people, vendors, analysts, SOC engineers?
	c) What is the temperament of this community for this kind of work?
	d) Can we do a Bar BOF in Bangkok to gauge the community?
	e) If the community is supportive, would a WG forming BOF be an option in Prague?

3) Ensure we have multiple vendors and industry analysts from large SOCs involved to help ensure that any specification we produce can be used and implemented en mass.

4) Systematically work our way down the list of problem spaces and look for solutions (taking input from existing work where possible). Look to having our first implementable draft within 6 months of getting a WG formed. Release iterative draft releases every few months as we flesh out more of the problem space.

5) Produce a specification and data model for JSON (and CBOR) along with implementation guides, interoperability guides, proof of concepts, and other content needed to ensure successful and rapid adopting across the market.

Thanks,
Bret

> On Sep 17, 2018, at 3:46 PM, Barry Greene <[email-masked]> wrote:
> 
> Hello Bret,
> 
> On Sep 18, 2018, at 00:03, Bret Jordan <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> All,
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/cacao <https://www.ietf.org/mailman/listinfo/cacao>

---

From: Bret Jordan <[email-masked]>
Date: Mon, 17 Sep 2018 17:27:52 -0600

Thanks Kathleen for the response. I always appreciate your comments and feedback and welcome specific examples of existing work and how that work can help us solve the problems we have identified. 

I hope to start a thread in the coming days on the problems that need to be addressed and the order in which they need to be solved. This should give us some concrete point to talk through and discuss. 

Thanks,
Bret

> On Sep 17, 2018, at 4:16 PM, Kathleen Moriarty <[email-masked]> wrote:
> 
> Hi Barry & Brett,
> 
> On Sep 17, 2018, at 5:46 PM, Barry Greene <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Hello Bret,
>>

---

From: Barry Greene <[email-masked]>
Date: Tue, 18 Sep 2018 07:37:08 +0800

Hi Bret,

I read the initial draft. It is an assertion of a gap without a quantitative review that there is a gap. 

I hate wasting time in the IETF working on idea that no way to gain operational traction. This space is overloaded with past efforts. Lets learn why they did not deploy, find the gaps, then proceed with new work.

Barry

> On Sep 18, 2018, at 07:23, Bret Jordan <[email-masked]> wrote:
> 
> Barry,
>

---

From: Bret Jordan <[email-masked]>
Date: Mon, 17 Sep 2018 17:52:11 -0600

Barry,

We will be working on a list of problem areas that need to be addressed and the order in which they need to be solved. If you have specific examples of how certain areas have been solved already and have design elements we could reuse, please share them.  We would love to reuse as much as possible. 

As I stated in goal numbers 2, 3, and 5, we need to ensure that this community has the right people in it, to ensure wide spread adoption. If this community does not have the right people, then we need to either recruit them and bring them in to this community or look for the right community. 

I agree that there are far too many standards created that never get implemented. This is why I also called out the items in goal number 5 and why we have recruited the authors and contributors that we have. 

Thanks,
Bret

> On Sep 17, 2018, at 5:37 PM, Barry Greene <[email-masked]> wrote:
> 
> Hi Bret,
> 
> On Sep 18, 2018, at 07:23, Bret Jordan <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Barry,
>> 
>>> On Sep 17, 2018, at 3:46 PM, Barry Greene <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hello Bret,
>>>

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 17 Sep 2018 22:12:09 -0400

Hi Brett,

I do think the gap analysis Barry suggested is an important step for the
authors of this work to pursue.  This is important for a few reasons.  The
first is that it will familiarize you with the prior work.  I know for RID,
it was extensive with many participants.  The document was also
republished, so the time span was quite a range as well dating back to
2000/1.

On Mon, Sep 17, 2018 at 7:52 PM Bret Jordan <[email-masked]> wrote:

> Barry,
>
> We will be working on a list of problem areas that need to be addressed
> and the order in which they need to be solved. If you have specific
> examples of how certain areas have been solved already and have design
> elements we could reuse, please share them.  We would love to reuse as much
> as possible.
>

You may discover this through the gap analysis that was suggested.  As a
result of that gap analysis, it will be easier to get others to engage in
your work. For those of us who have done work in this space, having that
acknowledged and then you stating the gap will help us all work toward a
common output.

>
> As I stated in goal numbers 2, 3, and 5, we need to ensure that this
> community has the right people in it, to ensure wide spread adoption. If
> this community does not have the right people, then we need to either
> recruit them and bring them in to this community or look for the right
> community.
>

I think through the gap analysis, you'll see the prior work and I think
will find the IETF is the right place.  It will be easier to engage prior
authors rather than asking them to do the analysis against your new effort.
It's just the usual pattern we are accustomed to working in. If you look
back at the SACM BoF for instance, you'll see a gap analysis was requested
against several standards including YANG and NEA among others.

I am guessing through that work we may figure out that this belongs in
MILE, but could be wrong and the analysis suggested will help with that
determination.

This work could be very important and I'd like to see the outputs of that
analysis.  I suspect others who helped on prior efforts would as well.
Thank you.

Best regards,
Kathleen

> I agree that there are far too many standards created that never get
> implemented. This is why I also called out the items in goal number 5 and
> why we have recruited the authors and contributors that we have.
>
>
> Thanks,
> Bret
> I hate wasting time in the IETF working on idea that no way to gain
> operational traction. This space is overloaded with past efforts. Lets
> learn why they did not deploy, find the gaps, then proceed with new work.
>
> Barry
>
> “While many attempts have been made over the years in the IETF and other
> SDOs to address certain elements of this problem space, there is currently
> no consolidated and standardized language or means that would allow cyber
> actions to be automatically coordinated, sequenced, processed and shared to
> enable cyber defenders to respond in machine relevant time. Some efforts
> such as BPMN have traditionally focused on higher-level non-cyber
> constructs for process definition, and other efforts like OpenC2 have
> focused purely on atomic actions, but none have focused on the overlay
> processes required for this to be used in a broader cyber security response
> use case.”
>
> As we work through and call out the problem spaces that need to be
> addressed, I would hope that those of you that are interested in this work
> will point us to specific elements and specific parts of existing work that
> we can use or reuse. Also as we called out in the draft, it is critical
> that this work ties in nicely with STIX and TAXII based Cyber Threat
> Intelligence.
>
> The reason we are looking to start some work here in the IETF, is we feel
> like this venue might be a good place given the problems we need to solve
> and how some groups like SUIT have similar problems they are trying to
> solve. However, if this community does not agree that this work should be
> done here, that information is also valuable.
>
>
> 3) Ensure we have multiple vendors and industry analysts from large SOCs
> involved to help ensure that any specification we produce can be used and
> implemented en mass.
>
> 4) Systematically work our way down the list of problem spaces and look
> for solutions (taking input from existing work where possible). Look to
> having our first implementable draft within 6 months of getting a WG
> formed. Release iterative draft releases every few months as we flesh out
> more of the problem space.
>
> 5) Produce a specification and data model for JSON (and CBOR) along with
> implementation guides, interoperability guides, proof of concepts, and
> other content needed to ensure successful and rapid adopting across the
> market.
>
>
>
> Thanks,
> Bret
> My first suggestion is background work. What you are doing is not new.
> Pull in all the previous work, describe pros/cons/deployment, then get into
> the gaps which CACAO seeks to fill.
>
> For example,
>
> As I mentioned in my Welcome message last week, we plan to use Google Docs
> to track all comments and suggestions to this draft and any other drafts
> that we write for this work. The read-only link for this work can be found
> here:
>
>
> If you want to see comments and suggestions that are being proposed, or if
> you want to add your own comments and suggestion, please request access
> from within the Google Docs itself.
>
>
>
> Thanks,
> Bret

-- 

Best regards,
Kathleen

---

From: <[email-masked]>
Date: Tue, 18 Sep 2018 07:48:54 +0000

Hi

I agree that a gap analysis would be great, but I read this discussion as "include this in the document that proposes a new approach". If I read that correctly, I would propose to split that out into two documents. The reason is that this sounds like a huge monster document, nobody can digest anymore. I think it would be valuable to have a gap analysis / motivation type of document and then another one (or several other ones) describing the new approach.

best regards
Carolin

From: Cacao [mailto:[email-masked]] On Behalf Of Kathleen Moriarty
Sent: Tuesday, September 18, 2018 4:12 AM
To: Bret Jordan <[email-masked]>
Cc: Barry Greene <[email-masked]>; [email-masked]
Subject: Re: [Cacao] CACAO Google Doc

Hi Brett,

I do think the gap analysis Barry suggested is an important step for the authors of this work to pursue.  This is important for a few reasons.  The first is that it will familiarize you with the prior work.  I know for RID, it was extensive with many participants.  The document was also republished, so the time span was quite a range as well dating back to 2000/1.

On Mon, Sep 17, 2018 at 7:52 PM Bret Jordan <[email-masked]<mailto:[email-masked]>> wrote:
Barry,

You may discover this through the gap analysis that was suggested.  As a result of that gap analysis, it will be easier to get others to engage in your work. For those of us who have done work in this space, having that acknowledged and then you stating the gap will help us all work toward a common output.

I think through the gap analysis, you'll see the prior work and I think will find the IETF is the right place.  It will be easier to engage prior authors rather than asking them to do the analysis against your new effort. It's just the usual pattern we are accustomed to working in. If you look back at the SACM BoF for instance, you'll see a gap analysis was requested against several standards including YANG and NEA among others.

I am guessing through that work we may figure out that this belongs in MILE, but could be wrong and the analysis suggested will help with that determination.

This work could be very important and I'd like to see the outputs of that analysis.  I suspect others who helped on prior efforts would as well.  Thank you.

Best regards,
Kathleen

Thanks,
Bret

On Sep 17, 2018, at 5:37 PM, Barry Greene <[email-masked]<mailto:[email-masked]>> wrote:

Hi Bret,

Barry

On Sep 18, 2018, at 07:23, Bret Jordan <[email-masked]<mailto:[email-masked]>> wrote:
Barry,

Thanks,
Bret

On Sep 17, 2018, at 3:46 PM, Barry Greene <[email-masked]<mailto:[email-masked]>> wrote:

Hello Bret,

For example,

Barry

On Sep 18, 2018, at 00:03, Bret Jordan <[email-masked]<mailto:[email-masked]>> wrote:
All,

https://docs.google.com/document/d/1YluuEIv-SREI1i3BHC2Wp8vnvpUOuOZhbfywiUSn2tI/edit#<https://docs.google.com/document/d/1YluuEIv-SREI1i3BHC2Wp8vnvpUOuOZhbfywiUSn2tI/edit>

Thanks,
Bret

--
Cacao mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cacao

--
Cacao mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cacao

--

Best regards,
Kathleen

---

From: Amelia Andersdotter <[email-masked]>
Date: Tue, 18 Sep 2018 11:21:13 +0200

Hi all,

I understand that reporting on cyber threats and proposing mitigating
remedies for cyber threats is increasingly a government affair (i.e. has
regulatory implications), so this is an aspect that needs to be covered
as well.

I.e., if there is a regulatory established mechanism for information
sharing in any jurisdiction, any organisation doing reporting or
mitigation work would have to certainly comply at least with local
regulations - would this project aim to facilitate compliance in this
regard? And what is required for that?

I guess this speaks again to a more robust "gap analysis", and Carolin's
point on having two separate documents resonates with me.

Generally, I'm uncomfortable with the idea of Globally Unique
Identifiers and do not think it constructive for CACAO to propose that.
It's anti-thetical to a lot of other developments, and regulatory concerns.

best,

Amelia

On 2018-09-18 09:48, [email-masked] wrote:
>
> Hi
>
>  
>
> I agree that a gap analysis would be great, but I read this discussion
> as "include this in the document that proposes a new approach". If I
> read that correctly, I would propose to split that out into two
> documents. The reason is that this sounds like a huge monster
> document, nobody can digest anymore. I think it would be valuable to
> have a gap analysis / motivation type of document and then another one
> (or several other ones) describing the new approach.
>
>  
>
> best regards
>
> Carolin
>
>  
>
> *From:*Cacao [mailto:[email-masked]] *On Behalf Of *Kathleen
> Moriarty
> *Sent:* Tuesday, September 18, 2018 4:12 AM
> *To:* Bret Jordan <[email-masked]>
> *Cc:* Barry Greene <[email-masked]>; [email-masked]
> *Subject:* Re: [Cacao] CACAO Google Doc
>
>  
>
> Hi Brett,
>
>  
>
> I do think the gap analysis Barry suggested is an important step for
> the authors of this work to pursue.  This is important for a few
> reasons.  The first is that it will familiarize you with the prior
> work.  I know for RID, it was extensive with many participants.  The
> document was also republished, so the time span was quite a range as
> well dating back to 2000/1.  
>
>  
>
>     We will be working on a list of problem areas that need to be
>     addressed and the order in which they need to be solved. If you
>     have specific examples of how certain areas have been solved
>     already and have design elements we could reuse, please share
>     them.  We would love to reuse as much as possible. 
>
>  
>
> You may discover this through the gap analysis that was suggested.  As
> a result of that gap analysis, it will be easier to get others to
> engage in your work. For those of us who have done work in this space,
> having that acknowledged and then you stating the gap will help us all
> work toward a common output.  
>
>      
>
>     As I stated in goal numbers 2, 3, and 5, we need to ensure that
>     this community has the right people in it, to ensure wide spread
>     adoption. If this community does not have the right people, then
>     we need to either recruit them and bring them in to this community
>     or look for the right community. 
>
>  
>
> I think through the gap analysis, you'll see the prior work and I
> think will find the IETF is the right place.  It will be easier to
> engage prior authors rather than asking them to do the analysis
> against your new effort. It's just the usual pattern we are accustomed
> to working in. If you look back at the SACM BoF for instance, you'll
> see a gap analysis was requested against several standards including
> YANG and NEA among others.  
>
>  
>
> MILE, but could be wrong and the analysis suggested will help with
> that determination.
>
>  
>
> This work could be very important and I'd like to see the outputs of
> that analysis.  I suspect others who helped on prior efforts would as
> well.  Thank you.
>
>  
>
> Best regards,
>
> Kathleen
>
>  
>
>      
>
>     I agree that there are far too many standards created that never
>     get implemented. This is why I also called out the items in goal
>     number 5 and why we have recruited the authors and contributors
>     that we have. 
>
>      
>
>      
>
>     Thanks,
>
>     Bret
>
>         On Sep 17, 2018, at 5:37 PM, Barry Greene
>         <[email-masked] <mailto:[email-masked]>> wrote:
>
>          
>
>         Hi Bret,
>
>          
>
>         I read the initial draft. It is an assertion of a gap without
>         a quantitative review that there is a gap. 
>
>          
>
>         I hate wasting time in the IETF working on idea that no way to
>         gain operational traction. This space is overloaded with past
>         efforts. Lets learn why they did not deploy, find the gaps,
>         then proceed with new work.
>
>          
>
>         Barry
>
>
>             “While many attempts have been made over the years in the
>             IETF and other SDOs to address certain elements of this
>             problem space, there is currently no consolidated and
>             standardized language or means that would allow cyber
>             actions to be automatically coordinated, sequenced,
>             processed and shared to enable cyber defenders to respond
>             in machine relevant time. Some efforts such as BPMN have
>             traditionally focused on higher-level non-cyber constructs
>             for process definition, and other efforts like OpenC2 have
>             focused purely on atomic actions, but none have focused on
>             the overlay processes required for this to be used in a
>             broader cyber security response use case.”
>
>              
>
>             As we work through and call out the problem spaces that
>             need to be addressed, I would hope that those of you that
>             are interested in this work will point us to specific
>             elements and specific parts of existing work that we can
>             use or reuse. Also as we called out in the draft, it is
>             critical that this work ties in nicely with STIX and TAXII
>             based Cyber Threat Intelligence.
>
>              
>
>             The reason we are looking to start some work here in the
>             IETF, is we feel like this venue might be a good place
>             given the problems we need to solve and how some groups
>             like SUIT have similar problems they are trying to solve.
>             However, if this community does not agree that this work
>             should be done here, that information is also valuable.
>
>              
>
>              
>
>             1) Identify all of the problem areas that need to be
>             solved for this to actually work in practice. 
>
>              
>
>             3) Ensure we have multiple vendors and industry analysts
>             from large SOCs involved to help ensure that any
>             specification we produce can be used and implemented en mass.
>
>              
>
>             4) Systematically work our way down the list of problem
>             spaces and look for solutions (taking input from existing
>             work where possible). Look to having our first
>             implementable draft within 6 months of getting a WG
>             formed. Release iterative draft releases every few months
>             as we flesh out more of the problem space.
>
>              
>
>             5) Produce a specification and data model for JSON (and
>             CBOR) along with implementation guides, interoperability
>             guides, proof of concepts, and other content needed to
>             ensure successful and rapid adopting across the market.
>
>              
>
>              
>
>              
>
>             Thanks,
>
>             Bret
>
>             "Without cryptography vihv vivc ce xhrnrw, however, the
>             only thing that can not be unscrambled is an egg."
>
>
>
>                 On Sep 17, 2018, at 3:46 PM, Barry Greene
>                 <[email-masked]
>                 <mailto:[email-masked]>> wrote:
>
>                  
>
>                 Hello Bret,
>
>                  
>
>                 My first suggestion is background work. What you are
>                 doing is not new. Pull in all the previous work,
>                 describe pros/cons/deployment, then get into the gaps
>                 which CACAO seeks to fill.
>
>                  
>
>                 For example, 
>
>                  
>
>                 - walk through IODEF (IETF) and explain pros, cons,
>                 limitations, and how CACAO would be different.
>
>                 - Walk through DOTs and explain why we could not use
>                 DOTS as it is today (with an update to the schema). 
>
>                  
>
>                 Barry
>
>
>                 On Sep 18, 2018, at 00:03, Bret Jordan
>                 <[email-masked] <mailto:[email-masked]>>
>                 wrote:
>
>                     All,
>
>                      
>
>                     As I mentioned in my Welcome message last week, we
>                     plan to use Google Docs to track all comments and
>                     suggestions to this draft and any other drafts
>                     that we write for this work. The read-only link
>                     for this work can be found here:
>
>                      
>
>                     <https://docs.google.com/document/d/1YluuEIv-SREI1i3BHC2Wp8vnvpUOuOZhbfywiUSn2tI/edit>
>
>                      
>
>                     If you want to see comments and suggestions that
>                     are being proposed, or if you want to add your own
>                     comments and suggestion, please request access
>                     "Without cryptography vihv vivc ce xhrnrw,
>                     however, the only thing that can not be
>                     unscrambled is an egg."
>
>                      
>
>                     -- 
>                     Cacao mailing list

-- 
Amelia Andersdotter
Technical Consultant, Digital Programme

ARTICLE19
www.article19.org

PGP: 3D5D B6CA B852 B988 055A 6A6F FEF1 C294 B4E8 0B55

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 18 Sep 2018 06:26:42 -0400

> On Sep 18, 2018, at 5:21 AM, Amelia Andersdotter <[email-masked]> wrote:
> 
> Hi all,
> 

The gap analysis could be a wiki or some other document that does not get published, but I think it’s an important exercise.

Best regards,
Kathleen

---

From: Bret Jordan <[email-masked]>
Date: Tue, 18 Sep 2018 08:36:50 -0600

Carolin,

That is a great point.  If someone wants to do a GAP analysis as a different document, they are free to do so.  We have reviewed the existing work and there is no single solution today that will solve the use cases we have and that we need to address for this to work operationally.  No where in the IETF or other SDOs is there a specification that one could hand to a vendor, organization, or developer to have them implement and do interoperability with. There are bits and pieces of lots of standards inside the IETF and outside the IETF that we will want to use.  But in general, we need and want to go down a different path.

Thanks,
Bret

> On Sep 18, 2018, at 1:48 AM, [email-masked] wrote:
> 
> Hi
>  
> From: Cacao [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Kathleen Moriarty
> To: Bret Jordan <[email-masked] <mailto:[email-masked]>>
> Cc: Barry Greene <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> On Mon, Sep 17, 2018 at 7:52 PM Bret Jordan <[email-masked] <mailto:[email-masked]>> wrote:
> Barry,
>  
> On Sep 17, 2018, at 5:37 PM, Barry Greene <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Bret,
>  
> https://docs.google.com/document/d/1YluuEIv-SREI1i3BHC2Wp8vnvpUOuOZhbfywiUSn2tI/edit# <https://docs.google.com/document/d/1YluuEIv-SREI1i3BHC2Wp8vnvpUOuOZhbfywiUSn2tI/edit>
>

---

From: Bret Jordan <[email-masked]>
Date: Tue, 18 Sep 2018 08:45:20 -0600

Amelia,

I will make some comments in-line. 

Thanks,
Bret

> regulatory implications), so this is an aspect that needs to be covered

There are regulatory requirements outside of just government that need to ensure and verify that certain things are done either as preventive steps or as mitigation / remediation steps. This is why it is so critical that you can issue commands, get responses from commands, and be able to tie all of this back to the Indicators, Threat Actors, Campaigns, Intrusion Sets etc that are documented in STIX.  

> regard? And what is required for that?

This work should enable that to take place. There are many vendors that are trying to offer these solution in their own proprietary ways.  However, if the eco-system is truly going to gain the upper hand against Threat Actors and Intrusion Sets, then we need to have solutions that can work vertical / sector wide in machine relevant time. 

> It's anti-thetical to a lot of other developments, and regulatory concerns.

In sharing groups, trust groups, ISAOs, ISACs, etc, you need a way of being able to tie certain comments and sequences of commands back in to a graph.  The only way this works is if you using UUIDv4 or UUIDv5 like IDs.  Now UUIDv5 can be problematic if you want to enable or allow versioning of the command itself, since the deterministic ID will change and thus break your graph.