I'm not going to sugar-coat my opinion, the security landscape is a seemingly very scary place at the moment. It seems like every day I'm reading a new report about a service being breached, sensitive data being leaked and companies having their files encrypted to be coerced into paying a ransom. This is all varying degrees of fear-inducing, especially when you work for a large company which relies on computers and their files to best serve our clients, many of which are very high-profile. One bad link-click, one incorrect double-click of a file attachment, one wrong installation and boom, it's game over. Local drives, mapped shared drives, cloud drives etc. would all be there for the taking, and all the valuable data that we take for granted would be under the control of an attacker who wants to extort as much money as they can get. When you put it that way, it's a wonder why we even allow the internet, email and even computers in the first place! Shut it all down and let's go back to pen and paper! No, not really, as this would provide other concerns such as office fires and documents being lost! So what can we do that's less based on fear, and more about pragmatism and being proactive?\n\nHaving Someone Lock You Out of Your Own House\n\nRansomware is definitely not something to be taken lightly and can come in a few forms. Firstly, there is the straight-up malicious software application that runs on your machine, encrypts the contents of your hard-drive with a key that you don't possess and then offers to sell you this key for a fee, frequently in Bitcoin. This is can be delivered as attachments in emails, as well as downloaded as payloads when a malicious site is visited. It can also be delivered by an attacker via a vulnerability in software running on the victim(s) machine. There are instances where this kind of software also moves across a network, infecting other machines as well and generally causing all kinds of chaos. This has happened with WannaCry and Petya, where these breeds of malware spread across devices running Microsoft Windows using the vulnerable SMBv1 protocol running on port 445. Once deployed, the results were devastating, and affected many organisations including the National Health Service in the United Kingdom.\n\nNHS Cyber-Attack: GPs and Hospitals Hit by Ransomware\n\nCyber-attack that Crippled NHS Systems Hits Nissan Car Factory in Sunderland and Renault in France\n\nTelefonica WannaCry Ransomware: One Of Spain's Largest Telecom Companies Hit By Cyberattack\n\nFedEx Says Cyber Attack to Hurt Full-Year Results\n\nAnother kind of ransomware doesn't attack and encrypt files, rather it dumps the contents of an organisation's database(s) to a hacker-controlled location. Following this, it then wipes the contents of the database and creates a sole database table/collection that informs the database administrator what has happened and where to send the Bitcoin in order to get the contents of the database back. This is an open-concern, especially in the age of corporate databases mistakenly being exposed to the internet without any access control whatsoever (yes this happens and it is unfortunately very common).\n\nMongoDB and Actually Taking Security Seriously\n\nConfiguration errors such as these obviously lead to data breaches, but in many cases they also lead to the ransoming of this data. Yes it is a bad mistake to make an important database available on the open internet without any access control, but no-one deserves to have their data, or their users data pilfered and sold back to them for a hefty sum because of mistakes like this. As administrators, we need to take these kind of threats seriously as the hackers out there aren't stupid and most definitely aren't messing around. If your database is exposed, pray that it is a security researcher that finds it first otherwise you could seriously be in operational and financial trouble.\n\nMongo Lock Attack Ransoming Deleted MongoDB Databases\n\nMongoDB Ransomware Compromises Double in a Day\n\nElasticsearch Ransomware Attacks Now Number in the Thousands\n\nThese kind of attacks are unfortunately still prevalent to this day, and it was one that took place Tuesday 16th July 2019 on cloud accounting provider iNSYNQ that inspired me to write this article. Years on and there is still work to be done to ensure that these kind of attacks don't claim more victims. It looks like their backups were also affected, which is what got me thinking more deeply about how one can try to protect their data in a cloud environment.\n\nQuickBooks Cloud Hosting Firm iNSYNQ Hit in Ransomware Attack\n\nAn update from Elliot Luchansky, CEO of iNSYNQ\n\nUpdate: We're beginning to turn on customer desktops\n\nEvery Cloud has a Silver Lining\n\nFirstly, let's have a sanity check, as if the basics aren't covered, then no amount of extra tools provided by Amazon Web Services will prevent you from being totally compromised by an attacker.\n\nEnsure your root and all other administrator accounts have the most ridiculously long, random, all character passwords as possible, GO NUTS! If someone can get into your administration dashboards, then you have bigger problems than ransomware.\n\nUse AWS Identity and Access Management (IAM) to switch on multifactor authentication for ALL of your accounts, no excuses.\n\nMake your AWS S3 buckets private by default and use the explicit "block all public access" option. Any public buckets should be kept separate to prevent configuration mistakes exposing your data, and it really isn't worth the risk.\n\nDon't use SMS multifactor authentication, as there are too many known vulnerabilities that can be use to reroute the multifactor codes sent to you.\n\nEnsure the email address(es) attached to your account(s) have strong passwords, as these are usually where reset password links are sent which if compromised can allow an attacker another way to compromise your account.\n\nEnsure that all of your databases have access control enabled, and be extra mindful with MongoDB and Elasticsearch as this isn't the default setting.\n\nEnsure that connections to your databases are encrypted, and if possible, use mutual TLS encryption so that the database and the client need to trust each other for a connection to be agreed.\n\nDO NOT EXPOSE YOUR DATABASE(S) TO THE INTERNET EVER. Even if your database is locked down like it's Fort Knox, DON'T TAKE THE RISK.\n\nWhitelist your ports using your OS software firewall (e.g. IPTables) and EC2 Security Groups, as no two machines within your infrastructure need access to ALL of each others ports (WannaCry would have had a hard time propagating if 445 was blocked by default).\n\nLock down communication protocols like RDP and SSH by default and only whitelist access to specific IPs. Use certificates and ≥4096 private key authentication where possible.\n\nIf using RDP, make sure it is patched and up to date to protect against attackers from abusing it for Remote Code Execution (CVE-2019-0708\n\nDon't put everything (systems, applications, backups etc) on a few super servers (to save costs). If you are breached, you WILL be sorry. Spread your systems out and build in redundancy.\n\nOne thing to be aware of is that no system is unhackable, irrespective of all the measures that you take. It just takes one persistent individual/bot and for all the stars to align for a vulnerability to be found and for all hell to break loose. It is more important that you do everything that you can, and keep up to date with the latest advice and best practice as the cybersecurity landscape is constantly changing. The best bit of advice I was ever given was design your system with the assumption that you WILL be hacked, as it will influence how certain system elements will be designed. You may not ever get hacked, but at least you will have a resilient system that actually helps contain any damage. The lack of understanding that surrounds "Unhackable" claims has been immortalised by the Pen Test Partners (company that tests systems for vulnerabilities) Unhackable Unicorn Badge.\n\nThe Unhackable Unicorn by the Pen Test Partners\n\nUnhackable Unicorn from the Pen Test Partners\n\nIf any company tells you that their system is inpenetrable, take that as an admission that they may not understand security very well and maybe take your business elsewhere. Also be aware that, just by announcing this to the world, they will paint a huge target on their head(s) that many within the Cybersecurity community will gleefully take direct aim at. It's probably best that you don't leave your data with said company to get caught in the crossfire, as things can get very messy!\n\nHacking the Bitfi. Part 1\n\nHacking the Bitfi. Part 2: John McAfee’s Video\n\nHacking the Bitfi Part 3: The Device with No Storage\n\nHacking the Bitfi Part 5: MITM Transactions\n\nI Think it's Safe to Say McAfee's 'Unhackable' Crypto-Wallet has been Hacked\n\nBitfi Removes Unhackable Claim from Crypto Wallet\n\nThe 2018 Pwnie Award For Lamest Vendor Response: Bitfi\n\nIf You Fail to Prepare, Prepare to Get Ransomed\n\nWith the assumption that our system has been hardened and is likely to withstand certain types of compromise, let's move on to other measures that cloud providers (in this case Amazon Web Services) provide. We should also discuss the difference between backups and versioning, where backups tend to be triggered on a timed basis and snapshot a whole region, whereas versioning is done on a file-by-file basis as a file is changed. This is important, as if you don't design your strategy correctly, then even having backups might be unhelpful or even worthless should you be the victim of an attack. Let's say (in a really bad scenario) you take a backup once a week and remove the other backups to save space. You effectively have your live version (the one you are using) and a lone backup should chaos ensue. Now let's say everything goes wrong the day before your next backup meaning that you need to restore from your previous version, you will have lost around 6 days worth of work when you rollback! Depending on how important your system is (e.g. accounting, billing, client management) this could be devastating for you. Taking this example further, what if your system is struck by ransomware just before the backup process is triggered? This could lead to the scenario where your only available backup contains the useless files under ransom! It pays to have a well thought out backup strategy with enough versions of your data to prevent total lockout.\n\nIt is also really important that your backups are kept logically separate from the system being backed up. You could have the BEST strategy ever devised, but if you don't separate your system from your backups, then this time spent could be completely wasted. Let's say you store your backups on the same machine as the application being backed up (don't do this), you wouldn't even need to be ransomed to get into trouble. Computers fail and if that machine dies, all of your data including live application data and backups could die with it. You must also be careful to organise system permissions even if your backups are stored elsewhere. As explained before, ransomware likes to live a jetset lifestyle and travel around, and if it has permission to jump from machine to machine, that is exactly what it will do. If it has access to other drives on a different machine, it definitely won't pass up on the opportunity to cause as much destruction as possible. The more that is broken, the more money you are likely to pay.\n\nAngry child wearing a red Adidas hoodie\n\nProtecting Ourselves\n\nSo what measures are available? Firstly, scheduled snapshots of drives are available and invaluable. Amazon Web Services even allows you automate the whole process, from creation, frequency, and retention. To keep costs down, they even do this for you so that only the differences are stored within subsequent snapshots. Are you using encrypted drives? No problem, the snapshots of encrypted drives are also encrypted. With a little effort, you can start backing up your data today and should your system go down or get ransomed, you'll be able to pick up where you left off with far less fuss than the alternative.\n\nAutomating the Amazon EBS Snapshot Lifecycle\n\nWhat if whole drive backups isn't the solution that you are looking for and you need something that is more finely tuned? Well Amazon Web Services has you covered here within their Simple Storage Solution (S3) offering. You might be familiar with S3 Buckets, and you might be using S3 a backing store for your user data as well as your all important backups. Did you know that that if write to the same name again it will overwrite what was already there? This means that even if you prevent deletes to your backups, if I wrote a blank/encrypted file to your backup, your backup would be updated to this blank/encrypted file. What's to stop a strand of malware from doing this? Clearly we need further protection.\n\nThis is where versioning comes in. By activating versioning for your S3 Bucket, any subsequent updates will not overwrite previous objects meaning that if I updated your backup with a blank/encrypted file, the backup would remain along with the blank/encrypted file. If you want to go one step further, Amazon Web Services offer Object Lock for S3 Buckets which have versioning activated which implements tight controls on Write Once Read Many files. This allows administrators to set a period where files cannot be overwritten nor deleted, and can be implemented at bucket-level and file-level which is really handy. There are two modes that can be used, Governance-mode and Compliance-mode. The difference between them is that files using Governance-mode can have their Object-lock policy changed by users with the appropriate permissions, whereas files saved in Compliance-mode will persist until the lock period expires. Going even further, there is the option of applying a legal-hold to files which prevents a file from being overwritten and deleted indefinitely.\n\nAmazon S3 Object Lock Overview\n\nSleep Easier\n\nHappy business woman holding an Apple iPad\n\nRansomware is something that we all need to be very mindful of and need to protect against. It only takes one click, or a single vulnerable system to be denied the files you have worked so hard to produce. The cloud(someone else's machine) isn't a silver bullet, and can be compromised just like every other computer, so we need to take proactive steps to minimise any damage that might come. Fortunately, cloud providers like Amazon Web Services provide us with many tools to help safeguard our data and make it less likely that we NEED to pay a ransom just to get our information back. The more measures that we put in place to protect the systems we administer, the more likely we can sleep a little easier in our beds at night.\n\nTake care, Si.