Re: [T2TRG] [saag] New Version Notification for draft-irtf-t2trg-iot-seccons-02.txt

Hi Thorsten,

I fully agree with your email.

Regarding: “I had a private chat with Oscar and pointed out the missing details on mitigation of the risks he points out in his document. Not sure if that should be added to an already long document or if we should split it into a separate document.”

I agree that having such a document would be great. Personally, I would not include the mitigation strategies in this document since this document is already pretty long. I also think that just a list of mitigation strategies will be rather long and also confusing for designers. A designer will still ask himself, what do I really need to protect “my” IoT system?

What about the following? We could have a different document that includes:

-          Extended text related to how to deal with threats (page 12 in the current document starting with “Dealing with above threats and finding suitable security mitigations is challenging: there are very sophisticated threats that a very powerful attacker could use; also, new threats and exploits appear in a daily basis.  Therefore, the existence of proper secure product creation processes that allow managing and minimizing risks during the lifecycle of the IoT devices is at least as important as being aware of the threats.  A non-exhaustive list of relevant processes include:”

-          Mitigation strategies: here we can list main mitigation strategies to deal with different types of threats.

-          Security profiles (section 6 in current document, this section would be removed from the current document) that illustrate which mitigation strategies should be applied to different classes of use cases (I believe that this makes lots of sense since not all classes of use cases will be exposed to the same threats, and thus, mitigation strategies will also be different.)

Regards, Oscar.

From: Thorsten Dahm [mailto:thorstendlux@google.com]
Sent: Friday, April 7, 2017 4:17 PM
To: T2TRG@irtf.org; saag@ietf.org
Cc: Garcia-Morchon O, Oscar <oscar.garcia-morchon@philips.com>; Barry Raveendran Greene <bgreene@senki.org>; Eliot Lear <lear@cisco.com>; Mohit Sethi <mohit.m.sethi@ericsson.com>; Kumar, Sandeep <sandeep.kumar@philips.com>; Peter Gutmann <pgut001@cs.auckland.ac.nz>
Subject: Re: [saag] [T2TRG] New Version Notification for draft-irtf-t2trg-iot-seccons-02.txt

Hi all,

I also agree with the statements of the folks who previously commented on the topic. Before the IETF in Chicago I had a private chat with Oscar and pointed out the missing details on mitigation of the risks he points out in his document. Not sure if that should be added to an already long document or if we should split it into a separate document. And yes, while it is a good document and we should have it, documents alone don't change much. What we need are products that implement the best practices as well as network operators and consumers who refuse to connect insecure dishwashers to their enterprise or home network. Without market pressure and holding manufacturers accountable for the damage their products may cause it's hard to convince them to spend money on IoT security.

Taking a step back, I doubt that IoT will be able to take care of itself in the next couple of years, so we have to rely on operators to do the job for the manufacturers while we push BCPs and standards like the current document to them. IMHO the extensive usage of features like private VLANs is still very painful and even in combination with stuff like MUD, it would only solve parts of the problem. We as operators probably need to rethink the stack from L1 to L7 and reach out to other Working Groups outside of the IoT / Security space to address the need. The bootstrapping work in ANIMA is a good example for that. We may can't avoid completely connecting devices that use strcpy() into fixed-size buffers to our networks, but we can prevent them from disturbing other devices on the network and limiting the blast radius in case of a (unavoidable?) compromise.

Maybe a good topic to be picked up by the T2TRG is the question of how to protect the network from compromised devices, the majority of the work as I can see it focuses currently on the security of the Thing itself.

cheers,
Thorsten

On 6 April 2017 at 15:32, Peter Gutmann <pgut001@cs.auckland.ac.nz<mailto:pgut001@cs.auckland.ac.nz>> wrote:
Garcia-Morchon O, Oscar <oscar.garcia-morchon@philips.com<mailto:oscar.garcia-morchon@philips.com>> writes:

>The main goals are:
>- summarize existing solutions out there and in IETF
>- summarize security considerations and challenges that should be addressed
>  in the future

The problem is that almost everyone else who has any interest in the IoS has
also published their own checklist or guidelines or BCP or whatever they felt
like doing.  It's not that we have a lack of guidelines, we have as many as
you like (and that's not just IoS-specific stuff but includes any book on
secure programming, security engineering, and so on), but no-one uses them.
So it seems like we need to look at why people aren't using them, and how we
can get them used.  Why does every J.Random Linux distro come with hardened
system binaries and libraries and books and howto's on further hardening
things, but every IoS device feature strcpy() into fixed-size buffers and XSS
and directory-traversal bugs like it was 1995?

The problem with the non-specificity of many of the guidelines is that you end
up with something that tries to cover, for example, a Raspberry Pi, which is
essentially a Unix server and for which you don't need any new guidelines
because any reference on setting up and hardening a Unix box will do, and at
the other end of the spectrum a PLC running what's labelled as an RTOS but
which is really just a big binary blob containing device drivers, a task
scheduler, a network stack, and the application, all running in ring zero with
no protection features.

So the document currently is an interesting overview of IoS security issues,
and better than most I've seen, but there's no obvious answer to a question
like "I have a PLC, what steps should I take to secure it?".  Instead, it's a
survey of every possible technology and mechanism that could be applied to the
problem, which leads to an obvious suggestion of submitting it as a paper for
Computing Surveys instead of publishing it as an RFC, since it reads very much
like a Computing Surveys paper and would probably work well there.

Peter.
_______________________________________________
saag mailing list
saag@ietf.org<mailto:saag@ietf.org>
https://www.ietf.org/mailman/listinfo/saag

--
Thorsten Dahm

Network Engineer
Google Ireland Ltd.
The Gasworks, Barrow Street
Dublin 4,  Ireland

Registered in Dublin, Ireland
Registration Number: 368047

________________________________
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.