<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">The definition of "faulty" is,
      fortunately, "settled law", probably dating back as far as the era
      of Hanseatic League (a particular interest of mine: the league was
      the invention of a packet international-network-thingie where the
      packets were sailing ships). <br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">In Canada, the courts would simply
      follow the legislation and precedent, and the only way you could
      get off is by trying to interpret the caselaw to say you were
      different. <br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">For an example of the difficulty of
      weaseling out, see [6-8] in
<a class="moz-txt-link-freetext" href="https://www.canlii.org/en/nl/nlca/doc/1995/1995canlii9847/1995canlii9847.html?searchUrlHash=AAAAAQAOZmF1bHR5IHByb2R1Y3QAAAAAAQ&resultIndex=2">https://www.canlii.org/en/nl/nlca/doc/1995/1995canlii9847/1995canlii9847.html?searchUrlHash=AAAAAQAOZmF1bHR5IHByb2R1Y3QAAAAAAQ&resultIndex=2</a></div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">As a more relevant example of a
      decision, I'd expect that an access control system on a router
      with a hard-coded back door would be found "not suitable for the
      purpose sold", and expose the authors to an order for replacement.
      Even in current Canadian law, that particular example (re Cisco
      routers) would put them on the wrong side of the definition of
      fraud, and subject to being ordered to make it right. <br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">Individual countries will vary in the
      details: in the US, different States could even differ, but in
      broad strokes</div>
    <ul>
      <li>it must be suitable for the purpose sold, at any age</li>
      <li>it must not fail before it reaches a specified age</li>
      <li>it may well have undiscovered faults, but the vendor must make
        them right once found, subject to age<br>
      </li>
    </ul>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">--dave</div>
    <div class="moz-cite-prefix">Amusingly, I also found a Canadian case
      about concealing a backdoor password, at [204] in
<a class="moz-txt-link-freetext" href="https://www.canlii.org/en/on/onsc/doc/2009/2009canlii64185/2009canlii64185.html?searchUrlHash=AAAAAQAIYmFja2Rvb3IAAAAAAQ&resultIndex=9">https://www.canlii.org/en/on/onsc/doc/2009/2009canlii64185/2009canlii64185.html?searchUrlHash=AAAAAQAIYmFja2Rvb3IAAAAAAQ&resultIndex=9</a><br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">On 2019-01-19 9:16 a.m., Dave Taht
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:87tvi4ohq4.fsf@taht.net">
      <pre class="moz-quote-pre" wrap="">
There should probably be a list for political issues somewhere.

I am liking various proposals for improving device security like this
and the german router thing (<a class="moz-txt-link-freetext" href="https://www.ccc.de/de/updates/2018/risikorouter">https://www.ccc.de/de/updates/2018/risikorouter</a>
) but missing from all these requirements is

"the right to repair"


" The code also asks manufacturers to disclose a minimum timeline for
 software updates and makes provisions for devices or components that
 cannot be updated through software, noting that the manufacturer can
 replace them—in fact, under U.K. law they must repair or replace faulty
 products for 6 years."

oh, I so wish we had that in the US. But what qualifies as faulty?




David Collier-Brown <a class="moz-txt-link-rfc2396E" href="mailto:davec-b@rogers.com"><davec-b@rogers.com></a> writes:

</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">I'm pleased to have seen this discussion on lawfare,
<a class="moz-txt-link-freetext" href="https://www.lawfareblog.com/what-make-uks-new-code-practice-internet-things-security">https://www.lawfareblog.com/what-make-uks-new-code-practice-internet-things-security</a>

Instead of proposing frozen, unmaintainable devices, they expect
updates, and note that a major UK retailer pulled an insecure product
because it couldn't be updated.

--dave

-------- Forwarded Message -------- 

 Subject:  What to Make of the U.K.’s New Code of Practice on        
           Internet-of-Things Security                               
 Date:     Tue, 15 Jan 2019 10:26:40 -0500                           
 From:     Jack Watson <>, Beau Woods <>                             

