Subject: [saag] draft-moore-iot-bcp-00 -- Best Current Practices for Securing IoT Devices

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 7 Nov 2016 21:43:20 +0100

I would like to provide a little bit of background why Keith & Richard
have put this document together so short notice.

Keith and I had a discussion about what could be done regarding these
DDoS attacks conducted with the help of IoT devices. I was skeptical
about the value of writing a document that offers guidelines since one
of the core problem with many IoT related security vulnerabilities is
that those who develop IoT products simply do not read any security
recommendations nor do they re-use any existing security techniques
either (at least it seems so).

Hence, my initial reaction was that they are probably not going to read
this newly written document either.

It is, however, clear that various SDOs will come up with the idea to
write some guidelines since these security problems in the IoT space
have gone on for a while now*.

At ARM our approach is to give developers an operating system (mbed OS
in our case) that comes with an embedded TLS stack and even with a
device management solution (based on LWM2M). Developers do not need to
worry about the details of networking protocols or security mechanisms.

Other companies and even universities have a very similar strategy (just
replace the name of the OS).

Of course, there will still be developers and companies who strongly
believe that they should roll out their own security design.

For those folks, someone has to write some best current practice
guidelines. To write such guidelines I believe there are various
preconditions:

* First, the group writing such guidelines should actually know
something about the best current practices. They need to understand this
part of the industry. Ideally, we want something that is still practical.

* Second, it needs to be a group with a lot of experience in the
Internet security space since we are talking about **Internet** of Things.

* Third, enough folks need to review the work since otherwise the
outcome is of limited value.

As you can imagine that our thinking was that the IETF could be such a
venue where lots of the security experts are already and where the
barrier for participation is low. There is still room for improvement
since we do not have many of the silicon vendors in the IETF.

Will it make a difference in terms of practical IoT security? I don't
know since there are still these nasty incentive problems (see a recent
article written by Bruce Schneier on this topic:
https://www.schneier.com/blog/archives/2016/10/security_econom_1.html).

Ciao
Hannes

*: Various people have pointed to other guideline documents (on this
mailing list and elsewhere). I was aware of some but certainly not all
of them. Checking for the overlap is certainly helpful. If they all
offer the same recommendations we can almost speak about industry-wide
consensus (at least on paper).

---

From: Ronald del Rosario <[email-masked]>
Date: Mon, 7 Nov 2016 20:50:01 +0000

"Checking for the overlap is certainly helpful. If they all offer the same recommendations we can almost speak about industry-wide consensus (at least on paper)."

Agree.
Ron

> On Nov 7, 2016, at 12:43 PM, Hannes Tschofenig <[email-masked]> wrote:
>

________________________________

CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential information of Five9 and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Five9 and/or its affiliated entities.

Disclaimer

The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more visit the Mimecast website.

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 8 Nov 2016 09:59:04 +0000

Hannes Tschofenig <[email-masked]> writes:

>I was skeptical about the value of writing a document that offers guidelines
>since one of the core problem with many IoT related security vulnerabilities
>is that those who develop IoT products simply do not read any security
>recommendations nor do they re-use any existing security techniques either
>(at least it seems so).

One thing about most (close to all?) of the IoT vulns that have come up is
that they're hack-like-it's-199x issues (I've heard that term at a number of
IoT-hacking talks, the x varies from about 5 to 9), vulns that were common in
the non-IoT world fifteen to twenty years ago.  So if you were lazy you could
just take any standard security development text and use sed to replace "Unix"
with "IoT".  Hey, it's worth a try, it might get a bit more attention from IoT
devs once the magic keyword is specifically mentioned...

OTOH I think you're right in your observation, the people I know who do IoT
(well, SCADA, which is somewhat different) development take security seriously
and often use multiple sources of secure-development practices, as well as
just safety/reliability-conscious practices in general, because when your
product has a lifetime of 10-15 years you can't cut corners at the development
stage and you can't roll out a new version once it's deployed.  OTOH the
people doing IoT barely care about security, it's just "get it apparently
working and out the door as quickly and cheaply as possible".

Peter.