Subject: [Cacao] Other thoughts

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

All,

I have heard from three people so far, what do others thing about the draft and this proposed work?

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: Qin Wu <[email-masked]>
Date: Tue, 18 Sep 2018 02:21:02 +0000

Interesting idea, I am wondering why this idea is restricted to cyber security scenarios,  I think it is also applicable to VPN service delivery scenario,

The essence of this idea is work flow management, process management, activity management, so you organize a sequence of process or tasks using
Work flow template, so you can setup it as a situation, monitoring it, optimized it.

In VPN service delivery scenario, I can define Network connectivity setup as
a Event, In this event, the managed object is network connectivity, when network connectivity gets setup, It will trigger another event, i.e., connectivity service performance
monitoring, when network performance parameter such as delay or packet loss exceed some threshold, It can trigger another event or action, to perform network optimization.

So what I like to see a current event triggering another external event, action and managed object is part of event, in VPN service delivery scenario, we
Can establish connection between network service monitoring and network service provision and therefore we can have full lifecycle  management on VPN service, automate
Network management. I think operation area definitely this capability, function, right now NETCONF/YANG doesn’t provide such capability.

One limitation of NETCONF edit-config operation is described in RFC6241:
“
If the <edit-config> operation contains multiple sub-operations
      that apply to the same conceptual node in the underlying data
      model, then the result of the operation is undefined (i.e.,
      outside the scope of the NETCONF protocol).

”
I think the reason is becos NETCONF lack process management capability.

-Qin
发件人: Cacao [mailto:[email-masked]] 代表 Bret Jordan
发送时间: 2018年9月18日 8:27
收件人: [email-masked]
主题: [Cacao] Other thoughts

All,

Thanks,
Bret

---

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

Hi Qin

I think we should not make this too big, otherwise it will be harder to implement. Just my 5 cents

best regards
Carolin

From: Cacao [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Tuesday, September 18, 2018 4:21 AM
To: Bret Jordan <[email-masked]>; [email-masked]
Subject: Re: [Cacao] Other thoughts

”

-Qin
发件人: Cacao [mailto:[email-masked]] 代表 Bret Jordan
发送时间: 2018年9月18日 8:27
收件人: [email-masked]<mailto:[email-masked]>
主题: [Cacao] Other thoughts

All,

Thanks,
Bret

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 18 Sep 2018 09:53:57 +0200

Hello Bret,

Wrt, "action", two question come to mind:

1.) Is the term "action" a superset to the term "corrective action" 
defined in 
https://datatracker.ietf.org/doc/draft-ietf-ccamp-alarm-module/ ? If so, 
it would tie into existing work. Important to note here is that an alarm 
can only be defined, if a corrective action exists.

2.) Would the term "action" in this domain justify the exploration of 
the ECA model (Event-Condition-Action) used, for example, in I2NSF or 
NETCONF?

https://datatracker.ietf.org/doc/draft-ietf-i2nsf-capability/
https://datatracker.ietf.org/doc/draft-bryskin-netconf-automation-yang/

Viele Grüße,

Henk

---

From: Bret Jordan <[email-masked]>
Date: Tue, 18 Sep 2018 14:20:03 +0000

Qin,

Thank you for your response and question.  The reason we have selected the Cyber Security Scenario is that it is an area that the authors and contributors understand really well and where we know that there is no existing solution that will work.  We also do not want to boil the ocean. We want to get a solution done quickly and get it adapted en mass. This also means that we do not plan on doing everything in the first release. It is more important that we gain adoption than produce the most perfect standard/specification.

A lot of the design work that we need to do for this to actually work in practice could easily be adapted in to other areas.  And I am sure others will take this work and use it for things like outside of the Cyber domain, as you have suggested.

I would love to have you help out. Please let me know if there is anything I can do to help enable you to contribute to this work.

Thanks

Bret

________________________________
From: Cacao <[email-masked]> on behalf of Qin Wu <[email-masked]>
Sent: Monday, September 17, 2018 8:21:02 PM
To: Bret Jordan; [email-masked]
Subject: [EXT] Re: [Cacao] Other thoughts

“

”

-Qin

All,

Thanks,

Bret

---

From: Bret Jordan <[email-masked]>
Date: Tue, 18 Sep 2018 14:22:03 +0000

Carolin,

I agree.  We need to ensure that this is simple to understand and easy to implement.

Bret

________________________________
From: Cacao <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: Tuesday, September 18, 2018 1:50:02 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: [EXT] Re: [Cacao] Other thoughts

Hi Qin

best regards
Carolin

“

”

-Qin

All,

Thanks,

Bret

---

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

Henk,