What to Make of the U.K.’s New Code of Practice on Internet-of-Things
Security

Across the globe, the rapid pace of technology development has made it
difficult to govern emerging tech effectively. Policymakers struggle
with several primary issues, including knowledge of the subject
matter, the potential impact on the pace of innovation, and the rapid
rate of adoption. The United Kingdom’s “Secure by Design” program
intends to meet these challenges, as well as take steps to position
the country as “best place in the world to do digital business.” As
Brexit continues, and Britain’s finance sector looks to jump ship,
such a goal is as timely as it is necessary. At its core, the program
will create powerful tools for policymakers, industry, consumers,
retailers, and others. The final U.K. “Code of Practice” for
internet-of-things security released on Oct. 14, 2018 by the
Department for Digital, Culture, Media and Sport in conjunction with
GCHQ’s National Cyber Security Centre offers one of the clearest
policy positions articulated yet by any national government. It sets
out a technically literate policy that will drive manufacturers to
innovate more efficient ways to protect internet-connected consumer
devices, through market and regulatory incentives.

By its own terms, the code of practice—and, more broadly, the Secure
by Design program—seeks to “support all parties involved in the
development, manufacturing and retail of consumer [internet-of-things
devices].” To support this goal, the release is accompanied by
awareness and educational documents, technical standards guidance, and
an implementation plan, all of which show the U.K.’s commitment to a
leadership role in securing the internet of things. The fact that the
code is translated into eight languages, including Mandarin, Korean,
French, German and Japanese, is crucial in showing that the U.K.
intends to be a global trendsetter, but it also reflects the global
nature of the markets, supply chains and security threats, as well as
resilience and confidence in consumer internet-of-things devices. A
common or coordinated international approach increases adoption speed,
reduces transactional friction, and increases consumer confidence
across global markets.

Finally, the implementation plan for the Secure by Design program
demonstrates GCHQ and DCMS know well the current cybersecurity climate
writ large. Like the United States, the U.K. has identified a
significant shortage of trained cyber security professionals. This,
compounded by the rapid development of internet-of-things devices,
rollout of 5G, and other technical advances, means there is a lack of
capacity to protect internet-of-things products and services from
increasingly complex cybersecurity dangers. The U.K. wants to see the
code ensure that devices flooding into homes and companies are
equipped with necessary capabilities for owners to protect
themselves—through voluntary, market-driven measures ideally, though
if that fails they will “make these guidelines compulsory through
law.” Consumer awareness, education, and labelling will empower buyers
to make well-informed decisions and give citizens knowledge to take
advantage of these capabilities. Finally, NCSC-sponsored CyberFirst
summer courses will train the next generation of technology
professionals to defend against security threats to internet-of-things
devices.

What the Code of Practice Is—And What it Isn’t

Many early criticisms of the code are premised on a superficial
understanding of the program and emerging solutions. At its core, the
code details several positive, practical steps for device manufactures
across the supply chain and product lifecycle. For instance, botnets
like Mirai and others gain their destructive power by taking over
large numbers of internet-connected computers or devices. Steps that
the code recommends, like prohibiting default passwords and keeping
software up to date, limit the speed and scale of a botnet’s growth,
thus diminishing their ability to do harm. The code guides
manufacturers away from common patterns of security failure that
create openings for many types of threats, including botnets, and
towards those that tend to be more successful. We outline the top
three recommendations, as well as a few others worthy of note. (The
paragraph numbers used below are from the document itself and do not
necessarily reflect our ranking).

1. No default passwords. Passwords are meant to restrict access to
systems only to those who know them. Default passwords, like “admin”
or “password,” ensure anyone can know them, thus defeating their
utility when defaults are published, well-known, or easily guessable.
Many devices already ship with unique passwords, requiring a change on
first use. Default and common passwords on internet-facing interfaces
(such as Telnet and SSH) allow network worms like Mirai to propagate
very quickly, though improving security of other interfaces also
improves “security by default” for internet-of-things systems.

