CrowdStrike and the risk of using homogeneous infrastructure

With the whole CrowdStrike debacle¹² yesterday³, I wonder how this could happen and why so many companies are using the same solution – automatically updated without any tests on the customer’s site. Why do you set up your infrastructure so it can deploy updates to your productive system without any (manual) tests beforehand? Or at least delay the deployment until a short grace period so you can see whether there is a big issue with it. I understand that speed is essential for some security issues. But the risk of deploying untested stuff (especially from a third party) to your network is not worth it.

And all these ideas are not only relevant to the situation yesterday. It would help if you had an answer no matter what systems you use. Ultimately, it all boils down to the fact that you can’t implement security by buying a solution from a third party without investing some of your budget in having good processes around the product and how you deploy something. I also wonder how much of this was happening because the persons in the position to buy these solutions were looking at what software their peers (in the industry) use and just buying the same solution. And I understand this as well. When somebody you know (and hopefully trust) decides to use solution A, you can use it as well and don’t need to vet it as much. I certainly caught myself thinking this. In my case, it was on the framework level in code instead of whole software solutions. But sometimes it is worth not using what everybody else uses, and it also helps when there is a healthy market of similar solutions around so the risk can be wider spread. But then this also implies that you use servers with different operating systems, which makes your whole infrastructure more expensive (and complicated again).

I am still trying to figure out an answer to this topic. I got shaken a bit yesterday and will use this as a wake-up call.

• /writing