One of the key areas where the Cybersecurity Maturity Model Certification (CMMC) expands on NIST 800-171 is system recovery, specifically the ability to recover from any event that compromises the integrity and availability of data. Backups are called out in the Recovery (RE) Domain and include the requirement to backup all content, not just CUI and other critical content. Further, testing backups is now a requirement and likely to be validated during a CMMC assessment. Watch the below overview and/or read further.
Backups are important for the Department of Defense (DoD), as well as their vendors within the Defense Industrial Base (DIB), because the loss of sensitive data or a significant loss of operations can adversely impact national security. Practices are included in Recovery (RE) and impact Levels 2, 3, and 5. The focus of this blog will be on Levels 2 and 3, shown below.
| Level 2 | Level 3 |
|
RE.2.137
|
RE.3.139
|
|
RE.2.138 Protect the confidentiality of backup CUI at storage locations.
|
Foundations of Recovery
What do I need to backup?
You need to backup systems containing CUI, intellectual property, and any other data source that could render your company non-operational in the event of a failure or cyber attack.
How long should I hold backups? How frequent should I backup?
Recovery Point Objective (RPO)- Your organization needs to map each system and define what is the maximum acceptable data loss, expressed as a percentage subtracted from 100, and the ideal restoration point. If you run daily backups only and ignore the SQL Server transaction logs, then your RPO is 23 hours, 59 minutes, and 59 seconds. Any data written to that database after you ran the backup cannot be restored via native tools until after the next backup. Many organizations assume this risk without fully understanding the impact of losing 24 hours worth of data. Likewise, if you get corrupted files in Office 365 or you have a system breach that modifies versions, the only way to get that data back is via a reliable backup.
Recovery Time Objective (RTO)- The RTO defines how long your system can be down before it is back online after a disruption. The disruption could be due to anything from a SQL Server outage to an AAD Connect Server failure. You don’t have to have the same RTO all of the time. For example, a manufacturer might have a very short RTO from Monday through Friday, 8 A.M. until 5 P.M., but a longer RTO for all other times. The RTO should include data recovery at the tenant, server, database, site, list, and item levels.
You also need to define the amount of downtime you can afford for each system before your company would fail to perform on customer/contract obligations.
Retention Period- Define the period of time you need to retain backups, to delete them or replace them. A one year retention period is common, but longer may be required by contractual requirement for duration. Also, storage expenses may lead you to shorten this period.
What are the major requirements?
The words to hone in on within the requirements: "test", "comprehensive", "resilient", and "protect the confidentiality". If you could boil down the requirements into four categories (besides simply backing up data), these would be it.
Test- Not only do organizations need to test that their backups are complete and functioning properly, IT leaders need to test all failover processes and revisit written policies and SLA's on a quarterly basis as a minimum best practice. For instance, an administrator or IT leader can check on the status of each backup within the Azure Recovery Services Vault.
Comprehensive- Backups need to include all systems containing CUI, which includes systems that contain critical intellectual property (IP), and other data stores that would severely impact your businesses ability to operate and perform on contract. Comprehensive backups include virtual machine image files (VHD) or snapshots and all necessary infrastructure/architecture to fully restore and recover. Azure Backup, for example, can store data copies, configuration information for virtual machines, a server, and workstation workloads. For Office 365 GCC High, you need a means for restoring individual mailboxes, OneDrive files and associated metadata, etc.
Resilient- One of the noticeable changes between the draft and final version of CMMC is the removal of "off-site and offline" from the above requirements. The CMMC team instead added this requirement in the discussion section of the CMMC Appendices and based it upon the Center for Internet Security (CIS) V7.1 Controls. Resiliency is thwarted by single points of failure. Therefore, it is logical to move your backups off the same servers, networks, etc. that could potentially be compromised or negatively impacted (essentially when you would most need a backup). Azure Government for instance traditionally offers two dispersed and resilient backup storage locations: Locally Redundant Storage (LRS) and Geo-Redundant Storage (GRS).
Protect Confidentiality- To ensure CUI and other critical data remains private and unchanged, your organization is required to encrypt storage and implement security protocols to mitigate the risk of storage tampering. If you are using a third party backup SaaS offering, you will want to make sure that you can Bring Your Own Key (BYOK) or have a means for controlling encryption keys with the use of Azure Key Vault and the like. Azure Storage Data is encrypted and decrypted transparently using 256-bit AES encryption, one of the strongest block ciphers available, and is FIPS 140-2 compliant. It is also important to use Role Based Access Control through/with Azure Active Directory to limit just in time access to storage files for the right person and automated approval/notification process.
If I'm in the Cloud, Do I Need Additional Backup?
Outages caused by natural disasters and the like are the least likely failure to occur for an organization that is cloud-only (i.e. Microsoft 365 GCC High and Azure Government for IaaS) due to Microsoft's provided level of redundancy for its services. More commonly, the leading threats causing the need for system backups are user and administrative error. User error encompasses accidental changes made to a site or file to downloading ransomware. Whereas admin errors can consist of mass deletion of files or users to changing a setting which leads to critical accessibility issues.
There may also be limitations on what is actually backed up by your SaaS or PaaS provider, unlike the case with Microsoft 365 and Office 365.
Backing up Office 365 GCC High
If you search "backup Office 365" or "backup Microsoft 365" you are not going to find many informational resources. Nevertheless, Microsoft does provide some elements of comprehensive backup for Office 365 in the traditional sense. Your organization may choose to go beyond what Microsoft provides to enhance your backup strategy. For example, your security and compliance requirements may necessitate the ability to restore any workload (SharePoint, Exchange, OneDrive, Teams, etc.) to a specific point in time.
There are also retention policies within Office 365 to recover some data or prevent losing the data in the first place. You can, for example, recover Exchange data that a user intentionally or unintentionally deletes. Administrators can recover a single deleted item or an entire mailbox worth of files if certain configurations are in place.
If you choose to introduce a third party application to backup sensitive and critical data from all workloads within the Office 365 stack to an offsite and/or offline locations, this software application needs to meet FedRAMP Moderate standards as it will be handling CUI and FCI data in motion and likely at rest, and the final destination of all backups needs to be secure and compliant to NIST 800-171 controls and CMMC practices.
Backing up Azure Data to Azure Government
Many workloads in Azure Government work natively with Azure Backup and can run backups in five clicks or less. Others require additional configuration. As mentioned previously, Azure allows you to determine what type of storage you would like to use based off availability needs and the level of geo-redundancy your team determines to be suitable.
Backing Up On-Premises Data to Azure Government
CMMC allows for data backup on CD's, flash drives, and stone carvings. However, none of these storage locations, along with other on-premises options, can scale or provide the flexibility a modern Aerospace and Defense company requires. By storing on premises data in Azure Government, administrators gain a plethora of first party security tools and policies. For example, Azure Backup for VM's provides a soft delete feature so that a 14 day clock starts for full recovery. This capability can protect your organization from accidental or malicious deletions of your backups. It's very difficult to do this on premises.
You can backup both, physical and virtual machines, running Windows or Linux using a variation of System Center Data Protection Manager (DPM), Microsoft Azure Backup Server (MABS), or Microsoft Azure Recover Services (MARS).
Bottom Line
The best time to plan for content recovery is before you implement a system. Much of your CMMC recovery plan depends on how your information system is implemented. A common bad practice is trying to force stringent recovery objectives from a system that was poorly installed and configured.
Most return to service times are in the four hour range for critical business systems, and 24 hours and longer for generic business systems. While we would all like for service restoral times to be shorter, it is rarely practical or cost-effective to provide them. If your company will go out of business if it is down for 24 hours, then you will require a much more complex system design and failover strategy.
Lastly, there are advantages to using native tools, over third-party tools, in that they are directly supported by the provider (i.e. Microsoft, AWS, etc); however, sometimes the need for a third-party tool is required because nothing natively exists or additional capabilities are offered by a third party tool.
Most importantly: Check your backups
#checkeverybulb
Original Blog: https://info.summit7systems.com/blog/cmmc-recovery
Video Source: https://youtu.be/ORDC7BQfM8w
Updated May 27, 2020
Version 1.0