Thanks for the email and questions.  I looked at the draft you linked and there are 15 uses of the term “corrective action” but it is never defined in the document. So I can not comment completely on if it is a super set or not.  As I have said before, there is a lot of good work that has been done in the IETF and other SDOs that we would like to make use of and bring together in to a single specification that someone could actually implement or perform interoperability tests against. 

I believe hooking in to I2NSF and such will be important going forward. As I have been doing more work in the ITU and other SDOs I can see this as becoming critical long-term.  But we need to start somewhere, but always keep an eye to where we need to go. 

My primary objectives is to get something put together rather quickly and get open-source proof of concept solutions written. Then go to RSA and BlackHat and talk with all of the CTOs on the show floor and try and get them to adopt and look at this work. Writing a standard / specification without doing the PR / Marketing work does not get us to where we need to be.

So this is a long answer, but yes, I hope each of you that have unique understanding and experience with other work products, can help bring that knowledge to the table so we can use it as we go forward. Once again, assuming that this community wants us to do this work here. 

Thanks,
Bret

> On Sep 18, 2018, at 1:53 AM, Henk Birkholz <[email-masked]> wrote:
> 
> Hello Bret,
> 
> 1.) Is the term "action" a superset to the term "corrective action" defined in https://datatracker.ietf.org/doc/draft-ietf-ccamp-alarm-module/ ? If so, it would tie into existing work. Important to note here is that an alarm can only be defined, if a corrective action exists.
> 
> 2.) Would the term "action" in this domain justify the exploration of the ECA model (Event-Condition-Action) used, for example, in I2NSF or NETCONF?
>

---

From: "Jason Keirstead" <[email-masked]>
Date: Tue, 18 Sep 2018 12:41:36 -0300

Hello all;

I want to offer a point that I think can help clarify some overall themes 
of the questions being posed thus far.

The CACAO effort *does not* have any desire to actually define or 
communicate the low-level atomic methodology of a singular course of 
action. OpenC2 is one such standard one may use to that effect, NETCONF 
may be another, as could YANG, or basic SNMP, or many other existing 
standards. 

We are not seeking to tie this effort to any of them, because any of them 
may actually be referenced inside a CACAO project - it is important for 
the CACAO effort to be very loosely-coupled to the actual action 
evaluation mechanisms, since the methods used in the market today are 
extremely varied and the effort therefore must support many different 
mechanisms. These courses of action will also very often not solely be 
executed in the cyber domain - humans often manually perform phases of a 
response. 

What we are attempting to define here is a standard way to share the 
actual high-level procedures and/or workflows (the terminology used in the 
cybersecurity realm is the "playbook") with which these actions are 
executed, not the low-level action operation itself. 

I hope that can clarify matters somewhat, and also make it more obvious 
why this work is not covered by any current work in 
STIX/TAXII/IODEF/DOTS/MILE. All of those standards revolve around a method 
of communicating a threat or security incident. We are seeking to 
communicate the response methodology for that incident.

-
Jason Keirstead
Lead Architect - IBM.Security
www.ibm.com/security

---

From: Bret Jordan <[email-masked]>
Date: Tue, 18 Sep 2018 09:49:33 -0600

Yes, I completely agree Jason.  Well said.

Thanks,
Bret

> On Sep 18, 2018, at 9:41 AM, Jason Keirstead <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hello all;
> 
> I want to offer a point that I think can help clarify some overall themes of the questions being posed thus far.
> 
> The CACAO effort *does not* have any desire to actually define or communicate the low-level atomic methodology of a singular course of action. OpenC2 is one such standard one may use to that effect, NETCONF may be another, as could YANG, or basic SNMP, or many other existing standards. 
> 
> We are not seeking to tie this effort to any of them, because any of them may actually be referenced inside a CACAO project - it is important for the CACAO effort to be very loosely-coupled to the actual action evaluation mechanisms, since the methods used in the market today are extremely varied and the effort therefore must support many different mechanisms. These courses of action will also very often not solely be executed in the cyber domain - humans often manually perform phases of a response. 
> 
> What we are attempting to define here is a standard way to share the actual high-level procedures and/or workflows (the terminology used in the cybersecurity realm is the "playbook") with which these actions are executed, not the low-level action operation itself. 
> 
> I hope that can clarify matters somewhat, and also make it more obvious why this work is not covered by any current work in STIX/TAXII/IODEF/DOTS/MILE. All of those standards revolve around a method of communicating a threat or security incident. We are seeking to communicate the response methodology for that incident.
> 
> -
> Jason Keirstead
> www.ibm.com/security <x-msg://2/www.ibm.com/security>
> 
> 
> -- 
> Cacao mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/cacao