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

Michael Richardson <mcr+ietf@sandelman.ca> Sun, 31 March 2019 01:16 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: cacao@ietfa.amsl.com
Delivered-To: cacao@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63A02120046 for <cacao@ietfa.amsl.com>; Sat, 30 Mar 2019 18:16:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RSG-Mnd69Fy for <cacao@ietfa.amsl.com>; Sat, 30 Mar 2019 18:16:50 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C5A312002E for <cacao@ietf.org>; Sat, 30 Mar 2019 18:16:50 -0700 (PDT)
Received: from dooku.sandelman.ca (unknown [209.171.88.16]) by relay.sandelman.ca (Postfix) with ESMTPS id 7A1A01F45B for <cacao@ietf.org>; Sun, 31 Mar 2019 01:16:48 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id C636423BF; Sun, 31 Mar 2019 03:16:52 +0200 (CEST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: cacao@ietf.org
X-Attribution: mcr
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Sat, 30 Mar 2019 21:16:52 -0400
Message-ID: <11776.1553995012@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cacao/LXA7SFg8Dkf5KYfM1Y2ymrfmi0k>
Subject: [Cacao] playbooks for ending-quarantines of residential IoT devices
X-BeenThere: cacao@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Collaborative Automated Course of Action Operations <cacao.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cacao>, <mailto:cacao-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cacao/>
List-Post: <mailto:cacao@ietf.org>
List-Help: <mailto:cacao-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cacao>, <mailto:cacao-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 31 Mar 2019 01:16:52 -0000

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. 

-- 
]               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    [