Re: [Smart] [Secdispatch] New Version Notification for draft-lazanski-smart-users-internet-00.txt

I am pretty sure this is not security 101 stuff. In fact I am pretty sure
that it will be quite a while before the academy really gets to grips with
this stuff. They don't have the same biases we do but they have different
ones.

For example, the need to patch systems is brought up and this is almost
always seen as a good thing. Not in the process control world it isn't. The
problem of unauthorized updates is a very serious concern for them.

Devices that automatically update themselves are vulnerable to a denial of
service attack by the device provider.

This is not an attack many device providers are worried about because it
isn't an attack that is going to affect them (for a start) and they think
they can trust themselves. Which may well not be true. I have seen a single
employee cause $1 million worth of vandalism after being upset that his
wages were being garnished for alimony. I really doubt that more than 5% of
the companies that make IoT devices have effective controls.

The same is true of devices that depend on a tied service. My Revolv hub is
useless because Google bought the company and shut down the service leaving
me with $2500 worth of dead equipment in my walls.

This is not 101 stuff and in fact I don't think that a single one of the
IoT vendors out there is showing that they understand it. We are still at
what I call the 'narcissistic' phase of the market in which every medium
sized IoT vendor thinks it is all about themselves.

The fact that an IoT device makes the owner dependent on the provider is
totally a security issue. The fact that the device providers don't want to
acknowledge it doesn't make it any less so.

I have spent well over $25,000 on IoT devices in the past few years. Of
these, I cannot think of a single one that I can give an unqualified
recommendation for. And there are security issues with every single one of
them.

On Mon, Jul 15, 2019 at 11:07 AM Bret Jordan <jordan.ietf@gmail.com> wrote:

> Eliot,
>
> However, many here assume that the endpoint can run security software,
> that security software is available for all endpoints, or that security
> software can be updated all at once across an organization/enterprise.
> Other also assume that if you just patched your software, you would be
> safe.  These assumptions are horribly wrong and goes to show the
> fundamental lack of understanding.
>
> The reason I called them out the way I did was I was trying to be
> explicitly clear on where the attack was coming from and what role the
> endpoint had in that attack. I did not want to assume that everyone
> understood the attack surface and threat model.
>
> So a client may initiate the connection to a compromised site or content.
> This is a very common case for initial infection.  However, once the threat
> actor is in the network, they often move laterally through the network and
> compromise machines where the attack is not initiated from the victim
> endpoint, but rather initiated from a compromised endpoint. So what you can
> see and do to protect your network changes.
>
> All of this is pretty basic network/cyber security 101 stuff.  What the
> IETF needs to know is how SoC analysts need and require sensors on the
> network, network log data, and DNS data to help identify these attacks and
> find them. We always had a saying when I was on the other side of the
> fence, “operating systems and software can always be made to lie, but the
> network never does..” Network analysis and network forensics is a critical
> part of the day-to-day analysis in a SoC.  This is often how intrusion sets
> are detected and threat actors behavior in the network is tracked.  This is
> not about selling product as some believe. This is about organizations and
> enterprises protecting their systems, networks, and data.
>
> Thanks,
> Bret
> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
> "Without cryptography vihv vivc ce xhrnrw, however, the only thing that
> can not be unscrambled is an egg."
>
> On Jul 15, 2019, at 2:01 AM, Eliot Lear <lear@CISCO.COM> wrote:
>
> Hi Bret,
>
>
> 1) Is the content or content provider that the user is going to
> compromised and trying to attack the endpoint?
> 2) Is the content provider that the user is going to a stage 2 delivery
> site?
> 3) Is the content provider that the user is going to the location for
> outbound malicious content (data exfiltration, CnC traffic)
> 4) Is the content provider that the user is going to adversely tracking
> and monitoring everything the end client does, aka active surveillance
> versus passive surveillance?
> 5) Is the remote site that the user did not go to attack the end point.
>
>
> While we tend to think of endpoints as being equivalent in class, in which
> case your use of the term "content provider” would be somewhat redundant,
> from a scaling perspective I am far more concerned about unwatched
> unmanaged endpoints than I am about content services.  And again, to me it
> is a matter of what problems I think might be tractable.
>
> Eliot
>
>
> _______________________________________________
> Secdispatch mailing list
> Secdispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/secdispatch
>