security & compliance in the cloud - hadoop magazine column version 1.2 by jarrett neil...

CLOUD SECURITY & COMPLIANCE

RISKS

AN ARTICLE FOR HADOOP MAGAZINE COLUMN

VERSION 1.0

MARCH 12, 2014

PREPARED BY: JARRETT NEIL RIDLINGHAFER

SYNAPSE SYNERGY GROUP

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 Consulting International 1

Table of Contents

Introduction................................................................................................................................................................................................................................2

Goals of this document...............................................................................................................................................................................................................4

The Issues & Risks associated with the public cloud, Which Need to be Mitigated ........................................................................................................................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 Failover Testing..................................................................................................................................................................................................34

Periodic Backup & Recovery Tests...................................................................................................................................................................................34

D.R. & B.C. Testing...........................................................................................................................................................................................................35

Periodic TSE SLA Testing...................................................................................................................................................................................................35

Written By: Jarrett Neil Ridlinghafer ..................................................................................................................................................................................36

Chief Technology Analyst ......................................................................................................................................................................................................36

Chief Technology Officer/CTO ................................................................................................................................................................................................36



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 lit t le 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 art icle 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



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:

Elast icity of resources

o Everything from memory, CPU cycles, disk-space and bandwidth even load-

balancing and rout ing have become elast ic 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 init ially installed upon. Indeed the

application itself now, can be located on any server around the world or on

mult iple servers at the same t ime.

Pay-for-use-only

o You no longer are forced to pay for unused CPU cycles, memory or disk-space

for example, drast ically reducing the cost footprint which has made it highly

attractive to enterprise customers as a cost cutt ing means.

Highly distributed

o You can have mult iple 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,



one of the largest and most widely used Cloud Frameworks “OpenStack” was just bashed

by mult iple analysts as “Not ready for prime-t ime 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 art icle will endeavor to explore those issues, to expose the weaknesses and flaws and to

suggest solut ions and proper procedures to mit igate 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 mit igate 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.

http://en.wikipedia.org/wiki/Cloud_computing



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 solut ions. These include:

Transmission of Data & Stored Data

Encryption and Server Hardening

Cryptographic Key and Cert ificate Management

Email Security Issues

Mult itenant Storage & Application Access

Access Authorizat ion, Authentication methods, and Identity Management & ACL’s



Employee Termination Policies

Retention and Backup

Disaster Recovery & Business Continuity

SLA’s & Contractual Agreements

Legal & Jurisdict ional Issues

Service Provider Long-term Viability and Financial Structure

Ongoing Test ing 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 t ransmit customer data across uncontrolled internet connections

that are susceptible to monitoring and interception. Indeed, just within the last 30 days the

NSA (National Security Administrat ion) 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 ut ilize 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 transmitt ing private client data of any type. This was a lapse of immense

proport ions and was an example of how lit t le 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 t he public domain of the Internet, there is no putt ing it

back.

Cloud services ut ilizing web based (e.g. HTTPS) encryption may require specific web

browser usage and configurat ion to ensure only appropriate and approved cryptographic

algorithms are employed.



HTTPS encryption: Actual cryptographic algorithms employed in any HTTPS (e.g. SSL, TLS)

protected session using a web browser are determined during the init ial session set up as a

negotiat ion 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 Inst itute of Standards & Technology)

CMVP (Cryptographic Module Validation Program) Program which is a joint American and

Canadian security accreditat ion program for cryptographic modules which you can find

out more about HERE. Since many SaaS Cloud service offerings remove your organizat ions

control of the web server component, web browser sett ings are one of the means available

to an organizat ion to enforce appropriate encryption mechanisms. The other

recommended means is via an SSL VPN Tunnel which ut ilizes the HTTPS/SSL Protocols to

init iate encrypted Browser-only connections.

Also, something to keep in mind is that often enforcing FIPS compliance via the Browser’s

