Subject: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Securing Internet of Things (IoT) Devices)

From: Keith Moore <[email-masked]>
Date: Fri, 4 Nov 2016 21:25:59 -0400

Stephen Farrell suggested I bring this draft to your attention. This was 
a rush job as the authors just started talking about this last Friday, 
but it was written in response to recent DDoS attacks that utilized 
easily-compromised IoT devices.   I'm sure there are missing pieces 
(I've identified a few since -00) and sections that could be stated 
better (like the title of section 2.3.2), but hopefully this is a useful 
start.

https://datatracker.ietf.org/doc/draft-moore-iot-security-bcp/

Keith

---

From: Natasha Rooney <[email-masked]>
Date: Mon, 7 Nov 2016 10:41:52 +0000

Hi Keith,

The Connected Living team here at GSMA recently published the IOT Security Guidelines (including a self-assessment scheme) for the same purpose as your draft but with a wider focus (mobile operator networks, service providers and applications). The guidelines may provide some input to the draft.

http://www.gsma.com/connectedliving/future-iot-networks/iot-security-guidelines/

Thanks!

Natasha

On 5 Nov 2016, at 01:25, Keith Moore <[email-masked]<mailto:[email-masked]>> wrote:

Stephen Farrell suggested I bring this draft to your attention. This was a rush job as the authors just started talking about this last Friday, but it was written in response to recent DDoS attacks that utilized easily-compromised IoT devices.   I'm sure there are missing pieces (I've identified a few since -00) and sections that could be stated better (like the title of section 2.3.2), but hopefully this is a useful start.

Keith

_______________________________________________
saag mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/saag

This email and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this email or call +44 207 356 0600 and highlight the error.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 7 Nov 2016 13:57:56 +0100

Hi Natasha,

thanks for pointing us to this GSMA effort.

Could you provide a little bit of feedback on who wrote these documents?

Ciao
Hannes

On 11/07/2016 11:41 AM, Natasha Rooney wrote:
> Hi Keith,
> 
> The Connected Living team here at GSMA recently published the IOT
> Security Guidelines (including a self-assessment scheme) for the same
> purpose as your draft but with a wider focus (mobile operator networks,
> service providers and applications). The guidelines may provide some
> input to the draft.
> 
>> On 5 Nov 2016, at 01:25, Keith Moore <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> Stephen Farrell suggested I bring this draft to your attention. This
>> was a rush job as the authors just started talking about this last
>> Friday, but it was written in response to recent DDoS attacks that
>> utilized easily-compromised IoT devices.   I'm sure there are missing
>> pieces (I've identified a few since -00) and sections that could be
>> stated better (like the title of section 2.3.2), but hopefully this is
>> a useful start.
>>
> This email and its attachments are intended for the above named only and
> may be confidential. If they have come to you in error you must take no
> action based on them, nor must you copy or show them to anyone; please
> reply to this email or call +44 207 356 0600 and highlight the error.
> 
> 
>

---

From: Natasha Rooney <[email-masked]>
Date: Mon, 7 Nov 2016 13:41:38 +0000

Hey Hannes!

The Connected Living team here at GSMA wrote them. If you wish to send in suggestions let me know off-list, I’ll connect you with the right person.

Natasha

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

Hi Natasha,

Ciao
Hannes

Thanks!

Natasha

Keith

_______________________________________________
saag mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/saag

---

From: Ira McDonald <[email-masked]>
Date: Mon, 7 Nov 2016 10:04:38 -0500

Hi Keith,

FWIW - link to the recent Trusted Computing Group's "Guidance for
Securing IoT using TCG Technology"

http://www.trustedcomputinggroup.org/wp-content/uploads/TCG_Guidance_for_Securing_IoT_1_0r21.pdf

The use cases are potentially of general interest.

Disclaimer - I was a contributor to this document, but I don't endorse
the narrow TCG-specific solutions focus.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
Jan-April: 579 Park Place  Saline, MI  48176  734-944-0094
May-Dec: PO Box 221  Grand Marais, MI 49839  906-494-2434

On Fri, Nov 4, 2016 at 9:25 PM, Keith Moore <[email-masked]>
wrote:

> Stephen Farrell suggested I bring this draft to your attention. This was a
> rush job as the authors just started talking about this last Friday, but it
> was written in response to recent DDoS attacks that utilized
> easily-compromised IoT devices.   I'm sure there are missing pieces (I've
> identified a few since -00) and sections that could be stated better (like
> the title of section 2.3.2), but hopefully this is a useful start.
>

