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

[Bret Jordan <[e-mail]>]

 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 <[e-mail]> wrote:
> 
> 
> 
> On Sat, Mar 30, 2019 at 6:16 PM Michael Richardson <[e-mail] <mailto:[e-mail]>> 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/ <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/ <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.  
> 

[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


> 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  [ 
> ]     [e-mail] <mailto:[e-mail]>  http://www.sandelman.ca/ <http://www.sandelman.ca/>        |   ruby on rails    [ 
> 
> 
> 
> 
> -- 
> 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]
> https://www.ietf.org/mailman/listinfo/cacao