[AusNOG] The Ransomware to come

[Mark Smith]

On 17 May 2017 10:36 pm, "James Hodgkinson" <yaleman at ricetek.net> wrote:

> according to the data's provenance

And how do you verify this provenance? I'm still looking for any more
methods of confirming provenance or intent or validity than the ones we
already have - which work perfectly well when implemented correctly. The
same way your various "planes" would work well *if* implemented correctly.

I think you're missing out on a whole world of security that's already in
place by being stuck in old world ideas of segmenting traffic for the sake
of it.

Check out Beyond Corp (https://beyondcorp.com/) and the Zero-Trust concepts
for something already out there which helps solve what you're trying to do,
but doesn't require a whole new networking protocol for the sake of it.


I think they're giving Google a bit too much credit for this idea of having
a perimeterless network- although it is very good to have them as a major
production example to point towards.

First time I came across the idea was in Steve Bellovin's "Distributed
Firewalls" from 1999. Entirely changed my perspective on where host
security is best done, having deployed network firewalls in around 1996
when they were just coming into the scene.

https://www.cs.columbia.edu/~smb/papers/distfw.pdf

Many parts of my 2013 AusNOG presentation were heavily influenced by that
paper and its fundamental ideas and observations.

Look up Steve Bellovin to see how significant it is for him to say the
firewalling is best done primarily on the hosts.

A slightly more recent project related to "perimeterless networks" was the
Jericho Forum, founded in 2004.

https://en.m.wikipedia.org/wiki/Jericho_Forum

Regards,
Mark.



James


On Wed, 17 May 2017, at 21:45, Paul Wilkins wrote:

Mark,
That's a good question and I'm glad you asked.

Once you have a security plane for your data, you can assign profiles
according to the data's provenance. Integrate this with your OS security
plane, including as an input to your virus scanner, with a view ultimately
to preventing control plane actions (like encrypting all your data) that
emanate from untrusted or untrustworthy sources from ever being allowed
write access outside of the mail spool.
The basic problem being, the OS treats a control plane action on a socket
the same, regardless of you're logged in from iLo, or coming remote from
Ukraine. Firewalls are essentially creating an artificial security plane,
but it's a bandaid, and requires you architect your network to channel all
your traffic through a chokepoint. If a socket's security profile was part
of the API, the profile would follow control actions up the stack, and
you'd get end to end security.

Kind regards
Paul Wilkins

On 17 May 2017 at 11:12, Mark Newton <newton at atdot.dotat.org> wrote:

On May 14, 2017, at 3:34 PM, Paul Wilkins <paulwilkins369 at gmail.com> wrote:
> 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.

How, precisely, would that make any difference to the ransomware attack
that sparked your creation of this thread?

  - mark


*_______________________________________________*
AusNOG mailing list
AusNOG at lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog



_______________________________________________
AusNOG mailing list
AusNOG at lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20170517/76359d2f/attachment.html>