Re: [T2TRG] [saag] 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> wrote:

> Garcia-Morchon O, Oscar <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
> 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