[throw0101a]

> Security is just hard, and it's not easier just because you're a tech company.

We're not talking about everyone having Red Teams here. We're talking about keeping up to date with regards to Patch Tuesday, or even just having an OS that still actually gets patches. That'll get us 80-90% of the way to decent security:

> “Almost two months passed between the release of fixes for the EternalBlue vulnerability and when ransomware attacks began,” Microsoft warned. “Despite having nearly 60 days to patch their systems, many customers had not. A significant number of these customers were infected by the ransomware.”

* https://krebsonsecurity.com/2019/06/report-no-eternal-blue-e...

[peterwwillis]

Do you know how many versions of how many operating systems across how many different platforms and products my company uses? Hundreds of variations, maybe thousands. Only a few groups have a solid handle on regular patching, and that's because of how hyper-standardized their systems are.

Even if an OS has automatic patching, you can't just immediately apply patches without going through an SDLC and QC process. And not every group even has those processes defined. Even if they do, you still need to address critical business problems before security ones.

[throw0101a]

> Do you know how many versions of how many operating systems across how many different platforms and products my company uses?

What OSes besides Windows, macOS, Linux, Solaris, AIX, HP-UX, z/OS, mobile (Andriod, iOS)? SCADA stuff perhaps?

And how many of those operating systems are targeted by worms and ransomware?

I know when I used to admin Solaris and IRIX machines we were worried a lot less about attacks than the Windows desktop folks. An nmap of the systems showed SSH open and one or two other services, which meant very few vectors for attack.

The fact of the matter is that by securing desktops, one probably takes care of 80% of a company's attack surface. Next take care of your Windows servers, which is another 10%. Then go after Unix-y servers and things like printers, HVAC, IPMI, etc (which should be VLANed off).

[peterwwillis]

Let's imagine just one example of patching a remote hole in a Windows server. First, you have to stage a duplicate of an old server with a new patch, which can take days. A production environment may need significant development effort just to integrate the patch, which takes days. Then run all tests and QC processes against it, which can take days. Then you can deploy it during a maintenance window. This is 1-2 business weeks.

Now multiply that times 1,000 different combinations of versions of Windows, applications, networks, platforms, and so on.

You're not just patching "servers", anyway. You're patching bare metal machines, hypervisors, AMIs, container images, software packages, plugins, network applications, security policies. Often vendor platforms don't even have a patch available so you have to implement a custom workaround, if one exists.

One could write an entire book about this subject. Please believe me, it's not simple.

[tedunangst]

Perhaps the city of Baltimore should have considered this before deploying thousands of different server configurations.

[velp]

But having so many configs is security in and of itself! /s

[nradov]

That approach might have made sense 10 years ago but it's no longer tenable now that the threat environment has escalated. Organizations will now have to roll out patches immediately even at the risk of disrupting mission critical operations.

[closeparen]

The attacker isn’t going to follow your SDLC and QC processes.