Subject: Re: [Cacao] playbooks for ending-quarantines of residential IoT devices

From: Joseph Salowey <[email-masked]>
Date: Thu, 4 Apr 2019 08:56:57 -0700

On Sat, Mar 30, 2019 at 6:16 PM Michael Richardson <[email-masked]>
wrote:

>
> I came to the CACOA BOF because I think going to BOFs is a good way to find
> out if the work is relevant to me.  I didn't think it was going to
> be... until...
>
> In the SecureHomeGateway (SHG) work at CIRALabs with MUD-based firewalling,
> we came across a proceedural problem: once we have identified a device as
> contravening the policy, and we quarantee it, then what?  I know now that
> what I'm lacking is a playbook that can be executed typical residential
> user
> (which for sexist and agist reasons seems to always be someone's
> grandmother).
>
> Feedback that the Canadian Multistakeholder effort
> https://iotsecurity2018.ca/ got was that ISPs suspected that they were
> going
> to be on the hook to take the support calls.  The SHG effort is partially
> about helping ISPs defend against being responsible for finding all the
> attack vectors.  Helping ISPs redirect the support calls seemed like a good
> thing. (Redirect to where...? Still TBD)
>
> I wrote
> https://datatracker.ietf.org/doc/draft-richardson-shg-un-quarantine/,
> with the idea of bringing this forward in the RIPE IoT WG.   I like writing
> in Markdown, and so it's on the IETF DT because RIPE has no equivalent.
>
> It's clear to me now that I'm writing a playbook!
> My playbook is clearly not in scope for CACOA since CACOA is about playbook
> technology, not playbooks themselves.
> Still part of my original goal in the document was to identify the parts
> that could be automated either through existing or developing protocols
> (INCH/MILE
> and DOTS are big on that list), or perhaps through other not-yet-developed
> protocols for things that clearly could be automated.
>
> I would welcome unicast feedback on how to make my document into a proper
> playbook.
>
> A question to the CACOA BOF is whether doing gap analysis is in scope.
> My feeling is that it is not, that it would attempt to boil oceans.
>
> Yet, if CACAO wants to be able to describe and sign operations, it behoves
> it
> to know what kind of things need to be done, with enough detail that we can
> describe the inputs to those operations.   So specifically, I'm thinking
> that
> we need to have a some kind of parametric interface to the signed snippets,
> rather like SQL ?-parameters.
>
>
[Joe] It seems to me that we will need parameters.  If you are addressing
an issue with a specific host, that host needs to be identified to the
systems or users running the playbooks.  Another example, might be "move to
quarantine VLAN".  I wouldn't expect the exact VLAN ID to be input to a
CACAO run book, but rather the component taking action would know how to
resolve the Quarantine VLAN to a VLAN ID.

I think this will have some influence on the question of scoping CACAO.

Joe

> --
> ]               Never tell me the odds!                 | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works        | network
> architect  [
> ]     [email-masked]  http://www.sandelman.ca/        |   ruby on
> rails    [
>
>
>
>
> --
> Cacao mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cacao
>

---

From: Bret Jordan <[email-masked]>
Date: Thu, 4 Apr 2019 12:19:33 -0600

Inline..

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 Apr 4, 2019, at 9:56 AM, Joseph Salowey <[email-masked]> wrote:
> 
> 
> 
> On Sat, Mar 30, 2019 at 6:16 PM Michael Richardson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> what I'm lacking is a playbook that can be executed typical residential user
> (which for sexist and agist reasons seems to always be someone's grandmother).
> 
> https://iotsecurity2018.ca/ <https://iotsecurity2018.ca/> got was that ISPs suspected that they were going
> I wrote https://datatracker.ietf..org/doc/draft-richardson-shg-un-quarantine/ <https://datatracker.ietf.org/doc/draft-richardson-shg-un-quarantine/>,
> that could be automated either through existing or developing protocols (INCH/MILE
> I would welcome unicast feedback on how to make my document into a proper playbook.
> 
> Yet, if CACAO wants to be able to describe and sign operations, it behoves it
> describe the inputs to those operations.   So specifically, I'm thinking that
> [Joe] It seems to me that we will need parameters.  If you are addressing an issue with a specific host, that host needs to be identified to the systems or users running the playbooks..  Another example, might be "move to quarantine VLAN".  I wouldn't expect the exact VLAN ID to be input to a CACAO run book, but rather the component taking action would know how to resolve the Quarantine VLAN to a VLAN ID.  
> 

[Jordan] Some playbooks that are shared across the internet, either openly and free, or behind some sort of trust group wall, will probably just say for example “Windows 10” and “Quarantine VLAN”.  But when that Playbook comes into a specific organization, they will enhance it and add extra detail / specificity.  Like “Windows 10 SP3” or “Windows System at x.x.x.x” or “Windows System Asset ID 1234”.  On the VLAN side, they may still say “Quarantine VLAN” or “Sandbox VLAN”.  They may also say “Sandbox VLAN 300”.  

Remember that Playbooks will be shared and collaborated on across the Internet, across trust groups, across business units, across enclaves, and across teams within an organization.  

Bret

> ]               Never tell me the odds!                 | ipv6 mesh networks [ 
> ]   Michael Richardson, Sandelman Software Works        | network architect  [ 
> ]     [email-masked] <mailto:[email-masked]>  http://www.sandelman.ca/ <http://www.sandelman.ca/>        |   ruby on rails    [ 
> 
> 
> 
> 
> -- 
> Cacao mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/cacao <https://www.ietf.org/mailman/listinfo/cacao>
> -- 
> Cacao mailing list
> [email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Thu, 04 Apr 2019 15:16:24 -0400

Joseph Salowey <[email-masked]> wrote:
    mcr>     Yet, if CACAO wants to be able to describe and sign operations, it
    mcr> behoves it to know what kind of things need to be done, with enough
    mcr> detail that we can describe the inputs to those operations. So
    mcr> specifically, I'm thinking that we need to have a some kind of
    mcr> parametric interface to the signed snippets, rather like SQL
    mcr> ?-parameters.

    > [Joe] It seems to me that we will need parameters. If you are
    > addressing an issue with a specific host, that host needs to be
    > identified to the systems or users running the playbooks. Another
    > example, might be "move to quarantine VLAN". I wouldn't expect the
    > exact VLAN ID to be input to a CACAO run book, but rather the component
    > taking action would know how to resolve the Quarantine VLAN to a VLAN
    > ID.

I find it credible that the playbook will know what the intended quarantine
VLAN is.  That it's not a parameter.

But, the address of the machine to move clearly needs to be mentioned in some
way.   There are quite a few addresses that could matter:
  1) IPv4 address and IPv6 address (but they can change)
  2) MAC address (but device could change it, either maliciously, or because
                  mac randomization)
  3) switch number and port number
  4) 802.1X login (if appropriate)

