Editor’s Note: As of January 2022, iland is now 11:11 Systems, a managed infrastructure solutions provider at the forefront of cloud, connectivity, and security. As a legacy iland.com blog post, this article likely contains information that is no longer relevant. For the most up-to-date product information and resources, or if you have further questions, please refer to the 11:11 Systems Success Center or contact us directly.
Of course, we welcome talking to all our customers directly about this or other compliance questions, so please don’t hesitate to reach out.
Defining Cloud and DRaaS
Firstly, it is important to define what aspect of cloud is being discussed. In this case, we are referring to Disaster Recovery as a Service or DRaaS. In laymen’s terms, DRaaS can be explained as follows:
If the primary location which houses your origination’s computing infrastructure has a disaster that impacts its ability to operate, you may perform a failover to a secondary location to maintain your systems and allow for continued operation. The difference is that the secondary location is virtual and not physical. There is no machine sitting in a datacenter awaiting usage but a series of virtual machines that have been replicated through a process wherein the organization’s production environment is copied in either a real-time or time snapshot manner and stored within the cloud provider’s platform awaiting usage.
This model has multiple benefits over traditional DR, including removing the need to purchase hardware and pay for the operation of a secondary location. Additionally, the DRaaS service itself can be shifted to different geographical locations so as to avoid, for example, a hurricane that would impact a large region, and adhere to data sovereignty regulations. Moreover, through the use of encryption, data is secured to the owner, and access is secured using authentication keys that the customer owns ensuring that once again, the replicated machines are secured from third parties.
Governing Regulations Pertaining to Cloud and DRaaS
The Federal Information Security Management Act (FISMA) is legislation that defines a comprehensive framework to protect government information, operations, and assets against natural or man-made threats. FISMA was signed into law part of the Electronic Government Act of 2002 and provides guidance for government entities on levels of encryption and implementation requirements.
- Federal Information Processing Standards (FIPS) 200: Minimum Security Requirements for Federal Information and Information Systems
- NIST Special Publication 800-53r3: Recommended Security Controls for Federal Information Systems and Organizations
- NIST Special Publication 800-78-1: Cryptographic Algorithms and Key Sizes for Personal Identity Verification
- NIST Special Publication 500-293: US Government Cloud Computing Technology Roadmap Volume I- High-Priority Requirements to Further USG Agency Cloud Computing Adoption
Specific NIST Guidance Disaster Recovery and Business Continuity for Cloud
NIST Special Publication 500-293 gives pathways for organizations to use DRaaS:
5.3.8 Business Continuity and Disaster Recovery
Description: In traditional IT operations, business continuity planning (more specifically, contingency planning) is complex, and the effectiveness of its implementation is difficult to test and verify. More often than not, when disasters occur, unexpected disruptions create confusion and result in less efficient recovery practices. Cloud computing increases complexity to the IT infrastructure and obfuscates responsibility between cloud provider and consumer. This elevates the level of concern related to business continuity and disaster recovery in a new paradigm such as cloud computing.
Importance: Identifying an effective Contingency and Disaster Recovery Plan is imperative to securing information systems and is a required deliverable of the Risk Management Framework and Certification and Accreditation Process.
Mitigation 1: Consistent policies and procedures, as in the case of all IT services. This includes taking action to:
- Develop a contingency plan for a cloud-based application or system using guidelines in NIST
SP 800-34 Rev 1 and in Domain 9: Contingency Planning, Federal Cloud Security Guidelines (if published);
- Determine ownership, data sensitivity, cloud service and deployment models, roles and responsibilities;
- Specify Recovery Point Objective (RPO) and Recovery Time Objective (RTO);
- Set recovery priorities and map resource requirements accordingly;
- Provide a road map of actions for activation, notification, recovery procedures, and reconstitution;
- Enforce policies and procedures through SLAs;
- Incorporate the consumer contingency plan for individual application and/or system into the cloud provider’s overall contingency plan;
- Establish management succession and escalation procedures between cloud provider and consumer; and
- Reduce the complexity of the recovery effort.
Mitigation 2: Ensure that requirements traditionally met through the following clustering and redundancy mechanisms are addressed:
- Shared storage clusters;
- Hardware-level clustering;
- VM clusters; and
- Software clustering (application servers and database management systems).
Mitigation 3: Ensure requirements met traditionally through alternate sites and backup are addressed. NIST SP 800-53 Rev3 recommends:
- Alternate storage and processing sites;
- Alternate telecommunication services;
- Information system backup;
- Provide cold, warm and hot backup sites (economies of scale);
- Outsource information system backup to a cloud backup service;
- Use multiple cloud providers; and
- Supplement cloud provider’s backup schemes with consumer’s non-cloud sites.
Mitigation 4: Ensure effective testing and exercises are conducted. This includes exercising the contingency plan periodically to verify its effectiveness (including personnel training) and confirming that it is updated to reflect changes in any of the dependent factors.
The service provider and consumer should plan to perform joint contingency plan testing and exercises against high-level disruptions to discover deep-rooted risks.
The service provider and consumer should plan to perform joint testing in business and service provider production-like environments to exercise contingency plans.
11:11 Systems Implementation of HIPAA/HITECH and FISMA
11:11 Systems operates in FISMA spaces adhering to regulations with third party independent auditor oversight ensuring that encryption, staff background checks, physical controls, access controls, risk analyses, role-based least access, and data sovereignty meet requirements. Additionally, customers may request extensive logging information to ensure activities performed operate within the confines of their data requirements.
This just touches on one aspect of the compliance-cloud challenge. We work with healthcare companies bound by HIPAA, companies dealing with Safe Harbor implications, and more – so please, reach out at Contact Us
