<story><title>The ransomware surge</title><url>https://www.bbc.com/news/technology-56933733</url></story><parent_chain><item><author>korethr</author><text>Backups.&lt;p&gt;I cannot emphasize enough the importance of backups. Take backups, verify your ability to restore from them, and keep them segregated from the rest of your infrastructure. It doesn&amp;#x27;t matter how inelegant and hacky your backup solution is, so long as you can restore from it. Any backup you can restore from is better than no backup.&lt;p&gt;You might get a call from one of your application engineers shortly before bed on a Friday night that the web front-ends are acting weird, and they can&amp;#x27;t get in to troubleshoot, and then 10 minutes later come to discover that the latest strain of Ryuk has laid waste to 2&amp;#x2F;3s of the servers and workstations across the company. And then all of a sudden, those VM snapshots you&amp;#x27;d been copying off to another file share with a shell script have become your salvation. Yeah, containing Ryuk and the rest of incident response mode are going to suck, but at least now you don&amp;#x27;t have to write an apology to your customers that the data they entrusted to you has been irrevocably lost.&lt;p&gt;In case you&amp;#x27;re wondering, no, that did not literally happen to me. But it is a mild fictionalization of someone I know.&lt;p&gt;Keep backups, and test your restores regularly, people.</text></item></parent_chain><comment><author>the_duke</author><text>I sometimes do infrastructure consulting.&lt;p&gt;One of the first questions I ask is if they have at least one fully independent, full&amp;#x2F;incremental off-site backup that can&amp;#x27;t be corrupted from the main infrastructure, and if they have ever checked if they actually work and are restorable.&lt;p&gt;I&amp;#x27;m continuously surprised how often the answer turns out to be no after dinner digging, even in larger companies with otherwise well-run IT.&lt;p&gt;No, the automatic 7 day RDS snapshots or turning on S3 versioning is not a sufficient backup. Neither is mirroring to a S3 Glacier bucket in the same org, or rsyncing to a a backup server in the same datacenter.&lt;p&gt;Backups are annoying and unglamorous. Nobody wants to do them, or do the tedious work of validating them or setting up something like an automated restore test.&lt;p&gt;Until the day you lose your data.</text></comment>
<story><title>The ransomware surge</title><url>https://www.bbc.com/news/technology-56933733</url></story><parent_chain><item><author>korethr</author><text>Backups.&lt;p&gt;I cannot emphasize enough the importance of backups. Take backups, verify your ability to restore from them, and keep them segregated from the rest of your infrastructure. It doesn&amp;#x27;t matter how inelegant and hacky your backup solution is, so long as you can restore from it. Any backup you can restore from is better than no backup.&lt;p&gt;You might get a call from one of your application engineers shortly before bed on a Friday night that the web front-ends are acting weird, and they can&amp;#x27;t get in to troubleshoot, and then 10 minutes later come to discover that the latest strain of Ryuk has laid waste to 2&amp;#x2F;3s of the servers and workstations across the company. And then all of a sudden, those VM snapshots you&amp;#x27;d been copying off to another file share with a shell script have become your salvation. Yeah, containing Ryuk and the rest of incident response mode are going to suck, but at least now you don&amp;#x27;t have to write an apology to your customers that the data they entrusted to you has been irrevocably lost.&lt;p&gt;In case you&amp;#x27;re wondering, no, that did not literally happen to me. But it is a mild fictionalization of someone I know.&lt;p&gt;Keep backups, and test your restores regularly, people.</text></item></parent_chain><comment><author>likecarter</author><text>A crucial point you missed:&lt;p&gt;Ransomware gangs often destroy your backup infrastructure. So it&amp;#x27;s important to create pull-only backups or backups that cannot be deleted &amp;#x2F; overwritten.</text></comment>