Security & Compliance in the Cloud - Hadoop Magazine Column Version 1.2 by Jarrett Neil Ridlinghafer

CLOUD SECURITY & COMPLIANCE
RISKS
AN ARTICLE FOR HADOOP MAGAZINE COLUMN
VERSION 1.0
MARCH 12, 2014
PREPARED BY: JARRETT NEIL RIDLINGHAFER
SYNAPSESYNERGYGROUP
And Defining Ways to Mitigate Risk

11/12/2013 Cloud Security & Compliance & how to mitigate the risk of using the Public Cloud
CONFIDENTIAL – © 2013 Synapse Synergy Group & Cloud ConsultingInternational
1
Table of Contents
Introduction................................................................................................................................................................................................................................2
Goals ofthis document...............................................................................................................................................................................................................4
The Issues & Risks associatedwith the public cloud,Which Need to beMitigated........................................................................................................................5
Data Transmission and Storage ..............................................................................................................................................................................................6
Encryption & Server Hardening ..............................................................................................................................................................................................8
Key Size - Does Matter!......................................................................................................................................................................................................9
Hardware Key Encryption...............................................................................................................................................................................................10
Software Key Encryption.................................................................................................................................................................................................11
DATA Disk (aka Data-at-Rest) Encryption METHODS.........................................................................................................................................................11
Encryption KEY & DATA MANAGEMENT Appliances .........................................................................................................................................................13
Email...................................................................................................................................................................................................................................13
Email Data Encryption.........................................................................................................................................................................................................16
Storage & Applications........................................................................................................................................................................................................18
Physical Storage..................................................................................................................................................................................................................21
Application Access..............................................................................................................................................................................................................22
Identity Management, Authentication Methodology & Password Policy Enforcement..........................................................................................................24
Group and User ACL’s.........................................................................................................................................................................................................26
Employee Termination Policy ...............................................................................................................................................................................................26
Retention Policy On & Off-site Backups and Emergency Access...........................................................................................................................................27
Disaster Recovery & Business Continuity ...............................................................................................................................................................................29
Cloud Service Provider SLA’s................................................................................................................................................................................................30
CSP Viability and Stability.....................................................................................................................................................................................................32
Legal Reorganizations, Jurisdicional Disputes and Associated Issues of Corporate Data within a Global CSP Environment................................................32
CSP FINANCIAL AND EXECUTIVE STABILITY........................................................................................................................................................................33
Periodic Disaster Recovery & Business Continuity Testing.......................................................................................................................................................34
Scheduled Ongoing Testing............................................................................................................................................................................................34
Periodic FailoverTesting..................................................................................................................................................................................................34
Periodic Backup & Recovery Tests...................................................................................................................................................................................34
D.R. & B.C. Testing...........................................................................................................................................................................................................35
Periodic TSE SLA Testing...................................................................................................................................................................................................35
Written By: Jarrett Neil Ridlinghafer..................................................................................................................................................................................36
Chief TechnologyAnalyst......................................................................................................................................................................................................36
Chief TechnologyOfficer/CTO................................................................................................................................................................................................36

2
INTRODUCTION
Since the coining of the phrase in 1995, “Cloud Computing” has become one of the
leading technology trends, if not the #1 trend since Marc Andreessen invented the first
Web Browser which basically allowed the then little known “Internet” t o become what it is
today. I predict that “Cloud” will be even “BIGGER” than “Mosaic” and yet either directly or
indirectly, the fact is that in one way or another that browser code he wrote and which he
named “Mosaic” has caused the life of every single individual on this Planet Earth to be
effected by it, in one form or another.
This article will be focused primarily on Compliance and Security within the Public Cloud
and will attempt to provide comprehensive policies and procedures for addressing the
Compliance and Security concerns facing Companies looking to enter “Cloud Computing”
in a standardized and well documented manner based on proven and approved
methodologies, practices and principles. The findings and recommendations contained

3
within this whitepaper are based on many hours of research and analysis as well as my
personal experience of 25 years in the industry and 10 years dealing with cloud technology
architecture.
Cloud technology is basically an amalgamation of tools/applications which have been
developed which when combined provide the following benefits:
 Elasticity of resources
o Everything from memory, CPU cycles, disk-space and bandwidth even load-
balancing and routing have become elastic in the sense that an application
and/or customer can use cup cycles from any CPU on any server located
anywhere in the world, it no longer need be physically attached to the same
piece of hardware that the applications is initially installed upon. Indeed the
application itself now, can be located on any server around the world or on
multiple servers at the same time.
 Pay-for-use-only
o You no longer are forced to pay for unused CPU cycles, memory or disk-space
for example, drastically reducing the cost footprint which has made it highly
attractive to enterprise customers as a cost cutting means.
 Highly distributed
o You can have multiple copies of your application scattered all across the
globe, on many different networks, all working to provide a more direct access
to each customer and providing a means for business continuity and disaster
recovery as well.
 Automated Services
o Cloud technology has included tools and applications to help automate most
of the previously manual operations thereby enabling large infrastructures to
me maintained by fewer employees while increasing efficiency overall.
As you can see, the benefits of Cloud technology are or can be when done properly,
absolutely immense. However, this great new technology does not come without some
major flaws and drawbacks, especially at this early stage in its development. For example,

