How to Build Your Exchange Server Recovery Strategy to Overcome Ransomware Attacks
In this article, you will learn how to build an Exchange Server recovery strategy to deal with a ransomware attack.
Join the DZone community and get the full member experience.Join For Free
Ransomware attacks on on-premises Exchange Servers are quite common as they store sensitive and confidential information and business data. The attackers often exploit vulnerabilities to gain access to the organization's network and steal or encrypt data for ransom.
Even if attackers do not succeed in encrypting the data, they may leave a backdoor or cause other damage that can leave your server unusable or cause permanent data loss. That's why it's important to have a disaster recovery plan or recovery strategy ready to deal with such critical situations.
Steps to Build Exchange Server Recovery Strategy
A ransomware attack on Exchange Server is the worst nightmare for any administrator. It can render the server unusable, leading to downtime and incurring financial losses. Below is the six-step Exchange Server recovery strategy that will come in handy if your Exchange Server is compromised and attacked with ransomware.
1. Identify the Critical Components
In Exchange Server, you must identify the critical components and data that need to be restored after a disaster strikes or a ransomware attack to resume the services. When talking about Exchange Server, you should consider the following for backup:
- Active Directory (AD)
AD is the database used to authenticate users and serve information. It contains important information related to your Exchange Server environment, such as users and computers, their roles, permissions, etc. Therefore, you should back up AD every 60 days or earlier. It is backed up as a part of the system state.
- Mailbox Database
The mailbox database contains the user mailboxes and mail items critical for business, such as emails, contacts, attachments, calendar items, etc.
In addition to the two components, consider backing up the file system and the system state. You may do so by creating Volume Shadow Copy Service-based backups.
2. Choose a Backup Strategy
Backups are critical. Thus, choosing the best backup strategy for your on-premises Exchange Server is important. In Exchange Server, you should use the Native Data Protection (NDP) using DAG instead of relying only on traditional backup technologies.
Microsoft Exchange Server also supports VSS-based backups that you can create using the Windows Server Backup (WSB with VSS-plug in) or an Exchange-aware third-party backup utility. Based on the Exchange Server environment, you can create Full backups, Incremental backups, or Differential backups.
In Full backup, the Exchange database and transaction log files are copied. After a successful backup, the logs are automatically truncated. However, the full backup takes more time to complete as it has to back up the entire database with log files. It also requires more storage to store the backup. Therefore, restoration time is also high.
In Incremental backups, only the specific changes in the transaction logs are copied over the last full or incremental backup. This helps in minimizing the backup frequency and conserve storage space. It also takes lesser time to create or restore the backup when compared to a full backup. The logs are truncated after the incremental backup completes.
Similar to Incremental backups, Differential backups copy specific data. The only difference is that it copies all the changes made since the last Full backup without taking the previous Differential or Incremental backup. This also helps minimize the backup frequency, time, and operations required to restore a database. Although it requires significantly lesser space to create backups, it is more than what is consumed by an Incremental backup. Restore is also faster than the previous two backup methods. The logs are also not truncated and remain the same before the backup.
Important Note: Ideally, you should never combine or implement Incremental backups and Differential backups together. In addition, you also need to disable Circular Logging on your server to allow Differential or Incremental backups.
You may follow the popular 3-2-1 backup rule to create an Exchange Server backup. The rule states that you should create at least three backups on two different storage media and keep at least one copy offsite (maybe cloud), preferably at another data center or branch.
3. Define Recovery Point Objective (RPO)
Defining Recovery Point Objective (RPO) involves determining the amount of data your organization can afford to lose when a disaster strikes or after a ransomware attack. This can be used as a parameter to determine how frequently you need to back up to keep the data loss to the minimum in the most efficient way.
For instance, after a ransomware attack, you will be able to restore data till the time of the last backup. It means any data created after the last backup will be permanently gone. So if you created the last backup at 12:00 AM and the ransomware attack took place at 6:00 AM, the data accumulated or generated between 12:00 AM and 6:00 AM cannot be restored from the backup and is deemed permanently lost.
However, you can recover all the data created between the last backup and when the disaster strikes with the help of an Exchange recovery software, such as Stellar Repair for Exchange. The software can also be used if the backup fails or becomes obsolete or unavailable. In addition, it can repair and extract mailboxes from the affected Exchange Server or corrupt Exchange database files and export them to your new Exchange Server or Office 365 directly. You may also save the mailboxes as individual PST files for backup.
4. Define Recovery Time Objective (RTO)
Similar to Recovery Point Objective, defining Recovery Time Objective (RTO) is also important. It helps determine the maximum time allowed to restore the Exchange mailbox database and services after a ransomware attack or disaster strikes from the last backup.
It basically tells for how long services will remain down. It is usually defined in minutes, hours, or days based on the estimated time required to restore data from backups or with the help of third-party software. You can estimate this time during backup testing. For instance, if it takes an hour to restore 100 GB of data, it may take around 10 hours to restore 1 TB of data. It also helps define the SLAs and meet the set expectations.
5. Test Recovery Plan
Testing the backup and recovery plan is more important than creating one. This will let you know any caveats or limitations and fix them before a disaster strikes. It will also let you know if all the required data is completely preserved and can be restored when needed.
If the test fails, you can review your backup strategy and take the necessary steps to ensure your recovery plan works effectively. It will also help you achieve peace of mind as you know that you can recover data if your organization is attacked by ransomware.
6. Document the Recovery Plan
Once you have the Exchange Server recovery strategy ready, it's time to document each step and component in detail to quickly recover the data when the need arises and restore services after ransomware or malicious attack. It will help respond to the ransomware incident, minimize the effect of a ransomware attack and quickly resume mission-critical operations.
To Wrap Up
Newer vulnerabilities and bugs open new doors for threat actors to exploit and compromise the Exchange Servers. You must patch these vulnerabilities with the latest Security Updates and Cumulative Updates regularly released by Microsoft to keep the attackers at bay. It is also recommended that you follow the best practices to strengthen your Exchange Server security. In addition, you should also create an Exchange Server recovery strategy that will help you recover and restore your Exchange Server and email services when a disaster strikes. This will help you protect your data, save your reputation, and prevent financial losses after a ransomware attack.
Opinions expressed by DZone contributors are their own.