[talk] Suggest meeting topic: role of BSD in response to ransomware

[Steven Kreuzer]

> On Jul 11, 2017, at 9:31 AM, James E Keenan <jkeenan at pobox.com> wrote:
> 
> Suppose that you are a sysadmin or other, non-executive-level techie in such an organization.  You've heard about FreeBSD and OpenBSD and you wonder, "Would using these OSes have helped us either resist a ransomware attack?  Could they help us recover better from such an attack?"

So, just like everything else I think that the answer is both yes and no. For this very particular incident the exploit vector was taking advantage of a Windows specific issue. This attack would have been mitigated if you ran a patched version of Windows as Microsoft had already provided a fix for this. If your file services for windows clients were provided by Samba running on either a BSD or Linux box, a NetApp, Isilon or some other enterprise storage solution you also would not have been vulnerable to WannaCry.

The real issue here is that people either unknowingly ran vulnerable piece of software, or they knew and didn't/couldn't upgrade for one reason or another. For these types of incidents, it doesn't really matter what you are running because if you have infrastructure that has known vulnerabilities and you can't address those issues, its not if you have an 'incident', but more likely when.

About a year ago some other ransomware spread around the internet, but this one ran on plain old Windows desktops and encrypted files on any drive that the machine had mounted. When a user in my office got hit by this, because we have shared drives which are mounted and mapped to regular drive letters, all the files in these remote volumes got encrypted. However, because we implemented a very aggressive snapshot policy, recovery was just taking that workstation offline and just promoting the last snapshot taken on the storage server before the incident. You might be able to make the case that filesystems such as ZFS which offer very cheap snapshotting capabilities make it easier to recover from these types of events but that comes with the complexity of 'rolling your own' and having an IT department with the skill set to support that.

Its always really easy to point a finger at Microsoft and blame them for writing buggy, insecure software but more often than not the real underlying issue is that the company doesn't put an emphasis on security, values uptime more than upgrades or has components that are so critical to business continuity that people are afraid to touch them. In my experience its usually been a combination of all three. Unfortunately, no amount of technology can fix a broken culture.