4
one of the largest and most widely used Cloud Frameworks “OpenStack” was just bashed
by multiple analysts as “Not ready for prime-time use by Enterprises” and they go on to
state that Public Cloud technology will not be ready for a few years yet, primarily due to
Compliance, Security and Reliability issues.
This article will endeavor to explore those issues, to expose the weaknesses and flaws and to
suggest solutions and proper procedures to mitigate the risk for each.
For more information about “Cloud Computing” overall you can read about it HERE
GOALS OF THIS DOCUMENT
The goal of this document is to provide a tactical plan outline which can be used to
effectively and safely evaluate and mitigate both security and compliance risks when
selecting a Public Cloud Service Provider or “CSP”
It will present the known issues and the best options available with which to address each.

5
THE ISSUES & RISKS ASSOCIATED WITH THE PUBLIC CLOUD, WHICH NEED TO BE
MITIGATED
There are a number of technical and operational issues that must be considered when
evaluating potential cloud computing solutions. These include:
 Transmission of Data & Stored Data
 Encryption and Server Hardening
 Cryptographic Key and Certificate Management
 Email Security Issues
 Multitenant Storage & Application Access
 Access Authorization, Authentication methods, and Identity Management & ACL’s

6
 Employee Termination Policies
 Retention and Backup
 Disaster Recovery & Business Continuity
 SLA’s & Contractual Agreements
 Legal & Jurisdictional Issues
 Service Provider Long-term Viability and Financial Structure
 Ongoing Testing and Validation
Each of these issues has impact across the entire spectrum of cloud computing services and
we will be addressing them all.
Data Transmission and Storage
Cloud services inherently transmit customer data across uncontrolled internet connections
that are susceptible to monitoring and interception. Indeed, just within the last 30 days the
NSA (National Security Administration) was caught effectively “taping” the data lines of
three of the world’s largest cloud computing companies as they transferred data between
data-centers. While most cloud based services utilize some form of encryption either via
web-based communications (e.g. SSL or TLS over HTTPS) or through a proprietary client to
server application, the effectiveness of the data transmission encryption may depend on a
number of variables and the actual cryptographic algorithms and protocols may not meet
the Federal Information Processing Standards (FIPS) encryption requirements. Those three
companies were not even encrypting the data they were transferring, a basic tenant and
SOP when transmitting private client data of any type. This was a lapse of immense
proportions and was an example of how little control one has over where or how their
private data may be distributed once it is out of the companies control and once its
beyond your private control and into the public domain of the Internet, there is no putting it
back.
Cloud services utilizing web based (e.g. HTTPS) encryption may require specific web
browser usage and configuration to ensure only appropriate and approved cryptographic
algorithms are employed.

7
HTTPS encryption: Actual cryptographic algorithms employed in any HTTPS (e.g. SSL, TLS)
protected session using a web browser are determined during the initial session set up as a
negotiation between the client web browser and the web server. Many, but not all, web
browsers and web servers have a ‘FIPS’ mode of operation that can be configured and has
been functionally validated through the NIST (National Institute of Standards & Technology)
CMVP (Cryptographic Module Validation Program) Program which is a joint American and
Canadian security accreditation program for cryptographic modules which you can find
out more about HERE. Since many SaaS Cloud service offerings remove your organizations
control of the web server component, web browser settings are one of the means available
to an organization to enforce appropriate encryption mechanisms. The other
recommended means is via an SSL VPN Tunnel which utilizes the HTTPS/SSL Protocols to
initiate encrypted Browser-only connections.
Also, something to keep in mind is that often enforcing FIPS compliance via the Browser’s
Cryptography Configuration Settings often has unintended side-effects that may impact
the function of other web site access or applications. This is also referred to as the 128-Bit
Encryption version of the Browser (Microsoft especially was known to install the less secure
40-Bit International version of its Internet Explorer Browser, which would typically be rejected
by the majority of financial institutions or trading sites such as Banks, Online stock brokerage
sites, etc.) and the two versions can cause unintended issues as some sites continue to only
allow access via 128-Bit encryption while others cannot handle that method and while not
a large issue is something to keep in mind.
Typically, 128-bit encryption (aka “Strong Encryption”) is normally configured via the server-
side and this needs to be addressed when evaluating any CSP especially within the SaaS
arena as SaaS typically offers less transparency and less direct access for verifying or
changing configuration at the server side due to its inherent multi-tenancy configuration.
HTTPS connections involve two separate cryptographic algorithms. The first is a key
exchange algorithm (aka “key establishment”) which is a means by which two entities
(users, customers, organizations, etc.) can exchange keys in order to create a
“Cryptographic algorithm” better known as a “secure communication session” or an

8
“encrypted” data connection, ensuring that the communication between the two entities
is as safe as technology can make it, from a security perspective.
Encryption & Server Hardening
Described by Wikipedia in the following manner, “In designing security systems, it is wise to
assume that the details of the cryptographic algorithm are already available to the
attacker. This is known as Kirchhoff’s' principle — "only secrecy of the key provides security",
or, reformulated as Shannon's maxim, "the enemy knows the system".
The history of cryptography provides evidence that it can be difficult to keep the details of
a widely used algorithm secret. A key is often easier to protect than the algorithm your
using for example, and is a whole lot easier to change, than the actual encryption

