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 Disaster Recovery as a Service, or commonly referred to as DRaaS. In laymen’s terms DRaaS can be explained as such:
If the primary location which houses your originations computing infrastructure has a disaster that impacts its ability to operate, you may perform a failover to a secondary location in a very rapid manner to maintain your systems and allow for continued operation;
the difference is that the “secondary location” is virtualized and not a physical location in the sense that there is a machine for machine sitting in a datacenter awaiting usage but a series of virtual machines that have been replicated through a process wherein the organizations production environment is copied in either a real-time or time snapshot manner and stored within the cloud providers platform awaiting usage.
This model has multiple benefits over traditional DR in that you remove the need to purchase hardware and pay for the operation of a secondary location. Additionally, the DRaaS service itself can be shifted at the organization’s request to different geographical locations so as to avoid, as an example, a hurricane that would impact a larger region, as well as adherence to data sovereignty regulation. Moreover through the use of encryption, data is secured to the owner and access is secured using authentication keys which the customer owns ensuring that once again, the replicated machines are secured from 3rd parties.
Governing Regulations Pertaining to Cloud and DRaaS
FISMA
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 and is quite extensive:
- 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 Clodu
NIST Special Publication 500-293 gives pathing for organizations to use DRaaS inclusive of warnings!
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.
iland Implementation of HIPAA/HITECH and FISMA
iland operates in FISMA spaces adhering to regulations with 3rd party independent auditor oversight ensuring that encryption, staff background checks, physical controls, access controls, risk analyses, role based least access and data sovereignty requirements. Additionally, customers may request extensive logging information to ensure activities performed operate within the confines of their data requirements.
As I said, 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