These seem like parameters to the playbook code.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Thu, 04 Apr 2019 15:46:05 -0400

Bret Jordan <[email-masked]> wrote:
    > [Jordan] Some playbooks that are shared across the internet, either
    > openly and free, or behind some sort of trust group wall, will probably
    > just say for example “Windows 10” and “Quarantine VLAN”. But when that
    > Playbook comes into a specific organization, they will enhance it and
    > add extra detail / specificity. Like “Windows 10 SP3” or “Windows
    > System at x.x.x.x” or “Windows System Asset ID 1234”. On the VLAN side,
    > they may still say “Quarantine VLAN” or “Sandbox VLAN”. They may also
    > say “Sandbox VLAN 300”.

Yes, so you seem to be strongly agreeing that they have to be parameterized
From a number of different contexts.  Some context are specific to the
incident, some are specific to the asset type, some are specific to the
"building", and some are specific to the enterprise.

So again, I come back to Jypyter Notebooks as a model.

---

From: "Jason Keirstead" <[email-masked]>
Date: Thu, 4 Apr 2019 15:57:36 -0400

The current understanding is definitely that playbooks and playbook steps 
will both require paramters. You can see that in the current introduction 
draft at https://tools.ietf.org/html/draft-jordan-cacao-introduction-00

Example:

Project-Step:

   o  Id:3

   o  Type: Machine

      *  Operation: Vlan-Move

      *  Variable: "HostVLANID ="infected-host.vlan

      *  Target: $$infected-host

      *  Destination: Quarantine VLAN ID

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

"Things may come to those who wait, but only the things left by those who 
hustle." - Unknown 

From:   Michael Richardson <[email-masked]>
To:     Joseph Salowey <[email-masked]>
Cc:     [email-masked]
Date:   04/04/2019 04:16 PM
Subject:        Re: [Cacao] playbooks for ending-quarantines of 
residential IoT devices
Sent by:        "Cacao" <[email-masked]>

Joseph Salowey <[email-masked]> wrote:
    mcr>     Yet, if CACAO wants to be able to describe and sign 
operations, it
    mcr> behoves it to know what kind of things need to be done, with 
enough
    mcr> detail that we can describe the inputs to those operations. So
    mcr> specifically, I'm thinking that we need to have a some kind of
    mcr> parametric interface to the signed snippets, rather like SQL
    mcr> ?-parameters.

    > taking action would know how to resolve the Quarantine VLAN to a 
VLAN

I find it credible that the playbook will know what the intended 
quarantine
VLAN is.  That it's not a parameter.

But, the address of the machine to move clearly needs to be mentioned in 
some
way.   There are quite a few addresses that could matter:
  1) IPv4 address and IPv6 address (but they can change)
  2) MAC address (but device could change it, either maliciously, or 
because
                  mac randomization)
  3) switch number and port number
  4) 802.1X login (if appropriate)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-
[attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM] -- 
Cacao mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cacao

---

From: Michael Richardson <[email-masked]>
Date: Thu, 04 Apr 2019 15:47:45 -0400

Joe and Jordan have commented on the parameterization part of my question.

> I wrote
>   https://datatracker.ietf..org/doc/draft-richardson-shg-un-quarantine/,
>
> with the idea of bringing this forward in the RIPE IoT WG.

..
> It's clear to me now that I'm writing a playbook!

Does anyone agree or disagree with me?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Bret Jordan <[email-masked]>
Date: Thu, 4 Apr 2019 17:20:10 -0600

Yes, this is a playbook.  Here are some examples of playbooks from the IACD effort.  https://www.iacdautomate.org/playbook-and-workflow-examples <https://www.iacdautomate.org/playbook-and-workflow-examples>

Thanks,
Bret

> On Apr 4, 2019, at 1:47 PM, Michael Richardson <[email-masked]> wrote:
> 
> ...