9
algorithm (which mandates both sides have to be using the same) if compromised. Thus,
the security of most systems and/or infrastructures are based upon the encryption “Key”
being well hidden.
Trying to keep keys secret is one of the most difficult problems in practical cryptography
and something that is extremely important when designing a secure system since anyone
who obtains the key (by, for example, theft, extortion, dumpster diving or social
engineering) can steal every message or document which that key has been used to
encrypt. Basically they’ve been given the “Keys to the Kingdom” when that key theft
occurs.
There are two types of keys, “Symmetric” and “Asymmetric” with for all practical purposes
“Asymmetric Key Algorithms” being the current standard mainly used in today’s encryption
systems as it uses separate keys for the encrypting and decrypting process thereby allowing
a “Public” and a “Private” key to be utilized and keeping one of them hidden locally while
the “public key” can be sent out without risk. It is a much more inherently safe method of
managing a key pair than having one single key.
KEY SIZE - DOES MATTER!
Size Does Matter, at least when talking Encryption Key Length. For the “one-time pad”
encryption system the key must be at least as long as the message. In encryption systems
that use a cipher algorithm, messages can be much longer than the key. The key must,
however, be long enough so that an attacker cannot try all possible combinations.
What does the Key do exactly? Keys are used to control the encryption and decryption via
a “Cypher” thereby converting cipher text (text no one can read) into plaintext, which can
be read by anyone who can read the language the original message was written in.
A key should be long enough to mitigate a “Brute-Force Attack” (basically make it so that it
would take so long that it would not be worth the effort), this has been standardized with

1
0
the rule that a key should “be as long as the message, and only used once” which
according to work done on “information theory” has been shown to create what has been
called “perfect secrecy”. Since it is accepted principle that the “security of a system is
based upon the Key alone”, Key management is obviously extremely important in
designing and managing security and mitigating risk.
Typical “Strong Encryption” is anything between 80-bits and 128-bits and can go as high as
There is no reason to go into depth of the encryption theory which can get extremely
complicated, suffice it to say that Strong Key Length, Proper Key Management Solution and
the use of Hardware Keys over Software Keys are the three areas which need to be taken
seriously in order to guarantee security as much as technologically able.
HARDWARE KEY ENCRYPTION
Hardware-Based Encryption
 Uses a dedicated processor physically located on the encrypted drive
 Processor contains a random number generator to generate an encryption key,
which the user’s password will unlock
 Increased performance by off-loading encryption from the host system
 Safeguard keys and critical security parameters within crypto-hardware

1
1
 Authentication takes place on the hardware
 Cost-effective in medium and larger application environments, easily scalable
 Encryption is tied to a specific device, so encryption is “always on”
 Does not require any type of driver installation or software installation on host PC
 Protects against the most common attacks, such as cold boot attacks, malicious
code, brute force attack
SOFTWARE KEY ENCRYPTION
Software-Based Encryption
 Shares server resources to encrypt data with other programs on the server
– Only as safe as your computer
 Uses the user’s password as the encryption key that scrambles data
 Can require software updates
 Susceptible to brute force attack, computer tries to limit the number of decryption
attempts but hackers can access the computer’s memory and reset the attempt
counter
 Cost-effective in small application environments
 Can be implemented on all types of media
DATA DISK (AKA DATA-AT-REST) ENCRYPTION METHODS
Just as there are two types of Keys for encrypting data there is also two types of full disk
encryption (FDE) methods, software based and hardware based.

1
2
And it is just as important that data being passed between points within a LAN or WAN be
encrypted, it is just as important that your critical and sensitive data which is doing nothing
but sitting there (hence the “at rest” in “Data-at-Rest”)also be encrypted in case an
intruder breaches the system and gains access to that resting data.
Software based encryption modifies the hard drive drivers and uses the CPU to encrypt all
data as it is written to the drive and decrypt all data read from the hard drive while the
hardware based methodology for FDE is built into the hard drive and is totally transparent
to the user and does not impose a performance impact on the computer.
Since the Trusted Computing Group released the specification commonly known as “Opal”
in 2009 there are a plethora of what is commonly referred to as SED “self-encrypting drives”
being manufactured.
In a SED, the encryption logic is built into the drive electronics. SEDs scramble the data as it
is being written to the drive and unscramble it as it is read using an AES encryption key.
The keys and encryption functions are isolated in the disk drive subsystem, protected from
malware because they are not accessible by the operating system. A BIOS level password
is used to authenticate the user to the SED.
Self-encrypting drives offer some extremely attractive features that a software or OS based
disk encryption method does not have, indeed the performance differences alone make it
a no-brainer choice for any type of critical drive encryption needs you might have, to go
with the hardware based SED solution. For example, the drive is automatically locked when
it is removed from a system or powered down and the drive can be securely erased in a
fraction of a second by the cryptographic erasure of the data encryption key. But perhaps
the most attractive feature to the average user is that the performance impact of a SED is
negligible as compared to a similar hard drive. Contrast this with software based full disk
encryption, which can exact an average performance impact of 32%.