---

From: Ronald del Rosario <[email-masked]>
Date: Mon, 7 Nov 2016 17:31:25 +0000

Hi Keith,

The Cloud Security Alliance (CSA) – IoT Working Group also published a similar document October 2016 titled “Future Proofing the Connected World: 13 Steps to Developing Secure IoT Products”

https://cloudsecurityalliance.org/download/future-proofing-the-connected-world/

Disclaimer: I am a member of the CSA IoT Working Group but not a contributor on this document.

Thanks,
Ron

From: saag <[email-masked]> on behalf of Ira McDonald <[email-masked]>
Date: Monday, November 7, 2016 at 7:04 AM
To: Keith Moore <[email-masked]>, Ira McDonald <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Securing Internet of Things (IoT) Devices)

Hi Keith,

mailto: [email-masked]<mailto:[email-masked]>

On Fri, Nov 4, 2016 at 9:25 PM, Keith Moore <[email-masked]<mailto:[email-masked]>> wrote:
Stephen Farrell suggested I bring this draft to your attention. This was a rush job as the authors just started talking about this last Friday, but it was written in response to recent DDoS attacks that utilized easily-compromised IoT devices.   I'm sure there are missing pieces (I've identified a few since -00) and sections that could be stated better (like the title of section 2.3.2), but hopefully this is a useful start.

Keith

________________________________

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: Loganaden Velvindron <[email-masked]>
Date: Tue, 8 Nov 2016 11:42:54 +0400

> https://datatracker.ietf.org/doc/draft-moore-iot-security-bcp/
[Speaking for myself]

That's a great start.

Can you please consider adding section 2.6.3. Sandboxing techniques
Device firmware SHOULD be designed to restrict processes attack surface
by isolating them in sandboxing, in addition to privilege minization. In
case of compromise, the attack surface is significantly reduced,
particularly in the case of privilege minimization.

