cloud complianceDRaaS

Government Organizations, FISMA and DRaaS

ByDecember 9, 2015

Of course, we welcome talking to all our customers directly about this or other compliance questions – so please don’t hesitate to reach out.

Definining 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:

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 http://www.iland.com/contact-us-compliance
Frank Krieger

Frank Krieger

With a career in IT spanning 16 years and over 10 years of ITIL and compliance background, Frank Krieger manages the iland compliance office in the company’s Houston headquarters. Frank received his degree in Computer Information Systems from Northern Michigan University and has an extensive background in enterprise ITIL and compliance including managing service organizations for Fortune 10 companies. Frank has held ITIL Practitioner status and is currently a certificated ITIL Expert. These achievements represent not only an in-depth understanding of process and service management, but also extensive compliance knowledge. When not busy pouring over frameworks and audit requirements, he spends time traveling with his wife, Jacque, playing with his corgi and is an avid Minecraft player.