1
3
As outlined above Hardware based encryption is the highly preferred method and one I
would recommend when designing your security management system. There are a number
of hardware vendors available on the market today and below I list a few which I can
recommend (star next to their name) and many I have no experience with personally but
know by reputation or from other consultants I’ve spoken with:
ENCRYPTION KEY & DATA MANAGEMENT APPLIANCES
 Crossroads StrongBox***
 Vormetric Enterprise Key Management ***
 Pasanoia3 Tape Encryption***
 DataFort*** (I used prior to their Acquisition by Netapp)***
 Crossroads Strongbox*** (However they now have multiple Data ProtectionSystems to Choose From)
 Thales Group*** (Always have had their hand in the securitysector and provide robust scalable and reliable
products typically)
Email
There are fundamentally three main areas which need to be addressed for Email Servers
being hosted on a public cloud service and while it may seem like email is not that big of a
deal, the realities are, and most people fail to realize that over 90% of successful corporate
attacks are now carried out via email exploits. It has become a VERY SERIOUS security
threat and using a hosted CSP email solution could become the largest risk to your entire
corporate security infrastructure.
Email threats consist of virus attacks, spam, false positives, distributed denial-of-service
(DDoS) attacks, spyware, phishing (fraud), regulatory compliance violations and data loss.
APT - Advanced Persistent Threats

1
4
APTs (Advanced Persistent Threats aka advanced “Malware”) attacks on a specific
organization’s people, systems, vulnerabilities and data from the inside. Typical transport to
the internal network is via Email.
“Spear-Phishing”
According to one report by the “SANS Institute” 95 percent of all attacks on enterprise
networks are the result of successful “spear phishing”. Somebody received an email and
either clicked on a link or opened a file that they weren’t supposed to. For example,
Chinese hackers successfully broke into computers at The New York Times through spear
phishing.
Upgrading your anti-virus system
The most successful attacks have been show to come in the form of offers for money,
coupons or incredible discounts or bargains with many of them appearing to have come
directly from your bank, PayPal Account, Brokerage Account or even the CSP email
account provider themselves announcing frozen accounts and the request to reenter
credentials or personal information. The hackers of today are much more specific in their
targeting and extremely sophisticated and the email threats of today should never be
taken lightly. Today’s spear-phishing is much more targeted at specific companies to
gather specific information. Some older or less robust email security solutions can’t handle
these threats well because they haven’t seen it before, and so It is critical that if you are
breaching your internal firewall via a Public Cloud Hosted Email System, that you have a
robust anti-virus & malware email server solution as well as “real-time” monitoring on any
device utilizing that email (PC, phone, tablet, laptop) as the biggest security threat to your
organization and the largest percentage of successful breaches are exploited via email.
When evaluating a email security solution make sure it is certified by the
Antivirus Testing Agency Certification
It is important to verify which agencies have certified the antivirus solutions your examining,
realizing that these testing agencies are “for profit” companies and therefore charge to
certify vendor products/ What this means is that small development firms may not be able

1
5
to afford more than one or two tests while larger vendors might have multiple certifications,
so it is really difficult to base decisions solely on the testing results however you won’t be
wrong going with a more established vendor who has been certified by 3 or more of the
agencies listed, as long as their certification scores are also high. When I have a hard
choice to make between technology vendors I will typically use the following criteria to
make my final decision:
 Cost
o Make sure its within your budget
 Scalability
o Make sure it scales for your expected 3-5 year growth plans. You may want to
ask the vendor what kind of upgrade path they offer if you’ll need to scale to
new hardware or software as you grow,
 Upgrade Path
o make sure they have a clean upgrade path that supports zero down-time, is
simple (the more complex the more likely issues will arise) and that it is fully
supported with a dedicated TSE when actually performing the upgrade as its
almost guaranteed you will have questions which will need answering and is
best to have an expert on the line with you who can advise as things come up
during the actual migration/transfer/upgrade process
 Support Options
o I’m a firm believer in strong support of no longer than 1hour SLA for hardware
replacement for critical production environments which means everything else
should be much shorter than that which is the hardest to resolve obviously as it
requires both a physical part and a physical body to install it. Obviously the CSP
will be in charge of the hardware in 99% of all CSP environments, you just need
to worry about the software aspects of SLA agreements and I would make sure
it’s at the least a 15 minute response and 30 minute fix at the low end, and I
personally expect more along the lines of 5 & 10 (5 minutes to respond to any
alert and 10 to solve the issue)

1
6
Email Data Encryption
Depending upon your needs, the majority of companies do not require encrypted email
data or sessions, and you will want to verify with the CSP whether they offer secure,
encrypted email storage as well as encrypted session protocols (SMTP, SecureIMAP, and
POP).
There are plenty of data-encryption appliances and software on the market which utilize
hardware encrypting techniques and can encrypt 100% of your email data on the server
residing on the CSP network, when and if allowed by the CSP. Many CSP’s have partnered
with these vendors to offer this as an add-on service, we highly recommend using it if
available, no matter the cost.
 Encrypted Email Traffic, including Login information
