Re: [OPSAWG] putting quarantined IoT devices behind a captive portal

[Michael Richardson <[e-mail]>]

{my appologies for still getting captive-portal vs captive-portals@ wrong}

John Romkey <[e-mail]> wrote:
    >> Eliot Lear <[e-mail]> wrote:
    >>
    >>>> to retrieve a JSON object telling it that it is captive. At which point, it
    >>>> can flash a LED, or attempt a firmware upgrade, or maybe just reboot if a
    >>>> timer goes off.  (%)
    >>
    >>> You are suggesting that a device self-remediate.  Some devices may be
    >>> able to eventually do that, but I have my doubts.  Were I a hacker, I
    >>> would have the device pretend to do just that.  And so this ties
    >>> somewhat to RATS.  I think a MUD extension might be able to help in as
    >>> much as one could imagine a “remediation” recommendation.
    >>
    >> Yes, so a full attack on the IoT device would do what you describe.
    >> A partial attack might miss messing this.  A reboot might clear out the
    >> malware, or might mitigate it enough (such as going to boot firmware) that
    >> would permit new firmware to be loaded.
    >>
    >> Yes, getting completely out of the quarantine would require either
    >> attestation or human intervention.  But, if the device now has good firmware,
    >> it would be able to send the "please unquarantine me" signal.

    > I believe strongly that the only safe thing you can do with a device
    > that’s been in any way compromised is completely isolate it.It
    > shouldn’t be able to send an “unquarantine” signal. You shouldn’t even
    > try to talk to it.

That's a reasonable view.
The question is: what next?
                   draft-richardson-shg-un-quarantine-00
tries to discuss this.

    > Let the firewall which is implementing MUD notify the user about the
    > problem. Let the device’s app or cloud services notify the user that
    > the device is offline. Possibly in a later evolution of MUD the
    > firewall might have a way to notify the device’s cloud service, but I
    > wouldn’t hamstring the initial version of MUD with an attempt to do
    > that.

I fully expect any notifications out should be done by the firewall.
There are two issues I'm trying to address:
  1) there will be false positives from use of MUD.  Manufacturers will
     screw up, DNS mappings will be updated out of sync with firmware, etc.
     If it is too painful to diagnose and fix, then MUD will get disabled by
     operators (ISPs, who will get the call), or by end users.

  2) not every user of a device will get the notifications.
     So devices with displays (think: thermostats, refridgerators, SIP phones,
     TV sets, etc.) whether they have real malware on them, or false
     positives should be able to indicate that they are offline.
     This matters a lot if you are trying to dial 911 on a broken phone,
     and you aren't the person with the app that gets the notifications
     from the firewall.

Putting them behind the captive-portal API when quarantined lets them get
exactly the kind of information they want.  It also helps them when they
turned on where there really is a captive-portal.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-