2. Implement a vulnerability disclosure policy. As more of the
“things” around us depend on software and become exposed to the
internet, more adversaries will take advantage of their flaws. A
coordinated vulnerability disclosure policy invites allies, acting in
good faith, to report these flaws to the manufacturer so they can be
fixed. The device maker has an obligation to acknowledge and address
issues in a timely manner. (The leading international standard for
coordinated vulnerability disclosure, ISO 29147, calls for
acknowledgement in 7 days. And the Code’s additional explanatory notes
section makes a case for manufacturers to address the issue in less
than 90 days.)

3. Keep software updated. Software updates can address bugs and
vulnerabilities once manufacturers know about them. Most
internet-of-things devices have the capability for software updates
today, though laggards still exist. For instance, a major U.K.
retailer removed GPS watches made for children over concerns that they
were insecure and could not be updated. The code goes further and asks
manufacturers to preserve basic functions during an update and that
the update process be secured. The code also asks manufacturers to
disclose a minimum timeline for software updates and makes provisions
for devices or components that cannot be updated through software,
noting that the manufacturer can replace them—in fact, under U.K. law
they must repair or replace faulty products for 6 years.

6. Minimize exposed attack surfaces. The code aims to eliminate
exposure and attack surface where the value to the consumer is
outweighed by the risk associated with the vulnerability. Many devices
already minimize feature sets due to resource constraints. With better
hardware capabilities at lower cost, the trade offs for increasing the
number of exposed services to the internet or taking a default-enable
approach to elective services.

9. Make systems resilient to outages. Boosting resilience to outages
will be increasingly important in coming years, as internet-of-things
infrastructure changes, such as migrating to a new domain, end of
life, going out of business, and other circumstances impossible to
predict. Mature design processes include failure-mode analysis to
guide how the device will perform during different environmental or
system failures. This can mean the device notifies the person it’s in
some kind of degraded mode or that mechanical systems replace
software-driven ones. My Amazon Echo tells me when my internet
connection (or its servers) are out, and internet-connected locks
usually have mechanical keys as backups when connectivity or power are
unavailable.

10. Monitor system telemetry data. Mobile phones and apps send masses
of telemetry information back to their developers, who can analyze and
improve the products as well as look for security or safety anomalies.
Microsoft, Apple and Google detect emerging threats against their
products and issue updates to address them, while doing so in a
privacy-neutral way.

Threats, vulnerabilities and industry practices change over time. The
code of practice is a snapshot in time, meant to be goal- or
outcome-based rather than prescriptive, so organizations can adapt as
necessary while still hitting these objectives. It isn’t meant to
supplant technical standards, but instead the U.K. government has
mapped the code to technical standards for ease of implementation.

Securing systems may increase cost of doing business, and eventually
the price of consumer goods. On the other hand, buyers and owners
already bear costs for insecurity. Widescale harm from events like
WannaCry and NotPetya greatly escalate those costs, including harm to
third-parties through no fault of their own. In conversation, U.S. and
U.K. retailers have mentioned costs associated with employees
educating consumers and increased rates of return for security issues.

Manufacturers are in the best position to reduce systemic cost and
risk, as their available options are much greater than those of
owners. Shifting responsibility and costs across the supply chain has
been difficult in the past, without strong financial or regulatory
incentives. The U.K. intends to drive these changes through labeling,
consumer awareness, (if it must) regulation, and (I strongly suspect)
by requiring devices they buy to adhere to the code.

Crucially, the Department of Digital, Culture, Media and Sport (DCMS)
has made it clear that they do not intend to reinvent the wheel. An
accompanying document maps the code against over 100 documents from
nearly 50 organizations, representing “published standards,
recommendations and guidance on [internet-of-things] security and
privacy from around the world.” This is, first and foremost, an effort
grounded in a practical understanding of the problem, the effective
approaches, and what has failed in the past. DCMS know that
manufacturers “are already implementing a range of standards,” and the
mapping document shows how those efforts fit with the code.

