[AusNOG] The Ransomware to come

Fri May 19 00:04:18 EST 2017

Leaving aside the baits/bread crumb trails/egos this group is about sharing
experiences, ideas and suggestions.

Everyone is a product of both their knowledge, experiences AND hopefully
their being open to look at things. The current for want of better words
"The Ransomware to come" is only  the latest in a long long line of
attacks/hacks. And they won't stop after this one.

The great danger is people listening to the 'Government' saying just keep
Windows patched up and your 100% secure. I positively   shuddered at that
type of comment. And pretty sure if X company got owned and could 'prove'
they had patched the Government would run a million miles in the other
direction if they wanted compensation for being owned.

Many patches only come out AFTER exploits  are found and all to often made
public. Ie hackers probably have known for X time. All companies have at one
time or another dragged their 'heels' on fixing/acknowledging
vulnerabilities.

If anyone has better suggestions than multiple off line backs ups over time
to defeat ransomeware then please share. Macafee etc are very busy adverting
- trust us we"ll back you up. "NO ransomware threat, you get owned no data
lose." 

Comments.

Regards
Chris

From:  AusNOG <ausnog-bounces at lists.ausnog.net> on behalf of Paul Wilkins
<paulwilkins369 at gmail.com>
Date:  Thursday, 18 May 2017 8:35 PM
To:  AUSNog <ausnog at lists.ausnog.net>
Subject:  Re: [AusNOG] The Ransomware to come

It's not possible to be in the wrong group on the Internet. On the Internet,
everyone knows everything ;)

Pointing to where it's all been tried before and all too hard, overlooks
businesses actively creating successful business opportunities based on a
security plane overlay (APM), and new protocols (SAML). But these aren't
solutions, they're after the fact workarounds, symptoms of the underlying
failure to deliver end to end security at the network layer. If you're
dialling in from Chad or Upper Volta, welcome to the internet, but I really
don't want your packets touching my email spool, ever.

 SSL is not the solution, it's just another bandaid. We're approaching a
situation where you don't need a firewall because a router ACL on port 443
offers equivalent security. And then because now you can't secure the
control plane because the data's encrypted, you have to spoof certificates
on the firewall.

It smacks of all care and no responsibility. (Read any user license) And if
you get hacked, you were stupid, and probably ugly, overlooking that the
overwhelming majority of IT users are definitely not literate in IT
security.

Kind regards

Paul Wilkins

On 18 May 2017 at 00:51, Chris Hurley <chris at minopher.net.au> wrote:
> At the end of the day it's about sharing ideas/experiences.
> 
> If you think you know everything, sadly your with the wrong group. ;-)
> 
> From:  AusNOG <ausnog-bounces at lists.ausnog.net> on behalf of John Lindsay
> <johnslindsay at mac.com>
> Date:  Thursday, 18 May 2017 12:13 AM
> To:  Mark Smith <markzzzsmith at gmail.com>
> Cc:  AUSNog <ausnog at lists.ausnog.net>
> Subject:  Re: [AusNOG] The Ransomware to come
> 
> Watching your server get owned between installing the OS and the patching
> finishing is always sobering.
> 
> John Lindsay
> 
> On 17 May 2017, at 11:14 pm, Mark Smith <markzzzsmith at gmail.com> wrote:
> 
>> 
>> 
>> 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
>>> 
>> 
>> _______________________________________________
>> AusNOG mailing list
>> AusNOG at lists.ausnog.net
>> http://lists.ausnog.net/mailman/listinfo/ausnog
> _______________________________________________ AusNOG mailing list
> AusNOG at lists.ausnog.nethttp://lists.ausnog.net/mailman/listinfo/ausnog
> 
> _______________________________________________
> 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/20170519/9d2d6884/attachment.html>