[AusNOG] The Ransomware to come

[Paul Wilkins]

*However, what the host OSes and applications do with and how they
interpret the packets' payloads when they arrive isn't the responsibility
of an internetworking protocol. If you think it can easily be made one,
how?*
This is exactly the problem in a nutshell. To say that security is not a
function of the ISO stack, separates application security from the network.
There is not going to be application end to end security until security at
the data layer integrates with application security. Even SAFE, which is a
step in the right direction of granting application access according to
traffic profile, can't deliver end to end security, because application
rights are not informed by the network profile. Or if it is, it's on an ad
hoc basis.

My feeling is we could see Cisco invent a means of allocating SGT tags by
BGP community extended to 64 bits, and some integration of 802.1x to
deliver Trustsec to the desktop. The problem being, this implies separate
routing tables for different security profiles, being necessarily the case,
which is not something ipv6 could be made to support.

The fundamental architectural failing of the ISO stack, is there is a data
plane, and a control plane, but no security plane, without which there can
never be end to end security.

Kind regards

Paul Wilkins


On 13 May 2017 at 14:10, Mark Smith <markzzzsmith at gmail.com> wrote:

> On 13 May 2017 12:31 pm, "Paul Wilkins" <paulwilkins369 at gmail.com> wrote:
>
> >In light of today's ransomware attack, (74 countries/with demands
> translated in 28 languages), I'm tempted to take a step back and take a
> longer optic on the gap between what the internet was meant to be, and what
> exists today. The OSI model which built the net was built on implicit trust
> between each layer and the one above. It was never anticipated that in a
> couple of milliseconds, a few hundred packets from Kazakhstan could span
> the globe
>
> I'd say that is a perfect description of the problem being solved with
> internetworking protocols, from as far back as when they were being
> invented in 1970s.
>
>
> > to hard drives around the world, and a ubiquitous operating system would
> then lock up people's data with hard cryptography.
>
> However, what the host OSes and applications do with and how they
> interpret the packets' payloads when they arrive isn't the
> responsibility of an internetworking protocol.
>
> If you think it can easily be made one, how?
>
> >You don't even need to play Cassandra to realise there's a genuine risk
> sooner or later, someone will sign a driver (ala Stuxnet), and significant
> portions of the global internet population will lose their data. Actual
> costs could run to billions of dollars. Unfortunately it will likely take
> an event of such magnitude before there's broad recognition that the trust
> model of the internet built on ipv4 is fundamentally broken, and we need a
> new network protocol that supports integrated security, and this would be a
> more worthwhile exercise than replacing ipv4 with ipv6.
>
> The best place to solve a problem is as close to as possible or
> ideally where the cause exists. This ransomware is infecting Windows
> OS only ... if it was a network layer protocol cause, then those of us
> running Linux, Android, Chrome OS, Mac OS X, iOS etc. would also be
> effected by it.
>
> This is a Windows OS problem and needs to be solved there - which from
> what I've read apparently it was a month or so ago with a security
> patch. (There is the broader issue of why Windows PCs aren't being
> patched in a timely manner, however that is also not a problem that
> can be solved by a network layer protocol.)
>
> I'd also observe that there is no reason why this same issue couldn't
> have occurred when viruses were being propagated via floppy disk
> between PCs running MS-DOS.
>
> Actually, looking it up, it did (it's now ringing a bell when I think
> about it).
>
> https://en.wikipedia.org/wiki/AIDS_(Trojan_horse)
>
>
> Regards,
> Mark.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20170514/2f48624c/attachment.html>