While most of the elements of the code are well understood, some of
the objectives it lays out are only beginning to enter common
practice. Though they have long been technically possible, these
innovative approaches have only recently been needed due to increases
in attacks against internet-of-things devices and buyer pressure for
higher security, largely among retailers and corporate buyers.
Publishing the code will serve to stimulate innovation toward better
capabilities in the hands of more manufacturers, buyers, and owners. 

Most device makers should have no problem meeting the objectives laid
out in the Code within the next couple of years. Several of the
world’s largest manufacturers have already committed to a similar
high-level doctrine called the “Charter of Trust.” The manufacturers
most likely to be impacted are those that buy very low cost, low
quality devices from China or elsewhere and repackage them under a
variety of names. These brands tend to exit the market after only a
year or two, replaced by other brands selling nearly identical-looking
products from the same factories, making it hard to enforce
accountability for support. They live on, connected to the internet,
vulnerable and exposed to global accidents and adversaries. This kind
of market confusion drives out better products leaving buyers with low
choice and low quality—a market for lemons.

Yet the code is not a cure-all for every internet-of-things security
concern. First, it only applies to home, or consumer-grade
internet-of-things devices. Yet similar technologies—and their
associated security risks—have been adopted across automotive,
aviation, maritime, energy, and other sectors. Each of these has
distinct ecosystems, challenges, and leverage points to evaluate if
the U.K. wants to apply the code in those industries. Second, the
unimplemented policies cannot make change, and the Secure by Design
program is light on how the government plans to achieve market
adoption. This will inevitably take resources, focus, and time that
must be allocated amid a turbulent national and global political
landscape. Third, global supply chains and markets demand
international cooperation and collaboration. While policymakers have
shied away from corralling rapidly advancing technologies, such as
internet-of-things devices and 5G, they seem more willing now than
ever before in key regions like North America, Europe, and China.

***

The code is a positive step forward for consumer IoT security and has
positive traction. HP and Centrica have already formally signed on to
the code, and others are likely to follow, given the resources the
U.K. government seems to be putting behind adoption and enforcement.
DCMS contend that at least eight of the code’s guidelines are already
legally enforceable through the U.K. Data Protection Act and GDPR.
Germany and the EU have begun adopting compatible (though much less
effective) policies, and in the United States, California’s
internet-of-things bill (SB-327) requires manufacturers to equip
internet connected devices with “reasonable” and “appropriate”
security features. (In the deliberations captured in the bill’s
history, the legislature emphasized that security must be both
reasonable and appropriate to the device, and that it’s up to the
device makers to determine that. The code could serve as a good model
for meeting this standard of care for consumer internet-of-things
devices.) Globally, policymakers are reaching for clear guidelines and
implementable solutions, coupled with adverse market pressure for
companies that come up short.

Most of the internet-of-things devices that ever exist will be
designed in the future. Policies like the U.K. Code of Practice are
meant to be forward-looking, driving innovators toward better
products. Many of the objectives it lays out are commonplace among
moderate- and high-quality devices, even those at low price points.
But the Code will raise the bar for all manufacturers and reduce
susceptibility to cyber security, safety, and privacy issues. And it
will give retailers and consumers a common measuring stick for
comparing devices.


_______________________________________________
Bloat mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bloat@lists.bufferbloat.net">Bloat@lists.bufferbloat.net</a>
<a class="moz-txt-link-freetext" href="https://lists.bufferbloat.net/listinfo/bloat">https://lists.bufferbloat.net/listinfo/bloat</a>
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
</pre>
    </blockquote>
    <p><br>
    </p>
    <pre class="moz-signature" cols="72">-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
<a class="moz-txt-link-abbreviated" href="mailto:davecb@spamcop.net">davecb@spamcop.net</a>           |                      -- Mark Twain
</pre>
  </body>
</html>