Verify that you’re able to use SSL with both incoming and outgoing mail servers and if the
CSP does not allow this basic security feature then find one who will. While all your email
traffic for your employees may not be sensitive, sending it in plain text is asking for hackers
and competitors to exploit you, and scanning your email traffic is almost like dumpster
diving, although the majority is garbage and/or useless to the hacker or competition,
eventually something significant will be discovered.
It’s a simple checkbox and port change on most email clients to make ALL your email
traffic encrypted, so it is well worth the small effort to train your employees in this simple
configuration change and then write a script which will verify the changes before allowing
them to login to the CSP hosted email service. You can easily write a script or create a
customized email client with the settings already filled out, depending on which email
client/server setup you’re using. Most IT admins should know how to do something that
basic and if not google it and you’ll find hundreds of tutorials.
 Encrypted Username/Password

1
7
An absolute must in my opinion. If the CSP you are evaluating does not allow SSL
authentication for mail then move on, it’s not nearly worth the risk you would be taking. If
not, then you are risking your usernames and passwords being stolen (since they will be
passed to the server in plain text)with an almost 100% guarantee. And once those are
stolen it is just a matter of time before the hacker has complete access to an employee
device and from there….you get the drift.
Mail Server Hardening
As with any server, it should be hardened with some extremely simple yet effective steps
such as making sure your Mail server (along with ALL your servers no matter they be DNS,
Web or Application servers), if on a Linux OS, is running in a “jail” (aka “chroot jail”) which is
an extremely simple yet 100% effective way of putting a full-stop to takeover attempts by
hackers if they do happen to get past the firewalls, load balancers, IDS/IDP systems and
actually get to the command-line will be trapped in their own little “jail” and unable to
exploit their having penetrated to the OS. They will be very limited to what they can do, in
other words.
 Server Access Controls
Again, if you have access to the mail server itself (such as in a IaaS type solution) then
locking down access with multi-point authentication and access rules is critical and takes
less than 30 minutes in order to give yourself 100% protection and peace of mind.
Obviously, or perhaps not but first you lock down all access to the server except through
SSH which is an encrypted command-line session (Secure Shell), and no other than direct
console access. Once that is accomplished then the following simple restrictions should be
instituted:
 IP Address - First level of authentication is by IP Address
o If the client attempting to access the server from an IP address other than
the specific ones listed in the configuration, it will instantly be rejected

1
8
 SSH Certificates - If they are coming from a listed IP Address, then the next test is to
check and make sure they have the correct SSH Client Certificate, one which will
me a match to one that resides on the SSH server. This is called “setting up SSH
Certificates” and can be googled to instantly find step-by-step instructions for
configuration with the client of your choice.
 Username/Password – And finally, you obviously also have username and
password of the clients own devising.
So in reality a hacker would need to know all three and the only way they would be able to
do this is if they gained complete control of an employee’s system, and the best way for
them to accomplish this is via email malware or a virus such as a Trojan. Which is why it is
extremely important that email authentication and data be encrypted when coming
through the firewall from a public location.
Storage & Applications
Overview

1
9
Cloud services typically reside within a shared infrastructure with multiple customers’ data
residing on the same physical and logical storage media. This is commonly referred to as a
“multi-tenant” environment and is typically used by SaaS CSP service solutions.
The issues with this type of service are many but primarily it increases the risk of data spillage
across logical (customer) boundaries either by intentional manipulation of the shared
infrastructure by a malicious actor, or unintentional spillage due to administrator error in
system configuration or data manipulation operations.
There are two basic types of SaaS service which is offered, we will discuss the security
concerns of both and what we recommend to remove the most risk from the service.
Multi-Tenant Applications
The CSP you are evaluating may or may not already be encrypting data at both the logical
(in shared memory) and physical (on disk) level however it would benefit you to see if the
CSP offers a “Dedicated” instance of their application, if there is determined to be
significant Risk with regards to the type of data being passed through or processed by the
CSP application, then a dedicated server is the most reliable way to mitigate that risk while
at the same time advancing overall performance and reliability of your environment.
The CSP may encrypt data at the logical or physical storage level to limit exposure of
customer’s data. Storage encryption issues are similar in nature to those described in the
Transmission section however their resolutions are completely different with many of the
storage solutions available via 3rd party vendors or CSP partnerships with data encryption,
security & compliance solution providers.
Data that is logically or physically stored by the cloud service in an unencrypted format is
susceptible to modification, deletion, and unauthorized disclosure. Stored data that is
encrypted is still susceptible to unauthorized deletion.
The physical storage facilities may be in multiple mirrored locations with third or fourth party
staff potentially having physical access. This may be partially mitigated due to a low
likelihood that extended staff would have knowledge or appropriate logical access to
specific customer’s data.

2
0
Organizational data may be physically or logically moved periodically to ensure efficient
operation of the cloud service as a whole based on overall utilization. This may impact the
need for periodic reviews or the level of service monitoring required to ensure any data
storage controls or limitations are enforced.
Physical and logical storage mechanisms for cloud service must be understood in order to
evaluate their potential for compliance with existing CORPORATE policy. This may be an
issue with some providers as their storage mechanisms are considered highly proprietary
and may include elements considered trade secrets.
Due to the highly complex and potentially fluid nature of cloud infrastructures, any
infrastructure shared between multiple customers would likely require client end-to-end
encryption methods to ensure there is no exposure of sensitive data to disclosure or
modification.
If the cloud provider can guarantee separate infrastructure, either physically, or through
cryptographic separation at all service and application layers, the solution might be
acceptable for processing of sensitive data. However, for physical segregation, the SLA
must address the personnel security and access concerns to the same degree as would be
applied to any contract provider given access to sensitive data. For cryptographic
segregation, personnel security and access concerns could be limited to the provider staff
with access to the cryptographic key material.

