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

On Sat, Mar 30, 2019 at 6:16 PM Michael Richardson <mcr+ietf@sandelman.ca>
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  [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on
> rails    [
>
>
>
>
> --
> Cacao mailing list
> Cacao@ietf.org
> https://www.ietf.org/mailman/listinfo/cacao
>