The 2021 Application Protection report notes that ransomware was a factor in roughly 30 percent of U.S. breaches in 2020. Looking at the breach analyses, we found some of the most important controls were user account management, network segmentation, and data backup. We realize that implementing these controls can be difficult, so this article goes into more detail on what to do.
It’s safe to say that a significant percentage of attackers are only logging into our systems to hack them. They guess passwords, steal passwords, and phish passwords. So, we know that passwords are poor protection indeed. The following sections list ways to fix this.
Best practices, as well as some compliance regulations, indicate to use multifactor authentication (MFA) on all systems holding critical data (see our earlier piece with tips and tricks for rolling out MFA). We know it’s hard, and if you can’t apply MFA to everything, then prioritize. First, all administrative accounts should use MFA. A major attack vector for ransomware is remote access, so that’s the next priority. Given all the critical data people leave in email and that most major email platforms support MFA, adding it to end-user email is the next priority.
Until you can get to 100 percent MFA for all access (hint: look for single sign-on tools to help here), let’s review some of our recommendations from the 2019 Application Protection Report. Based on the NIST Digital Identity Guidelines1, we advise looking into the following measures:
- Make your password policies user friendly.
- Check passwords against a dictionary of default, stolen, and well-known passwords, both when users choose a password and on a recurring basis.
- Never use hints for password resets.
- Use long passwords.
- Avoid arbitrary 30/45/60/90-day password rotations.
- Lock or remove unnecessary credentials.
Strong account management means applying the principle of least privilege. The first priority here is limiting administrative access: the fewer system administrators, the better. And these administrators should not have full access to everything, everywhere. Unless you’re an IT shop of one that works 24/7, divide the responsibilities by region, time zone, or system function. Another powerful technique is to separate the system administrator accounts from their day-to-day user accounts. Admins should use a normal nonprivileged account for such things as reading email, surfing the web, and accessing applications. Then when they need to perform IT administration, they switch accounts or elevate their privileges, and then revert to a normal privilege mode when done. This way, if an admin accidently clicks on a phishing email with ransomware, it won’t wipe out the entire network. Many of these restriction capabilities are configurable within most operating systems.
Service accounts too
What goes for system administrative accounts also goes for service accounts. These are the often invisible accounts that are tied to running applications. For example, a web server or database server might have an actual user account that runs its application service. Being unnoticed and powerful, these services are ripe for attacker takeover. These accounts should restrict rights to only those necessary to run the service. Web servers only need rights to their own service and the file directories, not an entire box or the entire network. Using a generic full admin account as a service account is a disaster waiting to happen. Again, operating systems have some built-in functions to restrict these service accounts, disallowing human interactive logins and tying them only to the servers and services they are supposed to function on.
In some systems, you can restrict service account privilege domains as well. For example, you can set up a backup server to have read-only access to the main domain, so it can copy files for backup. Restores can be done under a different account or manually with a system administrator.
The last part of user account management is monitoring access. All user accounts should be logged for audit purposes in a way that prevents tampering with the logs. Attackers will try to erase their tracks by deleting logs, so your monitoring system should sound the alarm if it detects logs deleted or they stop coming in. It’s also prudent to have the system automatically raise an alert when a system administrator account is created. This should be a rare enough event that false positives are manageable. Also review general user accounts against personnel records to ensure only the right people continue to have access. Lastly, because of the prevalence of brute force and credential stuffing attacks, create alerts for large numbers of login failures.
Ransomware can spread like wildfire on a network, which is why security professionals call their network segmentation devices firewalls. Firewalls can limit infections to specific segments of users, systems, or levels of trust. Virtual LANs, which run on managed switches, can also be a useful fallback if internal firewalls are unfeasible. This is essentially least privilege at a network level. The following are some key tactics for doing this.
Worried about supply chain compromise of your management tools? Set up default deny policies with firewall rules controlling the management servers. Then configure only the specific connections and ports necessary for remote management capabilities to the specific managed system addresses. One guideline to consider is that a remote management system can have Internet access or internal network access, but not both at the same time. Make it harder for an Internet attacker to remote control a server in your environment. The same rule applies for administrative interfaces: limit their access with network rules.
Network traffic can be filtered wherever subnets of different trustworthiness connect to each other, such as wireless networks, remote access gateways, third-party connections, storage servers, Internet-of-Thing devices, backup servers, developer systems, and user networks. Once again, apply least privilege and only allow the defined communication methods to the defined addresses.
The network devices and firewalls that manage network segmentation also need to be patched in a timely manner. Attackers will exploit those bugs and break through, so make sure to keep those devices up to date.
Once ransomware takes hold of your systems, the best course of action is to delete everything and reload from scratch. Attackers know this and will corrupt backup systems as part of the ransomware attack. This means you not only need to have complete and up-to-date backups, but you also need to protect them. Let’s look at how.
Any veteran system administrator knows the 3-2-1 backup strategy, which means having three copies of your data, two of them on different media and one offsite. Basically, you assume breach on your backups and have a backup of your backup. Remember, you need to back up everything, not just data. This means also backing up system images, application software, and configurations. This way you can rebuild servers and workstations, preferably using automation for speed and ease.
The director of IT at one of my early tech jobs used to say that a backup wasn’t complete until you did a test restore. Restore testing should include tests for completeness and speed. It’s one thing to perform a test restore for a few files but another thing to restore hundreds of terabytes. In many cases, a complete restore process can take days to complete. Also, if you are backing up online, such as saving data to the cloud, check your bandwidth speed requirements and costs. Some cloud providers charge much more in transfer fees to download data from their cloud than to upload to it.
A useful thought experiment is to assume that ransomware attackers have access to your administrative credentials as well as your backup server. Can they delete or alter your files? Look into “immutable backups,” which can’t be altered or deleted. The manual version of this is “air-gapped” tapes, which you take offline and lock in a cabinet. But virtual air gaps exist as well.
Most major cloud providers now offer immutable storage options, such as placing a software lock on a file when it’s created. The lock can remain in place for weeks or months to ensure stored files cannot be altered. These locks can both protect against ransomware and meet compliance and legal requirements for tamperproof logs.
Ransomware is a large growing threat to our critical systems. Fortunately, a defense in depth strategy, including strong user account management, network segmentation, and protected backup systems can prevail.