2
1
Physical Storage
Due to the nature of cloud services, the specific physical location of data may be
indeterminate from the customer perspective. For certain compliance data, assurances
and auditing to verify that data is not stored, either in primary, backup, or a residual form,
outside of the legal jurisdiction of the U.S. and its laws. Data physically stored outside the
jurisdiction of the United States may be subject to access or handling laws of the country in
which it is physically stored. This could result in access being granted to the data by a non-
U.S. government or court.
You may wish to obtain legal counsel with regards to the potential impact of physical data
storage for local law enforcement that resides in a different legal jurisdiction. Specific laws
or requirements in both the jurisdiction of the using law enforcement entity as well as in the
jurisdiction where the physical storage resides could potentially complicate or cause
unintended consequences regarding E-Discovery actions or access to computer forensic

2
2
data (e.g. logs) during incident handling of any data breach or loss or even upon legal
termination of the entity such as Bankruptcy within another country jurisdiction.
Data storage issues and risks apply to all cloud services. Individual services may store
residual or ancillary data in different forms (e.g transaction logs, error logs, usage data, and
temporary files) that may or may not contain elements of sensitive data. Each proposed or
evaluated service would require a technology specific evaluation to determine applicable
physical or logical storage that must be addressed.
Application Access
Cloud services will typically consist of a number of technical ‘layers’ from the physical
device, usually through a virtualization layer, and potentially multiple application layers
(e.g. web interface layer, application processing layer, database layer, etc.).
Sensitive compliance data may reside within each of these layers in some form that may
be accessible to system administrators with responsibility for that particular layer. System
administrators or logging sub-systems at each layer may have limited visibility into what
access is granted or is occurring with different layers.

2
3
System
administrators and
maintainers may fall under
different
organizational sub-units of
the cloud service
provider or
administrative and
maintenance functions
may be outsource to
a third-party for particular
functions.
Again it is important to
establish “Location” specific risk as system administrators and/or engineers may be
physically located in foreign countries and subject to governance/subpoena/legal action
by that country. If sensitive corporate compliance data is accessible to those
administrators, regardless of actual storage location, a local court could feasibly require
them to access and provide the data to the local government. While this might not be
supportable under international law, any complaints would likely have to be entered after
the fact.
Multiple customers of the service provider may use shared resources within some layers of
service provider infrastructure and this may be obscured intentionally or unintentionally by
the service provider (e.g. a customer may request a dedicated web instance or storage
location for sensitive data, but the data may be accessible from a shared database
resource) due to the complexity of the cloud services infrastructure.
Any resource layer shared by multiple customers may be susceptible to manipulation by a
customer in order to gain access to all data stored on that layer data stored on layers
above or below the comprised resource layer.

2
4
Data being actively processed within a resource layer (e.g. manipulated or changed and
not simply transmitted)cannot be encrypted for protection within that resource layer. This
potentially allows any user or administrator with access to that resource layer to gain
access to the data, regardless of any encryption that may be applied at different resource
layers.
Identity Management, Authentica tion Methodolog y & Password Policy
Enforcem ent
Cloud services are typically based on the concept of a high level of accessibly to the
service and stored information from any physical location. The identity management,
access authorization, and authentication mechanisms used by the cloud service must
enforce appropriate protections and utilize government approved cryptographic
mechanisms.
The identity management and access authorization functions of a cloud service may either
be managed directly by the cloud provider or delegated to one or more individuals from
the customer organization who are given special access rights. If management is retained
by the service provider, a robust mechanism for remotely validating the identity of
individuals presenting themselves as from the customer organization must be in place to

2
5
prevent successful social engineering attacks. This same structure must be in place for the
authorized customer account managers if delegated to the customer.
Authentication mechanisms must be separately evaluated from standard service functions
to ensure compliance with approved security standards (PCI, SOC1, etc..) in the handling
and transmission of user credentials, as well as the storage of user data within the account
database.
Information within the account database of the service provider beyond the user
credentials may constitute sensitive information as user data may provide all the
information necessary to execute a spear-phishing attack on key individuals. Some cloud
services may publish user data in formats or within the web service to enhance user search
features, but may use mechanisms that are accessible by non-organizational users.
Cloud services may provide a limited ability to audit the roles and permissions assigned to
all accounts within the customer’s portion of the cloud service. Cloud service providers will
typically not provide customers with information regarding administrative roles held by the
service provider or third party service providers responsible for some elements of the cloud
service.
Audit record retention, content, and availability may be limited with cloud services and
Cloud service providers may not be able to enforce particular password rules or lifespan. All
of which must be taken into account when selecting the best Vendor.
The combination of username and password alone is generally insufficient protection of
sensitive information that is accessible from anywhere on the World Wide Web. Additional
protections in the form of Internet Protocol address restrictions or multi-factor authentication
mechanisms may not be available from many cloud service providers but should be used
whenever available.