Cryptography Configurat ion Sett ings 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 inst itut ions or t rading 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 t ransparency and less direct access for verifying or

changing configurat ion at the server side due to its inherent mult i-tenancy configurat ion.

HTTPS connections involve two separate cryptographic algorithms. The first is a key

exchange algorithm (aka “key establishment”) which is a means by which two entit ies

(users, customers, organizat ions, etc.) can exchange keys in order to create a

“Cryptographic algorithm” better known as a “secure communication session” or an

http://en.wikipedia.org/wiki/Cryptographic_Module_Validation_Program



“encrypted” data connection, ensuring that the communication between the two entit ies

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



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, extort ion, 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 ut ilized and keeping one of them hidden locally while

the “public key” can be sent out without risk. I t 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-t ime 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 convert ing 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 mit igate 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

http://en.wikipedia.org/wiki/One-time_pad



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 mit igating risk.

Typical “Strong Encryption” is anything bet ween 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 Solut ion 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 crit ical security parameters within crypto-hardware



1

Authentication takes place on the hardware

Cost-effective in medium and larger application environments, easily scalable

Encryption is t ied to a specific device, so encryption is “always on”

Does not require any type of driver installat ion or software installat ion 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 t ries 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.



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 crit ical and sensit ive data which is doing nothing

but sitt ing there (hence the “at rest” in “Data-at-Rest”) also be encrypted in case an

intruder breaches the system and gains access to that rest ing 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 t ransparent

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 crit ical drive encryption needs you might have, to go

with the hardware based SED solut ion. 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%.



3

As out lined 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 Protection Systems to Choose From)

Thales Group*** (Always have had their hand in the security sector 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 realit ies 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 solut ion could become the largest risk to your ent ire

corporate security infrastructure.

Email threats consist of virus attacks, spam, false posit ives, distributed denial-of-service

(DDoS) attacks, spyware, phishing (fraud), regulatory compliance violat ions and data loss.

APT - Advanced Persistent Threats

http://www.crossroads.com/

http://www.vormetric.com/products/enterprise-key-management

http://www.disuk.com/products/backup-encryption/paranoia3.php

http://www.netapp.com/us/products/storage-security-systems/datafort/

http://www.crossroads.com/data-archive-products

https://www.thalesgroup.com/en/cybersecurity/what-we-do/products



4

APTs (Advanced Persistent Threats aka advanced “Malware”) attacks on a specific

organizat ion’s people, systems, vulnerabilit ies and data from the inside. Typical t ransport to

the internal network is via Email.

“Spear-Phishing”

According to one report by the “SANS Inst itute” 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 T imes 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 sophist icated and the email threats of today should never be

taken light ly. Today’s spear-phishing is much more targeted at specific companies to

gather specific information. Some older or less robust email security solut ions can’t handle

these threats well because they haven’t seen it before, and so It is crit ical that if you are

breaching your internal firewall via a Public Cloud Hosted Email System, that you have a

robust ant i-virus & malware email server solut ion as well as “real-t ime” monitoring on any

device ut ilizing that email (PC, phone, tablet, laptop) as the biggest security threat to your

organizat ion and the largest percentage of successful breaches are exploited via email.

When evaluating a email security solut ion make sure it is cert ified by the

Antivirus Test ing Agency Cert ificat ion

It is important to verify which agencies have cert ified the antivirus solut ions your examining,

realizing that these test ing agencies are “for profit” companies and therefore charge to

cert ify vendor products/ What this means is that small development firms may not be able



5

to afford more than one or two tests while larger vendors might have mult iple cert ificat ions,

so it is really difficult to base decisions solely on the test ing results however you won’t be

wrong going with a more established vendor who has been cert ified by 3 or more of the

agencies listed, as long as their cert ificat ion 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-t ime, 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 quest ions 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 migrat ion/transfer/upgrade process

Support Options

o I’m a firm believer in strong support of no longer than 1hour SLA for hardware

replacement for crit ical 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)



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 ut ilize

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

