54 DISASTER RECOVERY JOURNAL | SUMMER 2016
loads even existed in the environment.
This happens all too often, as highlighted in a recent study by Enterprise
Management Associates that uncovered
a significant gap in IT’s understanding of
compliance requirements and compliance-related workloads (see Figure 1).
While 96 percent of the security personnel surveyed reported their organization has compliance-related workloads in
the cloud, only 69 percent of IT personnel
reported the same. These types of oversights and misunderstandings can expose
companies to risks and fines should they
fail over to non-compliant cloud.
Securing the DRaaS
The primary items on the wish list
of most disaster-recovery-as-a-service
enthusiasts are around recovery times and
recovery points, locations, service levels,
and ease of implementation. All these are
rational, solid requirements. But a big area
is missing: security.
What happens to your workloads once
they have failed over? Once the dust has
settled, the continuity has been achieved,
and they hum along in the cloud for days
or weeks or months until it’s safe to bring
All the same security safeguards – or more
– would be protecting your workloads in the
Implementing these controls would be
seamless as part of the failover since no
one has time in an emergency to configure
Documentation of all of the security
technologies would be built-in and available
Since a large part of most IT audits has
to do with verifying the presence, use,
and success of security technologies, this
eschews a great deal of the struggle. Armed
with this data, our heroes would be most of
the way to vanquishing the auditor.
Except for one thing: is the cloud itself
The Web Site says Compliance
You own the workloads in the cloud.
They are yours. No cloud worth it’s vapor
would tamper with, disable, or destroy
your workload. So, as discussed above, the
security of your workloads is up to you.
The cloud facilitator can embed the tools
and provide the reports, but at the end of
the day, it’s your virus to remove.
The platform, however, is not yours.
It’s the cloud itself. While the prevailing
myth of 2005 was that as a cloud user, you
wouldn’t have to bother with the underly-
ing cloud – not the brand of server, not the
type of hypervisor, and not the security
of the data center. Unfortunately, that’s
In the domain of compliance, providers
can achieve various levels of certification
of their platform against varying regulations. While compliance badges feel like
they are distributed like candy across the
industry, the reality is far more convoluted:
Some compliance standards (ISO27001,
PCI) require vigorous third-party audit but
can be targeted at the entire organization
or at a specific location or data center.
u If the data center is targeted, only that
location is compliant and not many of the
overarching corporate practices like HR or
u If the entire organization is targeted, then it
all must comply.
Some compliance standards (HIPAA) have
no third-party governance organization but
can be evaluated in an attestation from a
u Organizations can claim to comply with
HIPAA without having any oversight.
u Others choose to be evaluated and then
have attestation paperwork to prove their
alignment with the standard.
Some compliance standards are still too
hairy to have solid guidelines.