2
6
Group and User ACL’s
Making sure the CSP offers a management console or “Dashboard” which allows granular
control of who gains access to what, is critical.
Most providers do have some type of “Management Dashboard” so you will want to verify
that it allows you to assign manager rights to your managers and thy in turn are able to
then assign access rights per user down to a very granular level such as access to
applications, databases and individual files even. If they do not offer this type of granular
control then you might think twice about using their service as this is a Basic tenant of
proper security.
Employee Termination Policy
It is important that your company have a employee termination Policy that erases all
access to critical resources when an employee leaves the company.

2
7
It is even more critical that a hosting company (CSP) observe strict termination guidelines.
Do you want one of their disgruntled employees logging in through a back-door and
destroying your data because the CSP failed to properly remove that persons credentials
and delete his account access?
ASK TO SEE THEIR EMPLOYEE TERMINATION POLICY!
Retention Policy On & Off-site Backups and Emergency Access
Compliance data and especially and financial transactional data, may be subject to
specific retention requirements. I believe from what I’ve been told the longest retention
requirement is 5-6 years however there are also requirements which state the data must be
maintained as long as the “customer and/or application” for which that data is from, is still
active which could potentially be a much longer length of time. Any cloud service provider
agreement must be assessed to compliance to any retention requirements associated with
the data that will be resident within the cloud service.
Backup systems may require decryption of certain data stores or data streams to function
properly. These systems may or may not re-encrypt the data for storage within the backup
system or within another storage location. If a different cryptographic system is used, it may
also need to be evaluated for FIPS compliance separately from the primary cloud service
Backup data may be stored in a different physical location from the primary data store and
be subject to the same physical storage locality issues as identified in the Storage section of
this document.
Transaction logs, access logs, error logs, and other data sources with ancillary or residual
data that may contain sensitive information may or may not be backed up. Additionally,
this data may be backed up and stored using a different mechanism from the primary
data. Retention of some ancillary data sources may be required in order to meet standards
for forensic or investigative analysis of any data breach or compromise of law enforcement
information.

2
8
Emergency access to data and Disaster Recovery plans for the provider should be explicitly
defined in the SLA. The SLA must include clear definition of priorities for restoration of
provider services and the support priorities given the government cloud services in specific
disaster scenarios to include large scale man-made disaster scenarios.

2
9
Disaster Recovery & Business Continuity
Cloud service provider facilities may be affected by natural or man-made disasters that
occur at a significant physical distance from the organizational customer base. However,
service loss to local customers may still occur in the case of a local disaster that affects the
local Internet Service Provider (ISP) that services the local customer’s primary facility.
Conversely, local disaster recovery may be enhanced through cloud services from an
alternate facility using an alternate ISP. Continuity of Operations Plans or Disaster Recovery
plans designed
for local data
services will likely
need to be re-
designed for cloud
services.
Disaster recovery
priorities for a cloud
service provider
may not be
consistent with the
customer availability
requirements of law enforcement during large scale natural or man-made disasters.

3
0
Non-local data storage that results in loss of access to local law enforcement data during
large scale man-made disasters could critically impede the investigation or apprehension
of threat actors responsible for the disaster. This may include targeted denial of service
attacks against cloud service providers if it became public knowledge that law
enforcement actions were dependent on the cloud provider.
Cloud Service Provider SLA’s
Provider documentation and SLA’s must be publically available and easily obtained
without much effort. Doing anything else, creates questions about the integrity of the
specific CSP and their Security, Compliance and Uptime percentages.
Specifically address the data content and types of ancillary or residual data that may exist
and detail the provider handling procedures for all data types.
SLA’s must specifically identify data retention periods for primary, ancillary, and residual
data sources
Backup, ancillary, and residual data must conform to the same physical and cryptographic
storage requirements as primary data.
SLA’s should clearly identify service provider policy regarding the issues from this section.
Contractual agreements should explicitly specify timelines and allowable service changes
in the event of ownership transfer of the provider.
Discontinuation of cloud services will remain a risk. It is likely infeasible to fully guarantee
access to and validation of ancillary and residual data destruction if the cloud service

3
1
provider discontinues services. The SLA’s and contractual agreements should specific the
intended actions, and only financially sound providers should be considered.
SLAs or contractual agreements should specify service provider responsibilities on the
sanitization of data from media and retired devices.
It should also contain SLA’s within the following critical areas:
 Uptime Percentage of at least 99.99%
o I’m a firm believer in 100% SLA’s personally but the industry has copped-out for
a sub-par standard of 99.99%
 TSE Response Times
 Guaranteed Issue Resolution Times
 Guaranteed Escalation Times
 Penalties for failure to meet those times
If the CSP does not offer these in writing then, think twice

3
2
CSP Viability and Stability
LEGAL REORGANIZATIONS, JURISDICIONAL DISPUTES AND ASSOCIATED ISSUES OF
CORPORATE DATA WITHIN A GLOBAL CSP ENVIRONMENT
General cloud provider agreements do not require the cloud provider to notify the cloud
service users of provider internal changes. This could include changes to the internal
security services, or physical locations of data storage that would adversely affect the
security posture for a government or law enforcement customer.

