Ransomware and DevOps Ransomware. A scary topic and one that is apparently more common than I suspected. Before you go further, if you haven't restored a database backup in the last month, stop and go verify your DR plan works. That's one of the overconfident issues facing lots of government and businesses. While this might not help your entire organization, at least you'll have some confidence in your process. This is a great article from Ars Technica and worth reading: A take of two cities: Why ransomware will just get worse. I'd recommend you read it and think about a few things. First, do you have insurance because things (substitute your own word here) happen? Second, have you really tested a DR plan for some sort of software issue like this? You might think about a way to restore systems in an air-gapped manner that prevents them from re-triggering encryption from a remote source, or maybe even in a scenario where you reset dates/times to prevent timer triggered issues. Perhaps the bigger issue is are you actually patching and updating systems? Too many organizations can't, don't, or won't. The former means you aren't sourcing software properly. Either you're using vendors with poor practices or have a poor development process. Organizations that don't or won't bother prioritizing patching, especially security issues, are likely those that will have issues as more criminals find ransomware and other ways of attacking their systems. Software and environments continue to be more complex, which means that the less you ensure the system is patched, the more likelihood there is of a vulnerability in your environment. DevOps and the cloud PaaS/SaaS platforms are attractive for a few reasons. One is that the platforms are constantly kept up to date, forcing you to move along with them. SaaS cloud vendors know this and are constantly patching and updating their software in order to keep it running. DevOps asks that we always have the ability to release, that we have the ability to patch on demand, not only at certain intervals. This is something I try to emphasize when talking about DevOps. It isn't necessarily about velocity, but it is about being able to release when you need to, whether that's today or next month. This is especially important for security issues. I have had hope for a long time that insurance would drive software to higher quality, and I still do. With the attacks and issues of ransomware, and who knows what other techniques that will be developed, I still believe more companies will buy insurance. I then hope, because of selfish motives, the insurance companies will require frequent patching, regular vendor certification of new platform versions, and better development processes. If insurance drives DevOps, I'm all for it, but I'd prefer to decide to adopt it yourself and start making changes today. Steve Jones - SSC Editor Join the debate, and respond to today's editorial on the forums |