[I'm thinking about OpenSSH and Linux seccomp-bpf sandbox, and also
techniques like OpenBSD's pledge]

---

From: Ari Keränen <[email-masked]>
Date: Tue, 8 Nov 2016 16:43:45 +0200

Hi,

Also at the Thing-to-Thing Research Group we have a draft about security 
considerations for IoT:
https://tools.ietf.org/html/draft-irtf-t2trg-iot-seccons

Cheers,
Ari

---

From: Watson Ladd <[email-masked]>
Date: Tue, 8 Nov 2016 07:02:56 -0800

> techniques like OpenBSD's pledge]

Does OS sandboxing actually work?

Real attackers attack. That means they have carefully studied the
system call interface of operating systems to find bugs, which they
can use to escape from running arbitrary code to violating all
security properties. They don't break the sandbox layer but exploit
the kernel instead.

ASLR, N^X, CFG, and memory safety stop attacks. (That's not MMU,
that's using a memory safe language) Sandboxing has limited
effectiveness, and we should recommend memory safety as the easiest
way to prevent RCE.

I'm also disappointed to see no mention of web interface security.

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 8 Nov 2016 16:10:04 +0100

We probably have do a bit of document scoping. Many embedded devices do
not run Linux since they have no MMU. I would like to have guidelines
that also consider those ~50 billion of currently deployed devices as well.

---

From: "Garcia Morchon O, Oscar" <[email-masked]>
Date: Tue, 8 Nov 2016 16:03:18 +0000

Hi Ari, Keith,

indeed, the purpose is similar of the draft in the T2TRG is similar. It is clear is that having a document in which we describe which aspects should be considered is very relevant.

We are in the process of further updating our draft --  comments are welcome.

Regards, Oscar.

-----Original Message-----
From: saag [mailto:[email-masked]] On Behalf Of Ari Keränen
Sent: Tuesday, November 08, 2016 9:44 AM
To: Keith Moore; [email-masked]
Subject: Re: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Securing Internet of Things (IoT) Devices)

Hi,

Also at the Thing-to-Thing Research Group we have a draft about security considerations for IoT:
https://tools.ietf.org/html/draft-irtf-t2trg-iot-seccons

Cheers,
Ari

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Adam Montville <[email-masked]>
Date: Tue, 08 Nov 2016 16:23:55 +0000

Would it be worthwhile to add this to the saag agenda, or is there
otherwise some session for discussing the plethora of IoT security related
material?

On Tue, Nov 8, 2016 at 10:04 AM Garcia Morchon O, Oscar <
[email-masked]> wrote:

> Hi Ari, Keith,
>
> indeed, the purpose is similar of the draft in the T2TRG is similar. It is
> clear is that having a document in which we describe which aspects should
> be considered is very relevant.
>
> Subject: Re: [saag] draft-moore-iot-bcp-00 (Best Current Practices for
> Securing Internet of Things (IoT) Devices)
>
> Hi,
>
> The information contained in this message may be confidential and legally
> protected under applicable law. The message is intended solely for the
> addressee(s). If you are not the intended recipient, you are hereby
> notified that any use, forwarding, dissemination, or reproduction of this
> message is strictly prohibited and may be unlawful. If you are not the
> intended recipient, please contact the sender by return e-mail and destroy
> all copies of the original message.
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 08 Nov 2016 11:36:01 -0500

> that also consider those ~50 billion of currently deployed devices as

**Many** of the devices involved in the recent attacks *DO* run Linux, and
do have MMUs.  (I don't consider routers and cameras to be IoT, even though
the press does.)

The price of MMUs is coming down significantly.

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

---

From: "Garcia Morchon O, Oscar" <[email-masked]>
Date: Tue, 8 Nov 2016 20:09:22 +0000

Hi Adam,

we will be discussing next steps for the T2TRG draft in the T2TRG meeting.

Regards, Oscar.

From: Adam Montville [mailto:[email-masked]]
Sent: Tuesday, November 08, 2016 11:24 AM
To: Garcia Morchon O, Oscar; Ari Keränen; Keith Moore; [email-masked]
Subject: Re: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Securing Internet of Things (IoT) Devices)

Would it be worthwhile to add this to the saag agenda, or is there otherwise some session for discussing the plethora of IoT security related material?

On Tue, Nov 8, 2016 at 10:04 AM Garcia Morchon O, Oscar <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ari, Keith,

Regards, Oscar.

-----Original Message-----
From: saag [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Ari Keränen
Sent: Tuesday, November 08, 2016 9:44 AM
To: Keith Moore; [email-masked]<mailto:[email-masked]>
Subject: Re: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Securing Internet of Things (IoT) Devices)

Hi,

Cheers,
Ari

---

From: Ben Laurie <[email-masked]>
Date: Tue, 8 Nov 2016 21:12:19 +0000

On 8 November 2016 at 15:02, Watson Ladd <[email-masked]> wrote:
> we should recommend memory safety as the easiest
> way to prevent RCE.

If only that were true. For example:

https://access.redhat.com/security/cve/cve-2015-7501

Apparently memory safe languages evolve in complexity until they also allow RCE.

---

From: Ben Laurie <[email-masked]>
Date: Tue, 8 Nov 2016 21:17:39 +0000

> security properties. They don't break the sandbox layer but exploit

Nothing works perfectly, but sandboxing is not completely pointless:
it reduces the attack surface, including (at least for some sandboxes)
the kernel attack surface. Certainly seccomp-bpf claims this property,
as does Capsicum.

Also, even if we fixed every bug in the kernel, we'd still have
security vulnerabilities in applications, which could be mitigated by
sandboxing. Note that this is what the OP claims, not that it defends
the kernel - which I agree is also useful.

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 11 Nov 2016 07:50:58 +0000

Hannes Tschofenig <[email-masked]> writes:

>We probably have do a bit of document scoping. Many embedded devices do not
>run Linux since they have no MMU. I would like to have guidelines that also
>consider those ~50 billion of currently deployed devices as well.