3
3
Commercial cloud service providers may re-organize or sell/buy business units to/from other
companies. This may cause modification to existing cloud services or changes in the
nationality of service administrators.
Upon discontinuation of cloud services (either by customer request, provider dissolution, or
provider request) it may be impossible to verify that all ancillary or residual data has been
properly sanitized from the provider infrastructure, even if the primary data is properly
removed from the service.
Refresh or replacement of provider hardware or media may result in unintentional release
of residual data in a recoverable format. The service provider would typically not notify
customers of internal hardware or media changes that might result in decommissioning or
disposal of devices that may contain customer data.
CSP FINANCIAL AND EXECUTIVE STABILITY
Verify the following before signing any contract:
 Length In Business
 Employee Turnover Rates
o High turnover is a sure sign of bad management usually
 Financial hiccups in the past
 Adequate Funding if Private, Adequate Cash Reserves and low Debt if Public
 Read the Executive Staff Bios which are usually available online and see if they are
people you would hire
 Read any financial reports or statements they have made public

3
4
Periodic Disaster Recovery & Business Continuity Testing
SCHEDULED ONGOING TESTING
The following is a list of “hard tests” I recommend all my clients maintain with any Provider
you may be using, on a regularly scheduled basis in order to maintain infrastructure integrity
at all levels:
PERIODIC FAILOVER TESTING
If possible, I encourage all businesses to perform regular failover testing and if the CSP does
not allow that, you may wish to reconsider your plans.
PERIODIC BACKUP & RECOVERY TESTS
There is nothing worse than losing data and then learning that your backups we’re not
being performed properly when you really need them….DO NOT WAIT till it’s a real
emergency to find out if your backups are working or not…

3
5
D.R. & B.C. TESTING
If possible, get it put in your contract that YOUR COMPANY and the CSP will “Jointly” work
together to perform scheduled validation testing for both your Disaster Recovery & Business
Continuity Plans, Policies & Procedures
PERIODIC TSE SLA TESTING
I recommend to all of my clients that periodic scheduled testing of the CSP’s “Technical
Support Engineer” staff be put to the test by initiating a planned disruption and then timing
their response as well as their resolution. In this way you can keep a sense of the quality of
the staff the CSP is hiring, as well as their quality of training.

3
6
WRITTEN BY: JARRETT NEIL RIDLINGHAFER
CHIEF TECHNOLOGY ANALYST
Cloud Consulting International
Atheneum-Partners.com
Compass Solutions, LLC.
CHIEF TECHNOLOGY OFFICER/CTO
Synapse Synergy Group, Inc.
4DHealthware, LLC
 Mr. Ridlinghafer With an extensive& extremely diverse background spanning 25 years beginning at
Netscape between 94-99 & as a Hands-On Executive & Generalist Specializing in Data-Center & Cloud
Infrastructure Designs, Builds, Upgrades, Integrations, Migrations, Consolidations, Operations (both
“Netops” & “Devops”), Security & Compliance, Virtualization & Automation, DR, HA& Distributed
Networks. As a Certified International Master Project Manager I have managed many massively
complex project management roles throughout my career. Having worked my way from “tech support
engineer” to executive level roles including multiple stints as Director & CTO, patenting 2 inventions &
founding 4 startups along the way.
 Mr Ridlinghafer has designed and managed the build-out from scratch of over 20 world-class data-
centers in his career including multiple Tier III Data-Centers with his most current one on-going where he
is managing the design and build-out of a $250,000,000 complete state-of-the-art, greenfield Tier III
data-center for the entire Nigerian Banking Sector.
 Inventor of the famous “Bugs Bounty” program. I 1st coined the phrase at Netscape '95
 Inventor and creator of the “Netscape/Mozilla Champions” program '95
 Managed the creation of the first AI Automated Email Response System in Corp. America '96
 Managed the massive in-house designed and developed Netscape Call Tracking System '96
 SavedNetscape over US$20M Annually over 5 years of Operational Management Excellence
 First to bring Fiber and Broadband (Both DSL & Wireless)Access to Los Gatos, CA '99
 Inventor of the First Plug-n-Play Retail Firewall Router, which KPCB Offered to fund in '99
 Built the massivelycomplex, SaaS PS3 Online Data Center '04-'06
 Built the SaaS Data-Center chosen to host OBAMA.MOBI for the successful 08 Presidential Campaign
 Designed & Built 20+ World-Class Data-Centers

Security & Compliance in the Cloud - Hadoop Magazine Column Version 1.2 by Jarrett Neil Ridlinghafer

Recommended

Recommended

More Related Content

What's hot

What's hot (18)

Similar to Security & Compliance in the Cloud - Hadoop Magazine Column Version 1.2 by Jarrett Neil Ridlinghafer

Similar to Security & Compliance in the Cloud - Hadoop Magazine Column Version 1.2 by Jarrett Neil Ridlinghafer (20)

Security & Compliance in the Cloud - Hadoop Magazine Column Version 1.2 by Jarrett Neil Ridlinghafer