Re: [Cacao] Initial Problem Set

[Bret Jordan <[e-mail]>]

I agree and hope we can borrow elements, concepts, ideas from other work, not just work here in the IETF.  The way I like to approach problems like this is to break them up in to phases. The first of which is the concept phase. Its purpose is to iterate out a list of requirements and problems we need to solve that are tightly scoped to the project at hand. 

To this end, I have I sent a very short list of initial problems to the list a few days ago and a draft last week. The draft contains a few high level requirements. These lists are not complete and not even the full list that we have worked through prior to uploading the draft. But it was meant as a starting point. My hope is that it would foster dialog and communication like “why is X a requirement, how do you plan on solving X, have you thought about problem Y, what about use-case W or requirement Z”. 

Once we have our concept phase done and fleshed out, I would like us to do a lit-review of prior work (even though most of us have already read all of these existing work products) to help us understand what has been done before and what can be reused. Some of us may just be able to point certain requirements at certain sections of existing work, which will be fantastic. 

Doing this will help us do two things:

1) It helps ensure that we do not artificially box ourselves in to a design just because there was something done similar or tangential in the past.

2) It helps ensure that we do not forget anything and ensures that we take advantage of lessons learned or really neat design elements from other work.

After this review phase we would work our way in to design where we will iron out all of the bumps and ridges and ensure that we are not creating a Frankenstein.  Some really cool designs may not be harmonious with our direction or other design elements. In those cases we need to pick and choose or redesign them.

There has been a lot of great work done here in the IETF, other SDOs, and industry in the past. We need to learn from that work and borrow great design elements from as many of them as we can.  But we also need to keep in mind that a complete solution to the problems identified in the CACAO Introduction draft is not currently available and there is no standardized solution used en mass by industry. Several vendors have their own solutions to this problem, but those only work within the confines of their products. We need to bridge the divide between treat hunters, threat defenders, vendor solutions, etc. This is the reason why we are working on this.  

Any work like this does require vast vendor adoption and buy-in and a lot of SMEs from industry. So as this work continues and grows, it is paramount that we engage with industry to help ensure that this works meets their requirements and that industry can and will adopt it. If they can not or will not adopt it, then we need to just stop work. There is no reason to create something that is not going to get adopted en mass. 


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."