I think that would definitely be useful.  We should distinguish between, at
least, desktop-PC equivalents (anything capable enough to Linux, in which case
just use any standard Unix good-housekeeping rules, you don't necessarily need
the same thing just with IoT stamped on it), and then real SCADA/embedded,
where you've got a single binary blob comprising the RTOS and the
application(s) it runs, no MMU, and barely anything else.

There's also a split in engineering terms between an Internet of
Shi^H^H^HThings device (take the cheapest Arm-based reference design, shovel
Linux 2.6.x and equally old, unpatched binaries onto it, and throw it out to
the public), and what I'd consider proper SCADA gear, stuff that's been
properly designed and engineered, with environmental protection, fault-
checking, and so on, something that won't break the first time you sneeze near
it, or that needs constant tending just to keep it going.  IoS devices have
very different goals (cheap and quick, and if it breaks the vendor doesn't
really care) from SCADA (long engineering cycles, time to do it right but
often political impediments to doing so, and companies that have to stand
behind their products, often for decades after they've shipped).

So the first question would be, how do you divide things up in order to decide
what goals need to be met, and what goals can actually be met?

Peter.

---

From: Adrian Hope-Bailie <[email-masked]>
Date: Fri, 11 Nov 2016 10:16:32 +0200

How does your average consumer know if they're buying an Internet of
Shi^H^H^HThings device or proper SCADA gear?

Surely half the problem is educating price sensitive consumers about how to
distinguish from well-priced good hardware and cheap crap?

All the guidelines in the world will not stop people building crap to try
and sell it cheap

On 11 November 2016 at 09:50, Peter Gutmann <[email-masked]>
wrote:

> not

---

From: Eliot Lear <[email-masked]>
Date: Fri, 11 Nov 2016 09:39:47 +0100

On 11/11/16 9:16 AM, Adrian Hope-Bailie wrote:
> Surely half the problem is educating price sensitive consumers about
> how to distinguish from well-priced good hardware and cheap crap?
>
> All the guidelines in the world will not stop people building crap to
> try and sell it cheap

If we can make it easy for developers to do the right thing, or as much
of the right thing as they can within their cost constraints, perhaps we
can put some dent in the problem.  I think that's possible with
manufacturer usage descriptions (draft-ietf-opsawg-mud) when DHCP or
LLDP are used.  That addresses the base case where the device isn't
infected in the first place, but not the case where it is.  For that you
need a mfgr cert.

Eliot

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 11 Nov 2016 08:59:51 +0000

Adrian Hope-Bailie <[email-masked]>

>Shi^H^H^HThings device or proper SCADA gear?

If it's consumer-grade gear it's almost certainly IoS-grade equipment.

>distinguish from well-priced good hardware and cheap crap?

Not when you've got the marketing resource of an entire industry working
against you.

In any case though the point is to come up with a taxonomy of
embedded/SCADA/IoT/whatever device types that represent typical use cases...

Peter.

---

From: Jeffrey Walton <[email-masked]>
Date: Fri, 11 Nov 2016 04:54:09 -0500

> All the guidelines in the world will not stop people building crap to try

Most consumers won't know. Those who do know or attempt to learn will
be further confused by marketing departments leading to a Market of
Lemons.

ARMv8 devices are a good example. When ARMv8 was first release, phone
OEMs were the first to ship to consumers (some hand waiving). The
relevant press release boasted about it. I purchased both phones for
early testing to find out they were effectively in a 32-bit ARMv7
configuration running armhf images.

Fast forward 18 months or so, and its the same situation. There are
four commodity dev-boards available I know of running A53
architecture:

  * RaspberryPi-3
  * ODROID-C2
  * Pine64
  * LeMaker HiKey

RPI3 and ODRID are A53, but they lack CRC and Crypto extensions.
Pine64 and HiKey are A53 and have the optional CRC+Crypto extensions.
If you check the marketing literature, all of them appear to be the
same.

The RPI3 is the worse because its like the cell phones. Its marketed
as ARMv8, but only got an armhf image. One of the RI3 FanBoi's
believed there was no {performance|security} benefit to switching to
AArch64 or Aarch32, and he actively lobbied against it t users.

I know the board characteristics in practice because I purchased the
actual boards and tested them. I was surprised to learn two of them
lacked CRC+Crypto because that's one of the features I wanted when I
purchased them.

Jeff

---

From: Jeffrey Walton <[email-masked]>
Date: Fri, 11 Nov 2016 04:54:54 -0500

> Not when you've got the marketing resource of an entire industry working

+1

> embedded/SCADA/IoT/whatever device types that represent typical use cases...

+1

Jeff

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 11 Nov 2016 21:30:30 +0100

The write-up is not only focused on this specific attack. It aims to be
a more more generic to the broader IoT sector.

Using high-end processors is a valid choice for many deployments but
there are also sectors that need features of the M-class device as well,
for example higher energy efficiency.

In terms of scoping I am trying to say that the recommendations should
not assume high-end device only.

Ciao
Hannes

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 12 Nov 2016 07:24:53 +0900

> embedded/SCADA/IoT/whatever device types that represent typical use cases...

JFYI: To talk about classes of devices, we already have RFC 7228.
The LWIG WG is now looking at updating this document.

https://datatracker.ietf.org/doc/draft-bormann-lwig-7228bis/

This is work in progress, but we are very open to useful classification to be added to this document.

Grüße, Carsten

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 12 Nov 2016 07:36:45 +0000

Jeffrey Walton <[email-masked]> writes:

>Most consumers won't know. Those who do know or attempt to learn will be
>further confused by marketing departments leading to a Market of Lemons.

It's actually a bit more complicated than that.  Most of the IoS wouldn't
exist if it wasn't for the S.  If all that was available was industrial-
strength SCADA devices running VxWorks then you wouldn't have WiFi-enabled
toothbrushes [0].  It's hard to find board shots of PLCs, but here's one:

    http://www.mikroe.com/img/development-tools/pic/picplc4-v6/gallery/picplc4v6_01.jpg

About 15-20% of the entire board area is the power supply and conditioning
circuitry, and it's pretty serious stuff, not just some woosy 3216 surface-
mount capacitor here and there.  Now compare that to a Pi (the most visible
example of an IoT device), which has a basic switchmode converter to get the
lower voltages needed by the board, and the protection is a polyfuse.  Which
you may need to remove because the decision to use micro USB for power means
you can't power much of anything attached to the Pi so you need an externally-
powered hub, and then need to hack either the hub or the Pi so you don't
backpower it and fry something.  You can end up spending more on the
additional parts you need than you spent on the Pi itself, and it requires
endless nursing (the WiFi-dongle drivers are kernel-specific, so when you do a
kernel upgrade it knocks itself off the net until you plug in an ethernet
cable and upgrade the drivers that way, and way too many other headaches, the
SD cards tend to get corrupted a lot so you have to reinstall your OS image,
etc).

And that's the blessing and the curse of the Pi (and equivalent IoT things).
By making it cheap, powered off a micro USB charger, running Linux, etc, it's
very accessible.  Anyone can throw together a product around a reference Arm
board, and they inevitably do.  If the same thing was done with an industrial-
grade device, it'd cost $400 per unit and run VxWorks, and there wouldn't be
an IoT.

Anyway, point is, we've got the IoS for better or for worse.  Unfortunately I
can't think of any obvious way of dealing with it...

Peter.

[0] I was trying to think of something over-the-top ridiculous but then
    remembered that the real thing already exists.

---

From: [email-masked]
Date: Sat, 12 Nov 2016 21:27:59 +0900

Hi,

We will also have a presentation providing a read out from the IoT software update workshop (IoTSU).  The presentation is linked from the agenda for SAAG.
https://datatracker.ietf.org/meeting/97/agenda/saag/

This does not provide what you are looking for though.

Thank you,
Kathleen 

Please excuse typos, sent from handheld device 

> On Nov 9, 2016, at 5:09 AM, Garcia Morchon O, Oscar <[email-masked]> wrote:
> 
> Hi Adam,
>  
> On Tue, Nov 8, 2016 at 10:04 AM Garcia Morchon O, Oscar <[email-masked]> wrote:
> Hi Ari, Keith,
>