t raffic for your employees may not be sensit ive, sending it in plain text is asking for hackers

and competitors to exploit you, and scanning your email t raffic is almost like dumpster

diving, although the majority is garbage and/or useless to the hacker or competit ion,

eventually something significant will be discovered.

I t ’s a simple checkbox and port change on most email clients to make ALL your email

t raffic encrypted, so it is well worth the small effort to train your employees in this simple

configurat ion 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 sett ings 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



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 t ime 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 putt ing 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 lit t le “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 solut ion) then

locking down access with mult i-point authentication and access rules is crit ical 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 restrict ions should be

inst ituted:

IP Address - First level of authentication is by IP Address

o I f the client attempting to access the server from an IP address other than

the specific ones listed in the configurat ion, it will instantly be rejected



8

SSH Certificates - I f they are coming from a listed IP Address, then the next test is to

check and make sure they have the correct SSH Client Cert ificate, one which will

me a match to one that resides on the SSH server. This is called “sett ing up SSH

Cert ificates” and can be googled to instantly find step-by-step instruct ions for

configurat ion 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 & Application s

Overview



9

Cloud services typically reside within a shared infrastructure with mult iple customers’ data

residing on the same physical and logical storage media. This is commonly referred to as a

“mult i-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 intent ional manipulat ion of the shared

infrastructure by a malicious actor, or unintentional spillage due to administrator error in

system configurat ion or data manipulat ion 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 applicat ion, 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 mit igate that risk while

at the same t ime 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 resolut ions are completely different with many of the

storage solut ions available via 3rd party vendors or CSP partnerships with data encryption,

security & compliance solut ion providers.

Data that is logically or physically stored by the cloud service in an unencrypted format is

susceptible to modification, delet ion, and unauthorized disclosure. Stored data that is

encrypted is st ill susceptible to unauthorized delet ion.

The physical storage facilit ies may be in mult iple mirrored locations with third or fourth party

staff potentially having physical access. This may be part ially mit igated due to a low

likelihood that extended staff would have knowledge or appropriate logical access to

specific customer’s data.



0

Organizat ional data may be physically or logically moved periodically to ensure efficient

operation of the cloud service as a whole based on overall ut ilizat ion. This may impact the

need for periodic reviews or the level of service monitoring required to ensure any data

storage controls or limitat ions are enforced.

Physical and logical storage mechanisms for cloud service must be understood in order to

evaluate their potential for compliance with exist ing 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 mult iple customers would likely require client end-to-end

encryption methods to ensure there is no exposure of sensit ive 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 solut ion might be

acceptable for processing of sensit ive 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 sensit ive data. For cryptographic

segregation, personnel security and access concerns could be limited to the provider staff

with access to the cryptographic key material.



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 audit ing to verify that data is not stored, either in primary, backup, or a residual form,

outside of the legal jurisdict ion of the U.S. and its laws. Data physically stored outside the

jurisdict ion 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 jurisdict ion. Specific laws

or requirements in both the jurisdict ion of the using law enforcement ent ity as well as in the

jurisdict ion where the physical storage resides could potentially complicate or cause

unintended consequences regarding E-Discovery actions or access to computer forensic



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 jurisdict ion.

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 sensit ive 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 virtualizat ion layer, and potentially mult iple application layers

(e.g. web interface layer, application processing layer, database layer, etc.).

Sensit ive compliance data may reside within each of these layers in some form that may

be accessible to system administrators with responsibility for that part icular 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.



3

System

administrators and

maintainers may fall under

different

organizat ional sub-units of

the cloud service

provider or

administrat ive and

maintenance funct ions

may be outsource to

a third-party for part icular

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 sensit ive 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.

Mult iple 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 sensit ive 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 mult iple customers may be susceptible to manipulat ion 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.



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 en t

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 authorizat ion, and authentication mechanisms used by the cloud service must

