[Mud] a place MUD would have helped --- US security cameras

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 30 July 2019 17:38 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: mud@ietfa.amsl.com
Delivered-To: mud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3B3120299 for <mud@ietfa.amsl.com>; Tue, 30 Jul 2019 10:38:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 sr3I8B3VZleI for <mud@ietfa.amsl.com>; Tue, 30 Jul 2019 10:38:31 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76C551201CC for <mud@ietf.org>; Tue, 30 Jul 2019 10:38:30 -0700 (PDT)
Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id CFB173808A; Tue, 30 Jul 2019 13:38:04 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 47160980; Tue, 30 Jul 2019 13:38:29 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: mud@ietf.org, canada-iot-security-discussion-request@elists.isoc.org
X-Attribution: mcr
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Tue, 30 Jul 2019 13:38:29 -0400
Message-ID: <26066.1564508309@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mud/k5j81RbmtxYtiG5hHMnUkmqfuBA>
Subject: [Mud] a place MUD would have helped --- US security cameras
X-BeenThere: mud@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of Manufacturer Ussage Descriptions <mud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mud>, <mailto:mud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mud/>
List-Post: <mailto:mud@ietf.org>
List-Help: <mailto:mud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mud>, <mailto:mud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Jul 2019 17:38:34 -0000

btw: I don't think it's actually fair to single-out cameras from a single
     country. I haven't read the Act (nor am I likely to), but it imagine
     if it had used positive language like, "the country of origin and
     the manufacturing firm MUST be easily identifiable on packaging
     and via firmware provided information, such as RFC8520"

{I am taking everything Bloomberg writes with a medium sized grain of salt,
after the spy chip story.}

https://www.bloomberg.com/news/articles/2019-07-10/banned-chinese-security-cameras-are-almost-impossible-to-remove says:

   But thousands of the devices are still in place and chances are most won’t
   be removed before the Aug. 13 deadline. A complex web of supply chain
   logistics and licensing agreements make it almost impossible to know
   whether a security camera is actually made in China or contains components
   that would violate U.S. rules.  

   The National Defense Authorization Act, or NDAA, which outlines the budget
   and spending for the Defense Department each year, included an amendment
   for fiscal 2019 that would ensure federal agencies do not purchase
   Chinese-made surveillance cameras. The amendment singles out Zhejiang
   Dahua Technology Co. and Hangzhou Hikvision Digital Technology Co., both
   of which have raised security concerns with the U.S. government and
   surveillance industry.

   ...

I wrote on the IoTSF basecamp in the thread about this:

   It's amazing, but hardly surprising.  The lack of comprehension of among
   the (US) supply chain of the risks of relabelling has been going on for
   decades.  Swapping internal components (even moving to completely
   different CPUs) without changing the label on the outside is something
   that many US based suppliers of equipment including Cisco/Linksys, Nortel,
   Polycom, Belkin, etc. have done repeatedly to the frustration of their
   customers who want to do simple things like just upgrade firmware
   regularly. 

   If Honeywell doesn't know what they sold, then they can hardly be expected
   to comply to needs to issue CVEs, etc. which suggests that both the customer
   and the supplier had no plans at all to ever think about firmware updates to the
   devices.  Were I in charge, I'd be firing/demoting people in the *government*
   who did this procurement, and not just cancelling contracts but going for
   breach of contract.   

  Let me suggest some ways in which this could have been prevented. (You'll
  hardly be surprised at my self-promotion, but I'm working in this area for
  a reason...)  Two key and usefully intertwined technologies: had RFC8520
  (MUD) been required for the cameras, then the MUD URL presented by the
  *firmware* might have sliced through all relabelling BS, and would
  identified the product relatively well.

  If a proper onboarding system had been used that transferred ownership
  control to the legal owner, then that could   have resulted in a clear
  IDevID reference to the manufacturer, and through the onboarding process, an 
  actual inventory of devices.  The "BRSKI"
  (draft-ietf-anima-bootstrapping-keyinfra) system that I'm a key author of 
  is one such system; there were two talks at last year's IoTSF on BRSKI.
  BRSKI is one of the better ways to pass the MUD URL on.   

  Firmware attestation is also important, not because it detects malicious
  firmware like was shipped by Dahua (honestly, how is that not a death
  sentence for the company?) , but because it forces the manufacturer of the
  firmware to identify itself. 

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