Maintaining Compliance
in the New Era of
Cloud Apps and Shadow Data
Introduction
In the 2H 2015 Shadow Data Report, Elastica Cloud Threat Labs analyzed over 63M documents stored in
popular file sharing apps like Office 365 and Box, and found that 26% of them were broadly shared – that
is shared broadly within the organization or externally. Of these, 1-in-10 were found to contain compliancerelated data, such as PII, PCI, PHI and source code. With partners, third parties and even employees rushing
to deploy cloud apps and services – often without the knowledge or sanction of IT – the risk to companies
from compliance violations resulting from the mishandling or leakage of this data will only continue to
increase. This paper will discuss cloud compliance regulations, the potential costs and risks of violating
them, and the critical steps necessary to ensure cloud data compliance.
Why is maintaining compliance in the cloud critical for today’s
businesses?
“... many [organizations]
IT departments are being forced
out of business necessity to quickly
move to the cloud.”
Software-as-a-Service (SaaS) delivered via the public cloud is one of
the fastest growing IT technologies being tracked by Forrester. They
report that worldwide spending on the SaaS market is expected to
grow at the rate of 21 percent over 2015, reaching $106 billion by
the end of 2016. It’s quite likely that SaaS growth projections could
be even higher if it weren’t for prospective users’ lingering concerns
about protecting sensitive data and compliance. According to
Forrester analyst Liz Herbert, “Security is the No. 1 reason preventing
firms from moving to SaaS.”
However, many IT departments are being forced out of business necessity to quickly move to the
cloud. Even though their #1 concern is governance and security, they’re still moving to the cloud without
an understanding of how they plan on governing and securing it, placing them at tremendous risk of
compliance violations and the resultant fines and remediation costs.
What are the regulations that govern compliance in the cloud?
When enterprises make the decision to adopt cloud apps and services, they are choosing to hand control
of their data to third-party cloud service providers. For some types of data, this is not a problem, but for
consumer financial data, patient medical records, sensitive product-related data, or personally identifiable
1
Copyright © 2014 Elastica, Inc. | www.elastica.net
information (PII), the cloud introduces a series of complex compliance challenges. As a result, data
compliance and privacy professionals take a keen interest in how data is being treated in cloud apps and
services. Violations of these regulations can result in heavy fines.
Compliance regulations fall into three broad categories:
Data residency/privacy legislation – laws in specific states, countries or governmental associations such
as the European Union (EU) that dictate that sensitive or private information may not leave the physical
boundaries of the country or region (residency), and that the information should not be exposed to
unauthorized parties (privacy). Example legislation includes:
•
The United Kingdom Data Protection Law
•
The Swiss Federal Act on Data Protection
•
Russian Data Privacy Law
•
The Canadian Personal Information Protection and
•
Electronic Documents Act (PIPEDA)
The EU Data Protection Directive is also an important piece of data privacy legislation that regulates how
data on EU citizens needs to be secured and protected. With the European Court of Justice’s ruling in 2015
that the Safe Harbor framework is inadequate to protect the privacy rights of EU citizens when their data is
processed in the United States, data privacy professionals expect to see additional data privacy legislation
and restrictions appear across Europe.
Industry-specific compliance requirements – laws or mandates covering a specific industry, type of
business or government agency that prescribe the appropriate treatment and security of private or sensitive
information. Examples of these types of requirements include:
•
The Health Information Portability and Accountability Act (HIPAA)
•
International Traffic in Arms Regulations (ITAR)
•
The Health Information Technology for Economic and Clinical Health (HITECH) Act
•
The Payment Card Industry Data Security Standards (PCI DSS)
Third party obligations – agreements among business partners that outline how a party such as a
contractor or vendor will handle and treat private or sensitive data belonging to another organization. Such
agreements often hold the external party accountable for securing the data in the same fashion as the
owner of the data, including adherence to all residency, privacy and compliance requirements. For example,
a contracted agency performing billing for a hospital in the U.S. must observe all the data protection
requirements mandated by HIPAA and HIT.
In view of all the residency and compliance requirements that companies face, it’s a challenge to strike a
balance between safeguarding sensitive data and attaining maximum benefit from SaaS applications. Given
the strict nature of compliance requirements and the penalties for exposing sensitive data, enterprises and
2
Copyright © 2014 Elastica, Inc. | www.elastica.net
organizations need to ensure that they meet specific requirements in the cloud.
CASB solutions are playing a critical role in helping compliance and security professionals achieve this by
ensuring:
•
cloud apps and services have the appropriate security certifications.
•
certain clouds are blocked from receiving specific types of regulated data.
•
regulated data, that does legitimately need to be placed in the cloud, is secured per
compliance guidelines.
If I restrict my employees to only use mainstream enterprisegrade SaaS apps, won’ít that solve the compliance problem?
To date, the security focus has been on unsanctioned third-party cloud services used inside the
organization – what we know as Shadow IT. But what is actually much more crucial from a data governance
and compliance perspective, is Shadow Data. Shadow Data refers to all the sensitive content that users are
uploading, storing and sharing via cloud apps—often without the oversight and knowledge of IT or security
personnel. In other words, just because an organization has selected a robust file sharing app, like Box or
Office 365, does not mean they are out of the woods in terms of data governance or compliance liability.
Even with the adoption of more secure cloud apps, we find that organizations often have no understanding
of where the actual data is, how it is classified, or how it is being shared. And this understanding is a
prerequisite to understanding what regulatory mandates are in scope and the potential risk exposure of that
data can pose to the organization. In the 2H Shadow Data Report, Elastica found that approximately 10%
of cloud-stored documents actually contain compliance related data. We can break that down even further.
48% of these compliance relevant files contain source code, 33% contain PII or personally identifiable
information, things like Social Security numbers. 14% contain PHI, or protected health information that might
constitute a violation of HIPAA, the health information portability and accountability act. 5% contain PCI, or
A user broadly shares
185 files
on average
SSN
CODE
48%
PII
33%
PHI
14%
PCI
5%
payment card information. And these statistics were taken from applications that were actually sanctioned
and approved.
Compliance in the context of public cloud is not just about understanding Shadow IT, but about having
visibility into Shadow Data.
3
Copyright © 2014 Elastica, Inc. | www.elastica.net
What role does tokenization and encryption play in cloud
compliance?
It is simply not an option to place clear text data in the cloud, as
this would violate the data protection tenets in a variety of ways.
For one, the SaaS provider may process or store data on servers
“... SaaS providers rarely accept full
(either primary or in backup locations) that are not physically located
accountability in their SLAs for the
in a region that is covered by strict data residency laws. Next,
security of their customers’ data,
employees of the SaaS provider have access to the data as they
leaving the customers with full
perform routine processes and maintenance, such as data backups
liability in the event of a breach.”
or server upgrades, and these employees are frequently located in
other regions. This incidental access, though necessary under the
SaaS provider’s service level agreement (SLA), still violates strict policies or regulations covering who is
authorized to view or handle the data. And finally, SaaS providers rarely accept full accountability in their
SLAs for the security of their customers’ data, leaving the customers with full liability in the event of a
breach.
Under these circumstances, organizations have a choice to make: say “no” to the cloud and its numerous
collaboration and efficiency benefits, or find the means to definitively address the residency and
compliance issues when working with sensitive data. Given that SaaS computing has become a multi-billion
dollar business globally, it’s clear that organizations are finding ways to protect their data in the cloud –
some more useful than others depending on the situation and the design.
The issues discussed above largely stem from data being “in the clear.” Anyone who can access the data,
whether they are authorized to do so or not, can clearly see the meaning and values of the data. The way
to resolve this problem is to “obfuscate” the data – that is, make it unreadable or meaningless so that if the
data is breached, it’s unusable by the intruder.
Encryption
Encryption is the process of using an algorithmic scheme to transform plain text information into a nonreadable form called ciphertext. The mathematical algorithm that turns plain text into ciphertext, or vice
versa, is called a key.
It’s possible to use a single key to both encrypt the information and to decrypt (or unencrypt) it and return
the information to its original plain text format. In practice, however, it’s much more secure to use one key to
encrypt data and another separate key to decrypt it. An even better practice is to use a unique pair of keys
for each field of data being encrypted. This multiple key practice provides an extra level of security, so that if
one field is compromised, the others around it aren’t.
Tokenization
4
Copyright © 2014 Elastica, Inc. | www.elastica.net
Tokenization is the process of randomly generating a substitute value, or token, that is used in place of real
data, where the token is not computationally derived in any way, shape or form from the original data value.
The most common form of tokenization uses a highly secure lookup table (called a vault) to keep track of
the relationships between real data and the substitute token values.
Because tokens are totally random, there is no relationship among them. Guessing one token doesn’t get
an intruder any closer to figuring out any of the other tokens. There’s no key or computation that unlocks
all the tokens once an intruder has figured one out. Tokenization is viewed as the strongest way to use
replacement data for original clear text values. With encryption, the value of an encrypted field is reversible
to get to the original value; with tokens, there’s no reversibility.
Encryption vs. tokenization – which should I choose?
As they make plans to adopt SaaS applications, user organizations have to consider when to use each
of these two obfuscation techniques. There’s no clear indicator of when one solution is any better
than the other. Encryption and tokenization are not necessarily competing technologies; they are often
complementary to one another. In fact, encryption is an essential component of a tokenization solution
because every token server relies on encryption and associated key management to safeguard data in the
token vault.
An Organization Needs to Consider:
•
What are the objectives of the business process using the SaaS application?
•
What information needs to be secured?
•
How will that data be used?
•
What regulations, policies and other external requirements drive how we handle our data
and do they specify a certain obfuscation approach?
Some mandates and regulations dictate that encryption must be used to safeguard the data. This may
be more a factor of the newness of tokenization as an obfuscation technique than it is a statement of
the effectiveness of tokenization or encryption. While encryption has existed for decades, tokenization
as a viable technology has only existed since about 2005. As mentioned earlier, the most common use
of tokenization today is to meet PCI DSS compliance requirements. However, as of the writing of this
document the PCI DSS specifications do not say anything at all about tokenization. (The PCI Security
Standards Council is only now considering tokenization as an added security measure.) That said, a user
organization must still consider if it is under a mandate to use encryption as a specific security solution.
Encryption has advantages over tokenization in certain circumstances. As discussed earlier, organizations
willing to accept less stringent obfuscation approaches can weaken encryption algorithms in order to
support specific functionality in a SaaS application. (Note that this is not permissible for U.S. federal
government agencies or their contractors that must adhere to the FIPS 140-2 standard.) Tokenization
5
Copyright © 2014 Elastica, Inc. | www.elastica.net
solutions also require more storage capacity than encryption solutions, so this needs to be taken into
consideration for use with large databases.
Similarly, tokenization has its advantages over encryption in certain circumstances. It is most helpful in
meeting residency/privacy requirements which prohibit data – in the clear or as ciphertext – from crossing
a physical border. User organizations that must keep sensitive data
within a specific country or region can do so by securing the real
“Given the right security platform,
data in a token vault on premise while placing meaningless tokens
the organization may be able to
in the cloud. What’s more, for common SaaS data storage and data
validation, tokens are generally better than encryption at maintaining
use one product that can tokenize
format requirements such as field lengths and character validation.
one field or fields and encrypt
others based on specific business
needs.”
In addition, there are operational factors to consider. Encryption
requires key management, rotation, custodians, policies, and so on.
Tokenization requires the careful management of the token database
(and the infrastructure to support a token database). Many organizations find that tokenization is less taxing
to manage from an IT perspective, but others have automated key controls and existing policies and tools
that facilitate the use of encryption.
An organization can use a hybrid approach, using both tokenization and encryption to safeguard data; it
doesn’t have to be an either/or proposition. Given the right security platform, the organization may be able
to use one product that can tokenize one field or fields and encrypt others based on specific business
needs.
What is the liability companies have from using various
cloud apps, and should the cloud provider shoulder any
of this responsibility?
The most pressing security issue for cloud service providers is protecting the back-end infrastructure from
outside attacks. But organizations also have to be concerned about front door attacks. For example, user
accounts getting compromised via phishing attacks or through a device being lost or stolen are cause for
alarm. It is also important not to forget that not every threat originates from the outside. Malicious insiders
might try to access sensitive data. Or you could also have a situation where an employee accidentally
shares data with someone who wasn’t supposed to access it.
Unfortunately, we cannot reasonably expect that cloud service providers will assume responsibility for
providing more comprehensive data security capabilities for customers. Indeed, many cloud providers take
a shared responsibility approach – they are responsible for the infrastructure, the customer is responsible
for managing how documents are being shared.
In regulated industries, you have an obligation to manage compliance related data yourself. If you’re
6
Copyright © 2014 Elastica, Inc. | www.elastica.net
in banking, FFIEC says you should treat the cloud like any other third-party application – it needs to go
through a vetting process, it needs to go through security, and it needs to follow change management.
But there are also other things to be concerned about. For instance, using Dropbox and Google Docs can
cause compliance related data to end up on the Internet. The truth is, if they need to share a large data
file that won’t go out through corporate email, end-users will leverage these content sharing platforms
to solve the immediate business problem, not realizing or perhaps not caring that they are also creating
a compliance and/or security issue and introducing significant risk to the company. When sharing this
data over large portals like this where anybody can get it, cloud app
vendors will tell you they have no liability for the data loss – all of the
liability is yours. That poses a huge problem with respect to the FTC,
“[corporate IT compliance and
the most active federal agency actively regulating privacy and data
security professionals] are
responsible for data that is entirely
out of their control with users who
may or may not be following the
rules, even though they are flying
completely blind.”
security since the late nineties.
Virtually all cloud app vendors will tell you that if your company gets
breached, it’s your responsibility – not theirs. A lot of that is going to
change in Europe with regard to updates for EU privacy directives
that share culpability for data breaches and mandate violations with
both the data controller and data processor – it will also be the cloud
vendors’ problem, not just the European data owners’ problem. But,
that will probably not happen in the US, so organizations will not have as much leeway in risk transfer or risk
sharing as cloud application adoption grows.
So, the onus will continue to fall on corporate IT compliance and security professionals to make sure that
they are securing cloud apps. They are responsible for data that is entirely out of their control with users
who may or may not be following the rules, even though they are flying completely blind.
What industries are most affected by cloud compliance
issues?
Healthcare organizations, for one. Many healthcare organizations are looking to take advantage of new
cloud-based clinical and support applications that improve patient care and collaboration while reducing
costs. Yet, concern about patient data security is keeping many of these organizations from fully utilizing
these new solutions. Breaches of healthcare data are common due to the high value that stolen medical
records command – and the costs of a breach, at $359 per lost or stolen record, are especially high. Clouds
that aggregate information from many organizations only add to the concern because they make for bigger,
more lucrative targets. As a result, healthcare organizations either find themselves trapped on legacy
systems. or, when they do move to the cloud, they adopt private cloud solutions that are far more costly and
inefficient than their public-cloud counterparts.
Surprisingly, financial services firms have also begun adopting cloud quite heavily. Things like lower cost
and improved manageability have been their key drivers. Financial services firms are looking to the cloud
7
Copyright © 2014 Elastica, Inc. | www.elastica.net
for both state-of-the-art functionality and a pay-as-you-go model that will allow them to add new features
without capital expenses. Traditionally, a key inhibitor for migrating over to the cloud has been compliance,
mainly because any type of regulated industry like finance has to be able to have or maintain some level of
granular logging capability and must be able to provide details of how applications are being used.
That being said, virtually all industries are vulnerable to data compliance violations, as most organizations
have some compliance related data exposed in the cloud – be it customer PII, source code, IP or legal
documents.
How can I ensure my cloud vendors conform to the necessary
compliance guidelines?
Many internal and external compliance guidelines specify that regulated data can only be placed in clouds
that have baseline levels of security in place. Some representative examples of security certifications for
compliance include:
•
Statement on Standards for Attestation Engagements (Length SSAE) 16 Service
Organization Control (SOC) 2: The dimensions along which SOC2 compliance is
measured include security, availability, processing integrity, confidentiality, and privacy. An
organization that meets the relevant criteria is demonstrating to its customers that it offers
essential safeguards with regard to how it handles customer data.
•
Format ISO 27001: As a widely recognized industry standard, adherence to ISO 27001
represents that an organization’s Information Security Management System (ISMS)
complies with ISO 27002. Akin to SOC2, the best practices entail that organizations take a
systematic approach to evaluating their own information security risks and have accounted
for threats as well as vulnerabilities in the process. Beyond that, the standard entails the
design and implementation of information security controls and ongoing management
processes to mitigate these risks appropriately.
•
Cloud Security Alliance (CSA) Cloud Controls Matrix (CCM): Drawing from other
standards, such as ISO 27001, the Cloud Controls Matrix developed by the Cloud Security
Alliance provides a cloud-centric security control framework geared towards helping
organizations assess the risk of the cloud services providers they use.
Companies need to ensure that their cloud providers conform to the company’s compliance guidelines.
For example, most information security-related compliance regimes include language around password
authentication. As part of that, they may mandate the use of mechanisms like strong passwords and twofactor authentication. If an organization needs to comply with one of these regimes, then they need to
ensure that the cloud service provider they employ also offers the same mechanisms.
8
Copyright © 2014 Elastica, Inc. | www.elastica.net
How do traditional compliance strategies fit into my cloud
compliance strategy?
If many of your applications are hosted in the cloud, you need to ensure identity and access management,
endpoint management, system development, and cycle management. Just because you migrated to the
cloud doesn’t mean you’re not responsible for these anymore. In fact, you have actually made your job a
little bit more difficult. At the end of the day you have no idea how Google runs Google. You have no idea
how Salesforce run salesforce.com. So you have to trust what they are doing is correct.
Trust, however, is not a control. So if you think the cloud is getting you out of doing all of the processes that
are required for compliance, it’s not. Now you have to deal with a third party to answer all of these questions
that you could’ve answered yourself had that application been in-house.
“The cloud is a shortcut to
provisioning, but it’s not a shortcut
to documenting the effective
implementation of data compliance
and security controls.”
The idea that you can provision a server in the public cloud in seven
minutes, that’s awesome. But where you may have saved two to
three days on getting a server live, you cannot cut corners on data
classification or risk management. It is still going to take you a lot of
time to figure out where this thing is going to go, how you’re going to
manage it, what kind of security you’re going to put it under, and what
kind of users can attach to it. The cloud is a shortcut to provisioning,
but it’s not a shortcut to documenting the effective implementation of
data compliance and security controls.
And if we talk about the migration requirement, the old strategies are not the same in the cloud. You can’t
just look at your business continuity and disaster recovery plan to determine what goes into the cloud,
because that would tell you development time doesn’t count. Nor can you say that business continuity and
disaster recovery are critical and should stay in-house, but everything else should go to the cloud. You have
to rethink this. How important is this data? Do you want production data in the public cloud with no controls
around it? Of course you don’t.
So you can’t think of your old traditional ways of what is important and what is not. You really have to
lean on data classification to sort that out. Classification in the cloud is entirely different, and monitoring is
absolutely important. You can’t manage what you don’t measure. You have to understand your classification,
and monitor what’s in the cloud, how it’s being used, where it ends up, and who has access to it. Without
this, you open yourself up to a level of risk that you probably can’t tolerate.
From a technical perspective, why can’t I simply use my
existing security and compliance tools in the cloud?
Traditional enterprise applications were typically deployed on-premises, sanctioned, and deployed by IT
organizations, and protected within a well-defined boundary. Security management was something like
9
Copyright © 2014 Elastica, Inc. | www.elastica.net
a security operation center (SOC), which in itself was fueled from data collected from a stack of security
offerings. Those security offerings included things like IDS/IPS, risk and vulnerability assessment tools, data
loss prevention (DLP), firewalls, SIEM solutions, eDiscovery, and network forensics.
Today we are seeing a world where applications like SAP, Oracle, SharePoint, and Exchange are being
replaced by cloud services like Salesforce, Box, Office 365, and Gmail. So on one hand, deployment is
simpler, but on the other, you lose visibility. Suddenly you have an
end-user using a non-enterprise owned device, transmitting data to
a non-enterprise managed server, over a non-enterprise controlled
“... we ultimately need to develop
network, and all of that is being facilitated by a non-enterprise app. It
the cloud analogs of all of the key
is a perfect storm of security concerns.
pieces of the traditional security
stack.”
But those concerns are ultimately predicated on the lack of visibility
that traditional enterprise technologies had. When it comes to the use
of cloud services hosted on public cloud infrastructure, we ultimately
need to develop the cloud analogs of all of the key pieces of the traditional security stack. For example, we
need the cloud analog of discovery and network forensics. That would constitute some kind of investigative
application that would provide continuous monitoring and logging capabilities, helping answer important
questions around how cloud related incidents took place.
And when it comes to things like firewall and DLP capabilities, the cloud based analog could be some type
of application that would enable you to do policy enforcement at a level of granularity that the typical Next
Gen Firewalls don’t give you.
For something like IDS/IPS, the analogous functionality in the cloud would be some kind of application that
would help you to detect whether an outsider had compromised a cloud account, where a legitimate cloud
session was somehow corrupted by malware, or whether you an insider engaging is nefarious behaviors.
What are best practices for managing compliance risk with
regards to the cloud?
How do you secure your sensitive customer information? The following best practices will help you get
started.
Ensure your cloud apps and services are certified.
Make sure your cloud apps and services have the necessary certifications and security functionality. You
can use a Cloud Access Security Broker (CASB) solution to analyze the credentials of existing sanctioned
and unsanctioned (shadow IT) cloud apps to make sure they comply with any external or internal data
security requirements.You should also restrict access to those cloud applications that cannot be brought
into compliance.
10
Copyright © 2014 Elastica, Inc. | www.elastica.net
Understand your cloud data.
Understand if regulated data is being placed in cloud applications and make sure there is a legitimate
business reason for placing it there. a CASB solution that uses data science and natural language
processing to classify Shadow Data. This can help ensure that sharing of regulated data or information that
has been classified as sensitive is properly controlled and managed. In situations where the data does not
need to be there, use the CASB to set policies that block it from being placed in the cloud. This limits the
organization’s points of exposure and reduces the chances of running into costly and complicated data
compliance issues.
Make sure the right security policies are in place when business needs dictate that regulated data must
be stored and processed in cloud apps.
To assist with compliance, put additional data protection policies in place such as tokenization or encryption.
In addition, take advantage of solutions that limit access to this data to only those business users that really
need to see it. Monitor actions taken against this data and maintain these logs for auditors and compliance
assessors.
Do as much awareness training as you can.
The idea that everybody knows the cloud because we all have an iPhone, is not true. We call awareness
training ‘engaging the human firewall’.
Adopt a solid security framework.
As far as regulations are concerned, FedRAMP is one of those you want to pay attention to as it talks about
virtualization hypervisors, privacy in shared data centers, and it is a requirement if you are a cloud provider
today. And if you want to work with the federal government, you have to be FedRAMP compliant. FedRAMP
compliance is a little over 1,100 data audit points – 1,100 different tests that need to be performed on the
environment. It takes about six months to get compliant. Right now there are only 23 companies that are
actually FedRAMP compliant – that’s how hard it is to do. The federal government won’t go into a data
center that’s not FedRAMP compliant.
Security frameworks are another great way to see if we are doing what we are supposed to be doing. The
one that counts here is the Cloud Security Alliance. This is the UK’s version of the FedRAMP document, and
there is actually a 100% overlap. The CSA one is more from a practitioner perspective, rather than an auditor
perspective. Together those two documents tell you exactly what with the expectation should be for a cloud
provider, or your own data center where you are using it as a private cloud.
Understand what data assets you need to have in the cloud.
You need a clear understanding of what data you need to have in the cloud. If you must keep sensitive or
regulated data in the cloud, classify it with the correct sensitivity level. Later, perform an audit to confirm that
the proposed security treatment and risk mitigation strategies have been implemented.
Implement data classification and link management.
Understand what is in the cloud and the associated risks, and mitigate them. We can mitigate risk by
monitoring the cloud and making sure we have single sign-on and dual authentication.
11
Copyright © 2014 Elastica, Inc. | www.elastica.net
Define what systems, people and processes need access.
To select appropriate technical controls and activities to protect confidential data that must be accessed via
the Cloud, map out how the information flows over time and how multiple applications and people access
and process it for various purposes.
Develop internal data governance and risk management policies.
Clearly define your firm’s privacy and security policies. These policies should determine what data you
need to protect – and what you don’t need to protect. Never compromise internal security best practices
designed to ensure data control, confidentiality and privacy when using shared IT infrastructure through a
Cloud Service Provider.
Determine the relevant external data privacy security requirements.
One example of the many types of regulations that apply to the financial services industry is Gramm Leach
Bliley. GLB requires firms to establish standards for protecting security and confidentiality of customers’
personal information. Section 501 (b) says these standards must secure privacy of customer info and
records; provide ongoing protection against threats and prevent unauthorized access and use of customer
data. The Financial Privacy Rule requires firms to provide an annual notice to customers explaining how
their data is maintained and shared as well as the steps they take to protect it. The Safeguards rule requires
them to implement an information security program.
While the act does not prescribe methods for meeting these requirements, one of the measures it
recommends is encryption of electronic customer information.
Similarly, in Australia, the Office of the Australian Information Commissioner has set out the National Privacy
Principles (NPP) that cover the process of collection, use, disclosure, access, correction and identification
of personal information. These require reasonable security and rigorously control data that flows across
Australian borders.
Separate duties.
Putting encryption or tokenization in the hands of cloud service providers can leave your enterprise open to
additional risks of data disclosure. A best practice for data privacy and governance is segregation of duties.
If you encrypt/tokenize data, don’t give the provider (where the data resides) access to the encryption key
or token vault.
Secure data at rest, in-motion and during cloud-processing.
Discussions about cloud security and privacy often focus on the service itself, as well as the cloud service
provider’s privacy and security quality and practices. But it is essential to also secure data as it flows in and
out of the cloud as well as when it is being processed in the cloud. Thus, another best practice is to secure
not only data at rest but also and data in motion (while it is traversing to the cloud as well as when it is
moving within the cloud). Data at rest is data in storage – whether that’s in the cloud, on premises or when
using a Cloud Data Protection Platform, in the platform. Data in motion is data in transit between the end
user and the application as well as when it is being processed within the cloud application (i.e. a report is
being generated).
12
Copyright © 2014 Elastica, Inc. | www.elastica.net
Ensure that your applications will remain fully usable.
In some cases, adding security makes the application unusable for business users. Server-based
encryption can “break” application functionality that end users depend on, such as the ability to search and
sort information or to create reports and send cloud-based e-mails. Make sure security preserves all of the
functionality your users need from the cloud application.
Take advantage of existing investments.
The solution should leverage your existing infrastructure as much as possible. It should interoperate with
the other security layers within your enterprise, such as SSO/IAM. In addition, make sure it supports multiple
cloud applications. This allows you to use the same deployment hardware and software to protect all your
cloud applications and centralize and automate data protection policy management for consistency.
Leverage existing training and expertise.
Organizations have existing investments not only in technology but also in training people on that
technology. For example, they may already have a key management system in place. Be sure that the
solution allows you to leverage any investments you’ve made in your human capital.
Conclusion
Ultimately, cloud adoption is only going to grow and the trend is not going to be reversed. But adoption can
only be done securely if you maintain visibility and control over the authorized and unauthorized cloud apps
and services running within your organization, classify the data stored in them, and maintain an effective use
policy that ensures that sensitive and compliance related data isn’t maliciously or inadvertently exposed.
About Blue Coat & Elastica
Blue Coat is a leader in advanced enterprise security, protecting 15,000 organizations. Through the Blue
Coat Security Platform, Blue Coat unites network, security and cloud, providing customers with maximum
protection against advanced threats, while minimizing impact on network performance, and enabling cloud
applications and services. Blue Coat acquired Elastica, the leader in Data Science Powered™ Cloud Access
Security, in November 2015. The Elastica CloudSOC™ platform from Blue Coat empowers companies to
confidently leverage cloud applications and services while staying safe, secure, and compliant. Blue Coat
was acquired by Bain Capital in March 2015.
For additional information, please visit bluecoat.com and elastica.net
13
Copyright © 2014 Elastica, Inc. | www.elastica.net