enforce appropriate protections and ut ilize government approved cryptographic

mechanisms.

The identity management and access authorizat ion functions of a cloud service may either

be managed directly by the cloud provider or delegated to one or more individuals from

the customer organizat ion 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 organizat ion must be in place to



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 const itute sensit ive 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-organizat ional users.

Cloud services may provide a limited abilit y to audit the roles and permissions assigned to

all accounts within the customer’s port ion of the cloud service. Cloud service providers will

typically not provide customers with information regarding administrat ive 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 part icular 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

sensit ive information that is accessible from anywhere on the World Wide Web. Addit ional

protections in the form of Internet Protocol address restrict ions or mult i-factor authentication

mechanisms may not be available from many cloud service providers but should be used

whenever available.



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 crit ical.

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

I t is important that your company have a employee termination Policy that erases all

access to crit ical resources when an employee leaves the company.



7

It is even more crit ical that a host ing company (CSP) observe strict termination guidelines.

Do you want one of their disgrunt led 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-si te Backups and Emergency Access

Compliance data and especially and financial t ransactional 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 st ill

act ive which could potentially be a much longer length of t ime. 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 sensit ive information may or may not be backed up. Addit ionally,

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 invest igative analysis of any data breach or compromise of law enforcement

information.



8

Emergency access to data and Disaster Recovery plans for the provider should be explicit ly

defined in the SLA. The SLA must include clear definit ion of priorit ies for restorat ion of

provider services and the support priorit ies given the government cloud services in specific

disaster scenarios to include large scale man-made disaster scenarios.



9

Disaster Recovery & Business Continui ty

Cloud service provider facilit ies may be affected by natural or man-made disasters that

occur at a significant physical distance from the organizat ional customer base. However,

service loss to local customers may st ill 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

priorit ies 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.



0

Non-local data storage that results in loss of access to local law enforcement data during

large scale man-made disasters could crit ically impede the invest igation 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 quest ions 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 explicit ly specify t imelines 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 destruct ion if the cloud service



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 responsibilit ies on the

sanit izat ion of data from media and ret ired devices.

I t should also contain SLA’s within the following crit ical 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 Resolut ion Times

Guaranteed Escalat ion Times

Penalt ies for failure to meet those t imes

If the CSP does not offer these in writ ing then, think twice



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

Commercial cloud service providers may re-organize or sell/buy business units to/from other

companies. This may cause modification to exist ing cloud services or changes in the

nationality of service administrators.

Upon discontinuation of cloud services (either by customer request, provider dissolut ion, or

provider request) it may be impossible to verify that all ancillary or residual data has been

properly sanit ized 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



4

Periodic Disaster Recovery & Business Continui ty 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

I f possible, I encourage all businesses to perform regular failover test ing 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 t ill it ’s a real

emergency to find out if your backups are working or not…



5

D.R. & B.C. TESTING

I f possible, get it put in your contract that YOUR COMPANY and the CSP will “Joint ly” work

together to perform scheduled validation test ing for both your Disaster Recovery & Business

Continuity Plans, Policies & Procedures

PERIODIC TSE SLA TESTING

I recommend to all of my clients that periodic scheduled test ing of the CSP’s “Technical

Support Engineer” staff be put to the test by init iat ing a planned disruption and then t iming

their response as well as their resolut ion. In this way you can keep a sense of the quality of

the staff the CSP is hiring, as well as their quality of t raining.



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

Saved Netscape 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 massively complex, 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

http://cloudwiser.wordpress.com/

http://www.atheneum-partners.com/experts/ridlinghafer-jarrett-neil-1060486

http://compasscentral.com/

http://synapsesynergygroup.com/

http://4dhealthware.com/

security & compliance in the cloud - hadoop magazine column version 1.2 by jarrett neil...

Documents

email data encryption

hardware key encryption

software key encryption

data disk aka data

data transmission

public cloud confidential

rest encryption methods

encryption server hardening