> On Sep 19, 2018, at 12:06 PM, Kathleen Moriarty <[e-mail]> wrote:
> 
> Hello Carolin,
> 
> Thanks for your efforts here.
> 
> On Wed, Sep 19, 2018 at 10:26 AM <[e-mail] <mailto:[e-mail]>> wrote:
> Hi Kathleen
> 
>  
> 
> ok thanks for the feedback. I have a question to understand this part better: " I'd be interested to see the requirements matched up against what exists and what can be re-used or what can be a lesson learned as well.  IODEF carries the CoAs that used to be in RID and IODEF has a nesting capability as well as a way to lay our the format to allow for predicate logic, so analysis on that would be interesting as well.  It can be used for chains of connected events/incidents.  Understanding what doesn't work for your new effort would help to understand why it's needed and how it is better."
> 
>  
> 
> Since the goals of both initiatives are different, I struggle a bit. Technically we should always discuss what concepts work for which use case. Like for instance do we need an authentication somewhere or not, and we don't re-invent the authentication. We check how it is usually done today. Is that what you are referring to when you mention the predicate logic etc? So, since MILE already worked on exchange formats for incidents even if their goal was different, we might have similar formatting requirements when we discuss the reactions to incidents? (just picking the formatting example here).
> 
> 
> The gap analysis may wind up just showing the gap, but I am hoping that there will be pieces of knowledge that can be gleaned from prior efforts.   Your authentication example is good.  There may be a need for it and the requirements may guide the selection of a solution that either works for both or that the new work has requirements (or technology evolved) that clearly show the need for something new.  
> 
> MILE protocols all support sharing formatted data, XML, JSON, etc. and are not restricted to IODEF.  There are 3 protocols to look at and I would hope that some could be reused, or that similar patterns may be useful.
> 
> Does that help?
> 
> Thanks,
> Kathleen
> 
> 
> 
>  
> 
> best regards
> 
> Carolin
> 
>  
> 
> From: Kathleen Moriarty [mailto:[e-mail] <mailto:[e-mail]>] 
> Sent: Wednesday, September 19, 2018 4:11 PM
> To: Baumgartner Carolin <[e-mail] <mailto:[e-mail]>>
> Cc: Barry Greene <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; Bret Jordan <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [Cacao] Initial Problem Set
> 
>  
> 
> Hi Carolin,
> 
>  
> 
> Thanks for starting something to help!  I think that could be a good starting point.  I'd be interested to see the requirements matched up against what exists and what can be re-used or what can be a lesson learned as well.  IODEF carries the CoAs that used to be in RID and IODEF has a nesting capability as well as a way to lay our the format to allow for predicate logic, so analysis on that would be interesting as well.  It can be used for chains of connected events/incidents.  Understanding what doesn't work for your new effort would help to understand why it's needed and how it is better.
> 
>  
> 
> Then for RID, there is lots that is met in the requirement list that was sent out and some requirements that I suggested (there are more) that were learned from time and experience on essentially the same problem.
> 
>  
> 
> Barry - understanding more on your work and the Cisco products mentioned would be helpful too.  If standards were used or not and what can be integrated into this effort or what can be a lesson learned to improve for this effort.
> 
>  
> 
> This will be very helpful for a BoF to be successful.  You'll get derailed otherwise.
> 
>  
> 
> Thank you,
> 
> Kathleen
> 
>  
> 
> On Wed, Sep 19, 2018 at 4:31 AM <[e-mail] <mailto:[e-mail]>> wrote:
> 
> Hi Bret, Kathleen
> 
>  
> 
> would that be something that could work as some kind of gap analysis? https://github.com/clatze/ietf/blob/master/CACAO-gap-FAQ.md <https://github.com/clatze/ietf/blob/master/CACAO-gap-FAQ.md> . It is no real gap analysis, this FAQ would rather highlight the differences. I just took two samples to show how that could look like and if that is what could be helpful. We could also include comments here like… "CACAO makes use of XY to achieve its goal".
> 
>  
> 
> best regards
> Carolin
> 
>  
> 
> From: Cacao [mailto:[e-mail] <mailto:[e-mail]>] On Behalf Of Kathleen Moriarty
> Sent: Wednesday, September 19, 2018 4:06 AM
> To: Barry Greene <[e-mail] <mailto:[e-mail]>>
> Cc: [e-mail] <mailto:[e-mail]>; Bret Jordan <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [Cacao] Initial Problem Set
> 
>  
> 
> Hi Bret,
> 
>  
> 
>  
> 
>  
> 
> On Tue, Sep 18, 2018 at 6:35 PM Barry Greene <[e-mail] <mailto:[e-mail]>> wrote:
> 
> Hi Bret,
> 
>  
> 
> What you have below was done in Cisco’s TIDP/TMS architecture.. 
> 
>  
> 
> Barry
> 
> 
> On Sep 18, 2018, at 23:49, Bret Jordan <[e-mail] <mailto:[e-mail]>> wrote:
> 
> All,
> 
>  
> 
> I wanted to start some discussion on some of the initial problems (not all) that we have already identified that need to be solved with this type of solution. Some of the solutions to these will have elements we can borrow from other work. Also, keep in mind all of this needs to work in native JSON..
> 
>  
> 
> Need the ability to document a single command
> Human executed commands
> Native Machine commands (Cisco IOS, Juniper, SEP, OpenC2, SNMP, NETCONF, YANG, etc)
> What device or system does the command target (DesktopOS 10 at IP address 10.0.0.2, Firewall BAR at 192.168.0..2)
> What class of devices or systems does the command target (DesktopOS 10 at patch level 4, Firewall FOO ver 10)
> Additional data classes of IODEF, also the SCI extension.
> 
> https://tools.ietf.org/html/rfc7970 <https://tools.ietf.org/html/rfc7970>
> Need the ability to document a chain of commands
> Need to know if there is temporal logic or conditional logic associated between commands
> Need to know if commands are sequenced or if they can be run in parallel
> Need to know if there are fall through or fail-to-next commands
> Need tracking to know how to back out commands that fail and how far up the tree you need to back out on failure 
>  
> 
> Take a look at the MILE work more closely, there are lessons learned as much of this has been done.  Even if you don't want to use the work, there 's no reason to have us all debate the same things again rather than build from experience.
> 
> IODEF predicate logic:  It's simple and more compact.
> 
> https://tools.ietf.org/html/rfc8274#page-7 <https://tools.ietf.org/html/rfc8274#page-7>
>  
> 
> Need ability to provide Digital signatures at the command, the command chain (tree), and COA Project levels
> These digital signatures need to be included in the payload themselves
> Need to be able to sign a section or part of the JSON text data
> They need to be in parallel and in series. Meaning, a command may individually be signed by more than one people.  The command and a signature may also be signed multiple times in series.
> Example: Company X that makes DesktopOS 10 signs a command that says it will resolve malware Z on DesktopOS 10 patch version 4. Big Bank Foo may then sign that (command + Company sig) and say they have verified it and it works. Some ISAC may then sign that (command + Company sig + Big Bank Foo sig) and then send it out to their eco-system
> Signatures need ability to identify what assertions someone is making.  
> We need to know what the types of assertions should be (it works, it has been verified, it has been reviewed, it may work, it seems to work, etc)
> You also need to consider origin authentication and multi-hop authentication.  There was a lot of work that went into the requirements analysis across areas of the IETF as not to make RID and other MILE protocols specific to incidents or even XML.
> 
> https://tools.ietf.org/html/rfc6545 <https://tools.ietf.org/html/rfc6545> 
> 
>  
> 
> Yes, this is XML and you want JSON, using JOSE, I presume.  Still, the gap analysis I think will be quite useful as I think you are missing requirements we already came up against.  It will speed your work up to leverage existing work.
> 
> Need ability to get responses at the individual command level, the chain of commands level, and the COA Project level. 
> Need to identify the types of responses that can be returned and what are the types of command codes / response codes that should be returned
> Need to identify and have negotiation between systems if the responses should be pushed or pulled.
> Need to know how the individual response can impact the next steps in the chain.
>  
> 
> You also need to consider internationalization, which has already been done in the MILE work.  This level of detail helps a lot for interoperability. There were 3 interoperable implementations of RID, so testing was done, lessons can be learned.  I'm not sure how may IODEF implementations there were/are, but many more than that.
> 
>  
> 
> Once again, please do the gap analysis to save us all time.  There are other MILE documents that may be useful, they can be found off the documents link of the charter page.  ROLIE and XMPP Grid were also designed to work with any format and I believe are more flexible than RID, so there is much that can be gleaned from these efforts as well as the DOTS work.
> 
>  
> 
> Best regards,
> 
> Kathleen
> 
>  
> 
> Things we already know how to do.. We know how to make this work in a graph, we know how to make this work with versioning, we know how to tie these to existing Cyber Threat Intelligence.  
> 
>  
> 
>  
> 
> 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."
> 
>  
> 
> -- 
> Cacao mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/cacao <https://www.ietf.org/mailman/listinfo/cacao>
> -- 
> Cacao mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/cacao <https://www.ietf.org/mailman/listinfo/cacao>
> 
>  
> 
> --
> 
>  
> 
> Best regards,
> 
> Kathleen
> 
> 
> 
>  
> 
> --
> 
>  
> 
> Best regards,
> 
> Kathleen
> 
> 
> 
> -- 
> 
> Best regards,
> Kathleen