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|
Protect the confidentiality of backup CUI at storage locations.
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.
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.
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.
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.
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).
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
Original Blog: https://info.summit7systems.com/blog/cmmc-recovery
Video Source: https://youtu.be/ORDC7BQfM8w
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.