A Conversation About Cloud Computing and Security

A Conversation About
Cloud Computing and Security
Joe St Sauver, Ph.D. ([email protected])
NWACC Security Meeting, October 10th, 2013
Disclaimer: all opinions expressed are solely those of the author and
do not necessarily represent the opinion of any other party
I. Introduction
Thanks and A Disclaimer
• I’d like to begin by thanking Adrian Irish of UMT and
NWACC for the chance to talk about cloud computing
security today.
• Adrian and Molly and the whole NWACC team put a lot of
work into this event, and I really appreciate the opportunity
to be part of it.
• I also wanted to remind folks that all opinions expressed this
morning represent solely my own perspective, and do NOT
necessarily represent the opinion of Adrian, UMT, NWACC,
Internet2, InCommon, nor the University of Oregon.
BTW, Speaking Of Organizations...
• Before we dig into cloud security, let me make a brief plug
for some security-related job opportunities, if anyone in the
audience knows of someone who might be interested:
-- The University of Oregon is seeking to hire a
Chief Information Security Officer, see
-- Internet2 would like to hire a
Chief Cyberinfrastructure Security Officer, see
-- ISOC would like to hire a Trust and Identity Lead,
see http://www.internetsociety.org/jobs/trust-identityprogram-lead
Format of This Talk
• Yes, this is another oddly-formatted "Joe talk."
• For those who haven't seen one of my talks before, I make
them verbose so they’ll be readable after the fact for those
who couldn't be here today, as well as for search engines,
readers for whom English is a second language, the hearing
impaired, etc. Please don't let my odd slide format shake
you up. :-) I promise I won’t read my slides to you, nor do
you need to try to read them as I talk.
• I also want to explicitly encourage you to ask questions as
we go along, or to question/challenge things I may say. As
the title of this talk hints, I truly want this to be a
conversation, not just me yammering for 90 minutes.
What Cloud Security Topics Are YOU
Interested In/Thinking About?
• To help get people comfortable speaking up, let's take a few
minutes and go around the room...
• What's your name and school?
• Is your school currently doing anything in the cloud?
• Do you have any specific cloud security concerns or
Some Context: Past NWACC Talks
• I've been pleased to have had the opportunity to talk at a
number of prior NWACC events, including doing talks on:
-- The Security of Mobile Devices in 2010,
-- Passwords, at an NWACC Security event in 2009,
-- The Inescapability of Convergence (Unless You
'Help'), 2006, http://pages.uoregon.edu/joe/convergence/
-- Winning the War On Spam, June 2003,
http://pages.uoregon.edu/joe/spamwar/winning-the-war-onspam.pdf and even, way back when:
-- Thinking About Your Wide Area Connectivity, in 2001,
• Today, though, we're going to talk about cloud security.
This Is My First Talk on Cloud Security for NWACC, But
It Is Not My First Cloud Security Talk...
• Internet2 NET+ Technical Architecture: An
Introduction to Security Considerations,
Internet2 Member Meeting, April 2012,
• Updates on Two Topics: The Security of Cloud
Computing and The Security of Mobile Devices,
Internet2 Member Meeting, April 2010,
• Cloud Computing and Security Considerations,
Internet2 Joint Techs, February 2010,
• Hopefully the thoughts in those will be consistent with
what I tell you today :-)
II. Why Talk About
Cloud Computing Security?
And Why Talk About
Cloud Computing NOW?
Answer: The Cloud's Here/Coming,
and Security Is In The "Critical Path"
When It Comes to Cloud Adoption
Seems Like EVERYONE's Now At
Least Considering the Cloud
• "94% of Enterprises are at least discussing cloud or
cloud services"
"Avoiding the Hidden Costs of the Cloud," PDF page 4,
Trendy Pundit Jargon: "Third Platform"
• Platform One: mainframe and terminals (pre-1985)
• Platform Two: LAN/Internet, Client/Server, PC ('85-'05)
• Platform Three: Mobile Broadband, Big Data/Analytics,
Social Business, Cloud Services, Mobile Devices and Apps
• 3rd Platform technologies currently "represent just 22% of
ICT spending," but are believed to account for 98% of
growth by 2020... Hmm.
• See for example figure 1
"Top 10 Predictions 2013: Competing on the 3rd Platform,"
Cloud-Based Services Are Also A
Major Focus for Internet2
• I work with Internet2 and InCommon under contract through
• If you're paying attention to what Internet2's been working
on, it's been hard to miss that NET+ is a major area of
emphasis now (and for the last year or so), see
• Given that, if you are at an Internet2 school, your institution
might end up (a) sponsoring a cloud-based NET+ service, or
(b) participating as a service validation or early adopter
school, or (c) simply using a NET+ service.
Thus, the security of cloud-based services might be an area
that touches you personally/professionally.
• But let's take a second to talk a little about cloud adoption
Some Sites Decide to Use
The Cloud. Others DON'T. Why?
• Is it a substantive matter of the features/functionality
available from cloud provider's products or services?
• Is it a business matter, perhaps how much the product or
service cost, or the terms of the agreement available?
• Or is the problem with infrastructure issues, maybe?
For example, perhaps the service doesn't integrate well with
your current identity management system, or requires
network bandwidth you don't currently have?
• Or is security (or privacy, or compliance) the problem?
What do we empirically know?
Security As Potential Block to Adoption
• "PC Connection, in partnership with Cisco, recently released
the results of its 2013 Outlook on Technology: Cloud
Computing Survey. The survey, the results of which are
available at InfoWorld, queried over 500 organizations of all
sizes to ascertain what they are seeking in a cloud solution,
what concerns they have about the technology and what
obstacles they see between their organization and further
cloud adoption. [...] Perhaps the most surprising
information gleaned from the cloud computing usage
survey is that security is the top obstacle to cloud
adoption, according to 65 percent of the survey
responses. Integration was the next biggest obstacle, but it
was listed in just 34 percent of responses." "Cloud Computing
Usage: Security Still Considered a Barrier,"
Or Does Using The Cloud Actually
IMPROVE Data Security?
• "Fifty-one percent of IT executives surveyed believe that
the cloud increases data security overall.
However, almost 70 percent of respondents indicated that
consumer cloud services pose a risk to sensitive data in
their organizations and 45 percent are not fully confident
that their cloud provider’s security processes and
programs meet their data security requirements."
"Data security, compliance top concerns of cloud adopters"
Some Proceed To Move To The Cloud,
Even If There May Be "Security Issues"...
• 'A new report by the agency's Office of the Inspector
General says that NASA needs to work on strengthening its
information technology security practices. [...] According to
the report, NASA had five contracts for cloud hosting
and none of these "came close" to meeting data
security requirements. [...] Over the past year, NASA spent
less than 1 percent of its $1.5 billion annual IT budget on
cloud computing. However, moving forward, the agency
plans to dedicate much more to cloud security and
initiatives. Within the next five years, NASA is planning
to have up to 75 percent of its new IT programs begin in
the cloud and 100 percent of
the agency's public data stored in cloud.'
"NASA Falls Short on Its Cloud Computing Security," http://news.cnet.com/83011009_3-57596053-83/nasa-falls-short-on-its-cloud-computing-security/
What Gets Moved Into The Cloud May Not
Stay There. Why? "Security Concerns"...
• "IDG Enterprise recently published Cloud Computing: Key
Trends and Future Effects Report, showing how enterprises
continue to struggle with security, integration and
governance [...] IDG’s methodology is based on interviews
with 1,358 respondents [...] 42% of cloud-based projects
are eventually brought back in-house, with security
concerns (65%), technical/oversight problems (64%), and
the need for standardization (on one platform) (48%) being
the top three reasons why. [...]
For IT, concerns regarding security (66%), integration
stability and reliability (47%) and ability of cloud computing
solutions to meet enterprise/industry standards (35%)
challenge adoption.
Security May Not Be The Only Issue
• Sometimes folks talk about "security" when they're really
worried about something else, like privacy:
-- If I store my confidential data in the cloud, will it end
up disclosed to unauthorized parties?
• Or compliance:
-- If I use the cloud, will I inadvertently violate some
compliance requirement, and get fined or otherwise
• Not all cloud providers treat privacy issues the same way
EFF's "Who Has Your Back?" Privacy
Those columns of stars are,
from left to right:
Requires a warrant for content
Tells users about government
data requests
Publishes transparency reports
Publishes law enforcement
Fights for users' privacy rights
in courts
Fights for users' privacy rights
in Congress
Privacy Concerns May Also Shift Some
Users Away From American Cloud Providers
• ITIF reported in August 2013 that one consequence of the
NSA's PRISM interception program is that "On the low end,
U.S. cloud computing providers might lose $21.5 billion
over the next three years. This estimate assumes the
U.S. eventually loses about 10 percent of foreign market
to European or Asian competitors and retains its currently
projected market share for the domestic market."
• BUT, the Cloud Computing Security Alliance, reporting on a
survey of cloud adoption post-Snowden, reported that "56%
of non-US residents were now less likely to use USbased cloud providers, in light of recent revelations about
government access to customer information."
Is Europe Really Any Better, Privacy-Wise?
• Europe was once fairly famous (notorious?) for having
stringent data protection requirements, see
http://ec.europa.eu/justice/data-protection/ but consider:
• "The FRA law (FRA-lagen in Swedish) [...] authorizes the Swedish
Defence Radio Authority to warrantlessly wiretap all telephone and
Internet traffic that crosses Sweden's borders. It [...] took effect on
January 1, 2009." http://en.wikipedia.org/wiki/FRA_law
• "BND lässt sich Abhören von Verbindungen deutscher Provider
genehmigen," [BND (the Federal Intelligence Service) can authorize
[the] interception of German provider connections],
• "UK government is one of the world's top pryers into user data on
Facebook and Twitter,"
Speaking of "European" Cloud Security
• I don't mean in any way to make light of the extremely
serious events that took place during WW II, but there's a
humorous spoof on cloud security that was put together by
Marcus Ranum that's too good to overlook:
• http://www.youtube.com/watch?v=VjfaCoA2sQk
Some Potential Compliance Hurdles
• Depending on the sort of stuff you're working with, other
applicable compliance regimes could include:
-- Breach notification laws (47 different state laws!)
-- CAN-SPAM (anti-spam laws)
-- DIACAP (a DOD compliance thing)
-- FERPA (higher education privacy)
-- FIPS 140-2 (crypto standards)
-- FISMA (federal contractors)
-- GLBA (certain financial data)
-- HIPAA/HITECH (health data)
-- Human Subjects Research Data Protection
-- ITAR (export controlled technologies and research)
-- PCI (payment cards)
-- SOX (accuracy of financial information)
-- etc., etc., etc.
Just ONE Compliance Area: HIPAA
• Covered entities must be in compliance with the HIPAA
Omnibus Rule as of 9/23/2013, see
http://www.gpo.gov/fdsys/pkg/FR-2013-01-25/pdf/201301073.pdf (138 pps)
• As part of that the so-called "conduit exception" has been
clarified to NOT include "data storage companies"
... We note that the conduit exception is limited to transmission services
(whether digital or hard copy)… In contrast, an entity that maintains protected
health information on behalf of a covered entity is a business associate
and not a conduit, even if the entity does not actually view the protected
health information…the difference between the two situations is the transient
versus persistent nature of that opportunity. For example, a data storage
company that has access to protected health information (whether digital
or hard copy) qualifies as a business associate, even if the entity does not
view the information or only does so on a random or infrequent basis.
(emphasis added) [PDF page 8, FedReg page 5572]
• To store Protected Health Information (PHI) in the cloud, you
WILL need a BAA (Business Associate Agreement).
Will Cloud Providers Execute BAAs?
• If you want to use a cloud provider for PHI, and the cloud
provider won't execute a BAA, compliance requirements will
stall your cloud deployment.
• Why might a cloud provider "balk" at executing a BAA?
Many cloud providers try to maintain a strict demarc, with
security and compliance responsibilities split between the
provider and the customer at the demarc.
• BAA's potentially drag the cloud provider back "across that
demarc," and may entangle them in expensive PHI
breaches caused by factors over which they ultimately have
little or no control. Penalties for HIPAA security violations
can run up to $1.5 million per year per incident.
• But, if you aren't willing to do BAAs, you're probably going to
have to forego a lot of health-care-related customers...
One Cloud-as-Infrastructure Provider...
Another Timing Factor: Some Standards Are
Still Being Developed; Maybe You Should
Chime In/Help With This Work?
ISO/IEC 27017 [...] This standard will provide guidance on the information
security elements/aspects of cloud computing, recommending cloudspecific information security controls supplementing those recommended by
ISO/IEC 27002 and indeed other ISO27k standards including ISO/IEC 27018 on
the privacy aspects of cloud computing, ISO/IEC 27031 on business continuity,
and ISO/IEC 27036-4 on relationship management, as well as all the other
ISO27k standards covering information security in general. [...]
The standard is at Working Draft stage. Publication is very unlikely before
2014, quite possibly not until 2015. Over 200 pages of detailed comments
from national bodies are being digested and integrated into the next draft. The
comments are generally positive and helpful, but it inevitably takes time to
discuss and agree so many through in-person committee meetings [...] SC 27
decided NOT to progress a separate cloud information security management
system specification standard, judging that ISO/IEC 27001 is sufficient.
Therefore, there are no plans to certify the security of cloud service
providers specifically.
III. What Is Cloud Computing?
Now That We Know People Worry About
Security (and Privacy, and Compliance) In
"The Cloud," What Exactly Is "The Cloud?"
• Infrastructure (compute cycles, storage, database, etc.)
available on demand from a pre-provisioned pool (example:
Amazon AWS, see http://aws.amazon.com/ ), sometimes
referred to IAAS ("infrastructure as a service")
• Apps that run somewhere "out there" on infrastructure you
don't run or rent (example: Google Apps for Education, see
http://www.google.com/enterprise/apps/education/ ), often
called SAAS ("software as a service")
• And then, largely for developers, there's "platform as a
service" (PAAS) outfits; one example of this would be
RedHat's OpenShift, see https://www.openshift.com/ ,
running somewhere in between IAAS and SAAS
I'm Renting a Server From A Hosting
Company. Am I Using "The Cloud?"
• No. Just outsourcing the hosting of a server isn't enough to
make you a user of "the cloud."
• Why? Most notably, your capacity isn't "highly elastic."
If you get /.'d and temporarily need a lot more capacity, you
can't quickly get it, you may need to enter into a year long
contract, and if you no longer need the contracted server
after a few weeks, well, that's too bad.
• You may also still need to administer the system from the
"bare iron" on up, which again is inconsistent with "cloud"
concept. In the cloud, you don't need to worry about actual
infrastructure devices.
• You may even know where "your" server is located
(example: server 26, rack 209, datacenter foo, Dallas, TX)
I'm An End User Using Gmail.
Am I Using "The Cloud"?
• Yes. Gmail (and associated applications such as Google
Apps for Education) are in many respects a perfect example
of "software as a service."
• Another very common example of a cloud-based SAAS
application is a file sharing service, such as Box or DropBox.
• Peer-to-peer file sharing services, on the other hand, such
as BitTorrent, wouldn't typically be considered to
be "in the cloud."
I'm Backing Up Stuff From My Smartphone
Online Somewhere. Am *I* Using the Cloud?
• Yes. Backups of content from mobile devices (such as smart
phones and tablets) would be a prime example of how users
may be engaging with the cloud.
• In fact, mobile devices largely REQUIRE cloud-based
backups because on-device storage may be limited, and
opportunities for external expansion may be limited
(typically, at best, you might be able to plug in something
like a 32GB MicroSDHC card).
• Backups are particularly important for mobile devices given
that mobile devices disproportionately often end up lost,
stolen, or broken...
My Campus Is Running a "Private Cloud" –
Surely I'm Using "The Cloud," Aren't I?
• From my POV, it depends. Some people just call a local
compute cluster a "Private Cloud" because "private cloud"
sounds cool/trendy.
• To really qualify as a cloud service, I'd be looking for:
-- substantial pool of resources shared among many users
with plenty of headroom for handling peaking loads
-- an interface that's compatible with things like the
Amazon EC2 public cloud (two examples: Ubuntu's
OpenStack and the nimbusproject.org)
• Things like "publicly hosted" "private clouds" make my head
hurt, definitionally-speaking. :-)
I'm Using XSEDE for Scientific Computing.
What About Me? Am I Using "The Cloud?"
• XSEDE, the follow-on project to the TeraGrid, certainly has
many "cloud-like" characteristics, but typically the XSEDE
folks treat "the Cloud" as being something that they
themselves are not.
• So I'd say, "not."
• See for example: "XSEDE Cloud Survey Report,"
IV. So What Are The Risks
If We "Go To The Cloud?"
The "A" in The Security "C-I-A" Objectives
• As I'm sure everyone knows, computer and network security
is fundamentally about three goals/objectives:
-- confidentiality (C)
-- integrity (I), and
-- availability (A).
• Availability is the area where cloud based infrastructure
appears to have had its largest (or at least most highly
publicized) challenges to date.
• For example, consider some of the cloud-related
outages which have been widely reported…
Some Major Cloud Outages in 2013 (as of 1 July)
• Nice summary from InfoWorld, "Worst Cloud Outages of
2013 (So Far),"
• Amazon, January 31st, less than an hour
• Dropbox, January 10th, 16 hours
• Facebook, January 28th couple of hours
• MS Bing, February 2nd, couple of hours
• MS Office 365/Outlook, February 1st, couple of hours
• MS Azure, February 22nd, over 12 hours
• Google Drive, March 18-19th, 17 hours total
• CloudFlare, March 3rd, about an hour
• Dropbox, May 30th, about an hour and a half
• Twitter, June 3rd, about 45 minutes
A More Dire Thing: Provider Bankruptcies
The Three Cloud Bankruptcy Issues...
• If you prepaid (to lock in prices/get a multiyear discount), is
that prepaid money in escrow somewhere (and able to be
refunded), or is it flat out gone?
• Can you find a replacement provider that will be able to take
over when it comes to providing the same service your
former cloud provider delivered? (standardized services will
obviously be easier than unique applications)
• Perhaps most critically: can you get your data out, and in
format that's usable elsewhere?
Cloud Lock-In: If You Want To Exit The Cloud,
Will You Have the Local Expertise You Need?
• One risk of letting someone else do the heavy lifting for you
for a while is that if you need to resume doing that work
yourself, it can be a lot harder to get back up to speed than
you might think.
• Will you still have key staff?
• Will you still have critical facilities?
• Can you deliver the professional quality of the services or
application you got from the cloud? (It's not uncommon for
some parts of a cloud service to be terrific, while others may
drive you nuts)
Digging Down On A Specific Technical
Availability Risk: Network Connectivity
• In the (public) cloud computing model, users are local but
critical resources are hosted elsewhere.
• Connectivity thus is of paramount importance: if the network
is "down," you won't be able to reach "the public cloud."
Some things to think about:
What might cause a network outage? Fiber cut? DDoS? Other?
Is the outage local, remote, or somewhere in between?
How much network IS "in between" me and my cloud provider?
How long might an outage last? Minutes? Hours? Days?
What would we do while we're down?
Do I need more network redundancy?
If I need to buy more redundancy, what will that cost?
Network Quality
• Besides just being available, you should also think about the
quality of your network connections. Will they be good
enough to support the cloud app you're thinking of fielding?
Depending on the app this may mean confirming:
• Do I have enough aggregate bandwidth?
• What sort of throughput can a single user achieve?
• Are there latency issues?
• Are there jitter issues?
• Am I going to be NAT'd, or will I have publicly addressable
IPs? Are those addresses "clean," or do those addresses
have reputation issues from previous users?
• Can I get IPv6 connectivity if I want or need it?
• Can I get jumbo frames if I need them? (9K MTU)
Mitigating Cloud Computing Availability Issues
• Risk analysts will tell you that when you confront a risk, you
can try to eliminate the risk, you can mitigate/minimize the
impact of the risk, or you can simply accept the risk.
• If you truly require non-stop availability, you can try using
multiple cloud providers, or you could use public and private
cloud nodes to improve redundancy.
• Some cloud computing services also offer service divided
into multiple "regions." By deploying infrastructure in multiple
regions, isolation from "single-region-only" events can be
obtained. Availability issues may also be able to be at least
partially mitigated at the application level by things like local
• Sometimes, though, it may simply make financial sense for
you to just accept the risk of a rare and brief outage.
• Cloud providers may be willing to help you meet whatever
service level agreements you need. For example, if
availability is of critical importance, you may be helped to
configure the cloud service you're providing so that it has a
high level of redundancy.
• However, as the saying goes, "You can get whatever level of
redundancy you need, but you're going to pay for what you
• The "more 9's" you need (e.g., 99% availability, 99.9%
availability, 99.99% availability, etc.), the more you're going
to pay because handling the weirdest potential corner cases
that can impact availability becomes increasingly difficult
(and thus expensive).
• 99.99 availability ==> 52+ minutes downtime/yr...
Cloud Application Availability Reporting
V. Confidentiality...
Data Confidentiality and Breaches
• But let's not get rat holed on availability.
• CIOs don't get fired for services going down (at least as long
as they don't go down for TOO long). CIOs do get fired for
big data breaches involving PII.
• Therefore, most CIOs worry a lot about the security of
private data, including its security if stored off-site.
• Should they? In some cases, yes.
• A couple of examples...
Protecting Data Confidentiality in the Cloud
• Protecting data in the cloud is often largely a matter of how
you encrypt private data at rest, and how you encrypt it
when it is in transit/on the wire.
• For web based applications, encryption of data on the wire
normally involves use of SSL/TLS ("https").
• While all SSL/TLS web sites may look more or less the
same, the quality of the encryption used by any given web
site may vary dramatically.
• I'd encourage you to check the SSL/TLS practices of sites
you care about using https://www.ssllabs.com/ssltest/
(caution: sometimes you will be disappointed!)
• You may also want to see an earlier talk of mine that's at
Protecting Data at Rest
• Protecting data at rest is often trickier.
• Some sites may do whole disk encryption when the system
is quiescent, but leave all data decrypted once the system
has booted up. If your worry is just theft of hardware, WDE
may be all you need, but in most cases the value of your
data >> value of the hardware it is sitting on.
• Therefore, strive to encrypt everything as much as possible,
as routinely as possible, and be sure to think about secure
cryptographic key storage (e.g., use a hardware security
module when possible). See an example of a service that's
offering HSM service in the cloud on the next slide.
Amazon's CloudHSM Service
Compulsory Access to Your Data
• Cloud providers may, under some circumstances, be
required to provide government authorities with access to
your data. This may be due to a court order, or as a result of
national security program, as was revealed in Edward
Snowden's recent leaks (see next slide)
• You may not be notified of government access, particularly if
the order served on your cloud provider prohibits the
provider from even disclosing the existence of that order to
• As is true for other potential confidential vulnerabilities, your
best bet is to use strong encryption so that your cloud
provider doesn't have the ABILITY to disclose confidential
information in unencrypted form.
VI. Integrity...
What About Data Integrity in The Cloud?
• Data integrity often seems to be the "red-headed step child"
of cyber security: many people seem to pretend this issue
doesn't exist.
• How do we rigorously know that the GB (or TB!) worth of
files we have stored are correct and un-tampered-with?
• Some of us may checksum critical files, but do we religiously
check those file checksums to ensure that nothing's
changed? And what about all the files we
DON'T check, eh?
• Some might ask is data integrity really that big a deal?
• Sure it is. We just don't think about it as "data integrity" or
"files being tampered with," we tend to run into it as "sites
getting hacked" or "defaced" or maybe systems getting hit
with "ransomware"
WordPress Plugin Issues As A Path To
Unauthorized File Modifications
vBulletin CMS Exploit  Full Control
The Feds Have Begun Paying Attention to
Server-Side Security Vulnerabilities
• For example, there's a new FCC Communications Security,
Reliability, and Interoperability Council (CSRIC) Working
Group that is specifically focused on DoS attacks that come
from servers rather than botted PCs.
• I view that as a particularly positive sign that people are
increasingly coming to realize that servers have some
unique risks of their own, due to things like their high level of
connectedness (e.g., gigabit links are common),
and pressures on administration practices (if you're selling
services at dirt cheap rates, you may not have a lot of
money available to vet customers, much less process abuse
complaints or do extensive security reviews).
Recovering From Data Corruption Issues
• The most common approach to recovering from data
corruption/unauthorized file modifications -- once they're
somehow detected -- is to restore data from a trusted
backup. When you're running systems locally, you also
probably arrange for them to be backed up, periodically
testing those backups for usability, etc.
• But what about in the cloud? Are you backing up data that's
there, too, somehow? Or are you trusting your cloud vendor
to do it for you?
• Data loss may be more common than you think...
Specific Example: T-Mobile's Sidekick Service, 2009
See http://www.engadget.com/2009/10/10/t-mobile-we-probably-lost-all-your-sidekick-data/
However, see also: Microsoft Confirms Data Recovery for Sidekick Users
Another Example: Amazon 2011
When You Start Looking at Cloud Backup
• Be sure to distinguish between backing up data TO the
cloud, and backing up what you currently have IN the cloud.
• Remember that our worry is "What happens when the data
you've got that was in the cloud that needs to be restored?"
Depending on what caused data to be lost or corrupted,
some strategies may not save you (example: mirrored data
can perfectly mirror data corruption caused by an
application flaw, right?)
• Some cloud providers have chosen to specifically focus on
cloud backup as a core competency, see for example:
VII. "Integrating" With The Cloud:
Another Area of Potential Concern
Campus Authentication
• In addition to the big three issues of availability,
confidentiality and integrity, you may also see more subtle
cloud-related security risks. For example, some cloud
providers may not do a very clean job of integrating with
your campus identity management system (e.g., they do
NOT do federated SAML-based authentication ala
Shibboleth and InCommon)
• Some providers may want to do something really, really
broken, like periodically syncing a copy of your credential
store to their systems (ooh, not good, not good at all), or
using your campus LDAP servers (also not a good model).
• Other providers may substitute their own identity
management system as a replacement for yours (hello,
OpenID providers).
We're Not Going To Rehash The Step-By-Step
Process By Which OpenID Works
• If you want a nice step-by-step summary of how OpenID
works, see the discussion and diagrams that are available at
• I also rather like:
"Single Sign-On For the Internet: A Security Story,"
While this is a 2007 document, it does a nice job of
summarizing not just how OpenID is meant to work, but
some of the ways that OpenID could potentially be abused
(at least if people are casual about how they implement/use
Google Is Not the Only OpenID Provider,
But It's Probably the Most Widely Used One
• There are literally hundreds of OpenID providers out there,
although just a handful account for the vast majority of
OpenID logins, see http://janrain.com/blog/what-are-mostpopular-networks-social-login-and-sharing-web/ which
quotes the values:
Windows Live: 6%
38% (cumulative %)
• That same article notes that OpenID provider popularity
varies with the type of web site that's being accessed.
Not All OpenID Providers Will Necessarily
Work The Way Originally Intended...
• For example, imagine an OpenID provider that provides a
redirection layer between an OpenID, concealing/protecting a
user's real email address from disclosure...
• This is not a hypothetical service – this is exactly what
LiquidID does, see http://liquidid.net/home.php (does this
remind you of privacy/proxy domain name registrations? It
sure strikes a chord for me in this respect...)
• Even more "interestingly," imagine an OpenID provider that
offers completely anonymous "throw away" OpenID
credentials, much in the way that Mailinator offers completely
anonymous throw away email addresses...
So What DOES Gets Shared When OpenID
Is Used? Answer: It Varies By Provider.
"Display Name, Homepage, Identifier, Preferred Username, URLs "
Facebook? LOTS More Gets Shared
Is Disclosing More Information About
Users A Good Thing, or A Bad Thing?
• If a legitimate service is relying on an OpenID for authentication,
having more information about a user helps them to potentially
identify and manage problematic users.
• On the other hand, if I'm a bad site attempting to leverage OpenID
to mine information about users, the more information that gets
shared with them, the bigger the potential risk to user privacy.
• Presumably privacy-aware users would prefer to use whatever
OpenID identity provider releases the LEAST information about
me (while still being acceptable to the services I use), but most
users just don't seem to know/care.
• One more point: virtually all of these user attributes are "selfasserted"/"user-supplied" – should you even bother paying
attention to them anyway? What if users simply choose to lie?
Using The Cloud -- Losing Your Logs?
• One of the really useful things you get when you run
services locally is log files. You get to see how your service
is used, and how people attempt to abuse it. Hopefully
you're doing that logging to a central log server.
• In some cases, when you move to the cloud, you may lose
access to those sort of log files, and that can really hurt
when it comes to your situational awareness. A major attack
may be going on, and you might not ever know (until it is
potentially too late).
• In other cases, logs are available for web-based review, but
not for centralized sysloging.
• Sometimes logs are available, but only if you specifically ask
for them to be made available...
End User Support and the Cloud
• You are probably used to locally support users of local
applications. One of the trickiest things to get used to is
recognizing that in the cloud, support may be a fully (or at
least partially) delegated responsibility.
• If a user has a problem, you may not be able to answer their
question. You may need to refer the user to a cloud
provider's support infrastructure, and that support may be
outsourced to a third party in the third world.
• Your users may or may not get good support as a result,
and in some cases that may negatively impact the security
of the work they do.
• You will also need to learn to live with not being able to have
direct access to a ticketing system operated by the cloud
VIII. Stepping Back For a Second...
What's The Basic Question Again?
Oh Yeah... "Should We Go Ahead
With Cloud Provider Foo, Or Not?"
And How Do We Decide?
"Should We Go Ahead With Cloud Provider
Foo Or Not?" -- Simple Question, Right?
• Only two basic answers, after all, "Yes," or "No."
• Presumably you make comparable go/no-go decisions for
non-cloud-related technologies all the time:
-- Is the campus data center secure enough?
-- What operating systems should we recommend (or ban)?
-- How can we mitigate the risks arising from malware?
-- Is our learning management system FERPA-compliant?
-- Do we need a new policy to deal with unencrypted data
on desktops or laptops?
• For stuff not in the cloud, you have myriad sources of local
data to help you reach a decision...
Investigating Local Security Concerns
• For stuff that's NOT in the cloud, it's easy to locally find out
what's going on:
-- Look at your logs
-- Check your passive monitoring infrastructure
-- Actively scan the relevant systems
-- Reach out via phone/email/IM
-- Have meetings with coworkers and users
-- Consult the campus IT ticketing system
-- Walk over and pick up a compromised system for
forensic review
-- Talk to local developers
-- Discuss issues with university counsel or internal audit
• This is the sort of stuff you're used to doing every day.
Security Concerns In The Cloud
• It's a little trickier when stuff's "in the cloud:"
– You don't run the gear.
– You don't hire the staff (often you don't even know
who the staff are!)
– You (often) can't scan the cloud installation.
– You don't monitor the internal cloud provider network.
– You (normally) don't get to set the cloud provider's
– Terms and conditions may be a take-it-or-leave-it matter.
– etc., etc., etc.
That Said, In Some Ways, "Cloud Computing
Security" Is No Different Than "Regular Security"
• For example, many applications interface with end users via
the web. All the normal OWASP web security vulnerabilities -things like SQL injection, cross site scripting, cross site
request forgeries, etc., -- all of those vulnerabilities are just as
relevant to applications running on the cloud as they are to
applications running on conventional hosting.
• Similarly, consider physical security. A data center full of
servers supporting cloud computing is internally and
externally indistinguishable from a data center full of "regular"
servers. In each case, it will be important for the data center
to be physically secure against unauthorized access or
potential natural disasters. There are no special new physical
security requirements which suddenly appear simply because
a facility is supporting "cloud computing"
Physical Security at an Oregon Cloud Provider
Cloud As A "Tycho Magnetic Anomaly"
• The cloud may normally be represented by a fluffy white
blob, but the cloud's is actually more like a "black box." You
end up needing to figure out what's happening inside of it
without being able to open it up or even touch it.
• Remember Arthur Clarke's Space Odyssey books? If not,
see http://en.wikipedia.org/wiki/Monolith_%28Space_Odyssey%29
• Think of a cloud provider as being just like one of
Clarke's black monoliths: even though it may have
some sort of mysterious force field that keeps you from
directly touching it, you still have to decide what it
means, if it's safe to have around, and what (if anything)
you need to do about it.
• When you get right down to it, the primary way you're going
to do that is by asking questions.
Asking Q's About Cloud Provider Security
• But do you actually want to directly ask questions of the
cloud provider? Or are you willing to just "take the cloud
provider's word for what they're doing," perhaps by just
reviewing documentation they've already written?
• If you do want to ask questions of the providers, do you
want to ask a bunch of questions that you yourself
personally dreamed up, perhaps uniquely well tailored to
probe unique security aspects of that particular provider?
• Or would you prefer that a qualified auditor/external
assessor asked questions, and you just got to see an audit
report? (Would you be willing to sign an NDA to get it?)
• Or do you want to ask questions of others who currently use
that cloud-based service? (But what if it's a brand new
service, and you are one of the first users of it?)
Taking the Provider's Word For It....
• If you're tempted to try this route, you might hear...
• "Check out their security website. It's all there, and they
won't tell us anything beyond what's on it anyhow, so I
guess we'll just have to take their word for it."
• "Millions of other users trust these guys, so it's probably safe
for us to do so too, right? They're really big, and they seem
really smart, so surely they wouldn't screw up anything
important about their security, would they?"
• "They're much cheaper (or "free!"), so it's worth taking a
chance on them -- heck we couldn't afford to do [insert
service name] ourselves if we couldn't get it from them..."
• "Legal okayed it. Don't second guess the attorneys.
If something goes go wrong, they'll sue them for us."
Asking Your Own Set of Questions...
• If you try this route, hypothetically you might hear...
• "We'll schedule a conference call, and you can ask any
security questions you might have then."
• "[on the call] Let's just start with your half dozen biggest
questions. We don't want to get hung up over 'hundreds' of
'techy' security questions..."
• "[next call] What? You've got still more questions? I thought
we took care of all those during the last fifteen minutes of
the last call... it isn't fair to just keep coming up with new
security question after question..."
• "[by email] Look. We've got thousands of customers. We
can't answer long lists of unique security questions for each
customer... We'd have to charge 100X what we do..."
"We'll Review Their Audit Reports"
• What exactly will you be looking for? What would be a
"deal breaker," if you saw it in an audit report?
• Some new providers may NOT have been audited at all.
Getting audited "just for you" may be expensive, and not
something they're interested in doing. What then?
• Not all audit reports are the same, so which one(s) do you
want? For example, assume your choice is SOC-1, SOC-2,
or SOC-3? (FWIW, AWS offers all three SOC reports, see
https://aws.amazon.com/compliance/#third-party )
• Providers may be reluctant to share a non-redacted audit
report with you (although a major potential customer who is
willing to sign an NDA to get access to an audit report may
have better luck than a smaller-scale customer who is not
willing to sign an NDA)
• How often will any audit need to be repeated?
"Checking References"
• Asking others who may be using the cloud service may give
you some insights into what they've seen, but...
• Your site and the reference site(s) may not have the same
infrastructure, or the same planned usage, or the same
tolerance for risk, etc.
• Pesky NDA terms may limit a colleague's ability to candidly
share what they've learned (at least "on the record"/for
• Just like talking to references for a new potential employee,
you usually end up getting referred to those who have
positive opinions (for some reason)
• Oral reports are not very comparable, if you're trying to
evaluate multiple potential options side-by-side.
IX. "I Highly Support Standards. That's
Why We All Use Our Own."
Using a Standardized Security Framework
• Another option: If we want to do a systematic review of
cloud provider security, maybe it would make sense to use
some sort of standardized security framework?
• If we all agree to use the same one, a provider would only
need to complete one framework, and because the
framework would be standardized, we could:
-- Be comfortable that we haven't overlooked anything
-- Easily compare the responses from provider A with the
responses from provider B
-- Not have to wait while a provider answers a newly
written set of security questions
• If we all agreed to use the same security framework,
providers could just complete that one, confident that it
would handle the lion's share of the questions from users.
Whose Security Framework Should We Use?
• Cloud security frameworks have been developed by many
agencies/organizations, including:
-- Cloud Security Alliance
-- GSA
-- ISO
-- Jericho Forum
Which Security Framework Should We Use?
• Even if we pick a particular organization, such as the Cloud
Security Alliance, they may still have multiple security
frameworks available. For example, CSA has the
Consensus Assessments Initiative Questionnaire (CAIQ) as
well as the Cloud Controls Matrix (CCM).
• Even if we pick the CSA CCM, there may be multiple
versions of it in circulation:
-- CSA CCM v1.4
-- CSA CCM v3.0
The "Goldilocks Problem"
• Just like Goldilocks and the Three Bears, some cloud
security frameworks may be too simple, other cloud security
frameworks may be too complex.
• The trick is finding one that's "just right."
• What about FedRAMP? It may be an example of a
framework that's TOO tough, with just ten
FedRAMP-certified cloud services to-date.
Just 10 FedRAMP-Certified Services
CSA STAR Registry
• On the other hand, there are 37 companies listed on the
CSA STAR (Security, Trust & Assurance Registry) list, see:
• Listing on the STAR registry is based on completion of a
relatively simple self-assessment, the CSA CAIQ
(pronounced "CAKE"). Many of these items may end up
being responded to with just a "Yes" or "No" response (you
can review CAIQ self-assessments for providers of interest
on the web site).
• If a provider makes just a pro forma yes/no response to
each item, in my opinion, that's really not very helpful.
It's *too* much of just a "checklist" approach.
• We need something in between FedRAMP (too much), and
CSA STAR (too little). Fortunately, there's the CSA CCM.
CSA Cloud Controls Matrix
• The CSA Cloud Controls Matrix (CSA CCM) is the security
framework that I've previously suggested Internet2 use with
its NET+ providers.
• Sometimes folks wonder how the CSA CAIQ and the CSA
CCM relate... While the CSA CAIQ aligns with what the CSA
CCM also covers, the CAIQ is basically a checklist while the
CCM provides an outline for preparation of a narrative
whitepaper covering relevant security topics in depth
• The CSA CCM approach also avoid any problems that may
be associated with completing a checklist but
NOT FIXING any issues that may be exposed as a result. If
you complete a CSA CCM-based whitepaper talking about
your approach to security, it becomes quite difficult to gloss
over/ignore areas where deficiencies may exist.
CSA CCM 1.4 vs. CSA CCM 3.0
• The version of the CSA CCM that I originally recommended,
v1.4, had just under a hundred questions. Candidly, one of
the reasons I liked it was that it was relatively brief (you
might not think I like succinct paperwork given the length of
my talks, but really, I do)
• Community-wide experience with the 1.4 version of the CSA
CCM lead to the realization that it didn't cover everything.
Thus, the most recent version of the CSA CCM, v3.0,
released in late September, now has 136 items, obviously a
significant expansion.
• Internet2 is currently considering whether it wants to move
to CSA CCM v3.0 (my recommendation would be that we do
so). In fact, my recommendation would be that we routinely
roll to new versions of the CSA CCM, as they may be
What Controls ("Rows") are in CSA CCM?
• To see, download a copy at
• Its 136 rows ("controls") are grouped into 16 topical areas:
1) Application & Interface Security
2) Audit Assurance & Compliance
3) Business Continuity Management & Operational
4) Change Control & Configuration Management
5) Data Security & Information Lifecycle Management
6) Datacenter Security
7) Encryption & Key Management
[continued on the next slide]
What Controls ("Rows") are in CSA CCM? (2)
• 8) Governance and Risk Management
9) Human Resources
10) Identity & Access Management
11) Infrastructure & Virtualization Security
12) Interoperability & Portability
13) Mobile Security
14) Security Incident Management, E-Discovery & Cloud
15) Supply Chain Management, Transparency and
16) Threat and Vulnerability Management
• Many of the items in each of these areas are pretty basic
"common sense" items.
Items From One of Those 16 Areas:
Threat and Vulnerability Management
• TVM-01, Anti-Virus / Malicious Software:
Policies and procedures shall be established, and
supporting business processes and technical measures
implemented, to prevent the execution of malware on
organizationally-owned or managed user end-point devices
(i.e., issued workstations, laptops, and mobile devices) and
IT infrastructure network and systems components.
Items From One of Those 16 Areas:
Threat and Vulnerability Management (2)
• TVM-02, Vulnerability/Patch Management:
Policies and procedures shall be established, and
supporting business processes and technical measures
implemented, for timely detection of vulnerabilities within
organizationally-owned or managed (physical and virtual)
applications and infrastructure network and system
components, applying a risk-based model for prioritizing
remediation through change-controlled, vender-supplied
patches, configuration changes, or secure software
development for the organization's own software. Upon
request, provider shall inform customer (tenant) of policies
and procedures, especially if customer (tenant) data is used
as part the service and/or customer (tenant) has some
shared responsibility over implementation of control.
Items From One of Those 16 Areas:
Threat and Vulnerability Management (3)
• TVM-03, Mobile Code:
Policies and procedures shall be established, and
supporting business processes and technical measures
implemented, to prevent the execution of unauthorized
mobile code, defined as software transferred between
systems over a trusted or untrusted network and executed
on a local system without explicit installation or execution by
the recipient, on organizationally-owned or managed user
end-point devices (e.g., issued workstations, laptops, and
mobile devices) and IT infrastructure network and systems
The Columns In the CSA CCM
• When you look at the CSA CCM and scroll across, you'll see
that there are also multiple columns in the spreadsheet:
-- A: Major control area and control name (e.g.,
"Threat and Vulnerability Management: Mobile Code")
-- B: Control ID number (e.g., TVM-03)
-- C: Control specification (narrative text of the control)
-- D-I: Architectural Relevance (compute? storage? net?)
-- J: Corp Governance Relevance?
-- K-M: Cloud Service Delivery Model Applicability
(Software as a Service? Platform as a Service?
Infrastructure as a Service?)
-- N-O: Supplier Relationship (Service Provider?
The Columns In the CSA CCM (2)
• -- P: AICPA TS Map
-- Q: AICPA Trust Service Criterial SOC 2SM Report)
-- R: BITS Shared Assessments AUP v5.0
-- S: BITS Shared Assessments SIG v6.0
-- T: BSI Germany
-- U: CCM V1.X
-- V: COBIT 4.1
-- W: CSA Enterprise Architecture/Trust Cloud Initiative
-- X: CSA Guidance v3.0
-- Z: FedRAMP Security Controls, Low Impact Level
-- AA: FedRAMP Security Controls, Moderate Impact Level
The Columns In the CSA CCM (3)
• -- AB: GAAP
-- AD: ISO/IEC 27001
-- AE: Jericho Forum
-- AG: NIST SP800-53 R3
-- AI: PCI DSS v2.0
• The columns from P-AI are particularly helpful because they
allow you to see how the controls present in the CSA CCM
map to the requirements of most of the other popular
security frameworks you might encounter.
The CSA CCM Does Not Highlight Controls
OTHER Frameworks Require That Are Missing
• If you were to take SP 800-53 R3, and build a new
spreadsheet where each row was one control required by
SP 800-53, you could then check to see which of those
controls are (or aren't) covered by the CSA CCM.
• You CAN'T get that information from the current CSA CCM
spreadsheet because the ONLY controls listed in the CSA
CCM are the ones that the CSA CCM ALREADY HAS.
• That is, the CSA CCM lets us answer the question, "Is what
the CSA CCM requires consistent with what other security
frameworks require?" (And the answer would be largely
• It does NOT help us answer the OTHER (perhaps more
interesting) question, "Are there things the other frameworks
require that are missing from the CSA CCM?"
Are There Things That Are Missing
From Even v3.0 of the CSA CCM?
• Sure. What's missing depends on what you care
about/where you're coming from.
• For example, when I first recommended that Internet2 use
the CSA CCM, Bob Brammer was very concerned that the
CSA CCM might not include everything that higher
education cared about. For example, the CSA CCM has no
controls specifically focused on FERPA-related issues
(probably because FERPA's not a big deal for most folks
outside of higher education). I'm also not seeing anything
about SAAS accessibility (e.g., for blind or deaf users).
• Does this mean that the CSA CCM is a failure, or can't be
used by higher ed? No, it's just an example of an area
where supplemental compliance items may be required to
cover areas of specific interest to our sector.
What's A "Passing Score" on the CSA CCM?
• For example, does a site need to have all controls perfectly
addressed? 90% of them? A majority of them in some form
or another? What if they're all just TBD/in progress?
• There's no right or wrong answer to any item, and many
different approaches could work. A stronger response to one
item might offset a weaker response to another.
• Sometimes, just seeing HOW a company responds to a
CSA CCM item can be very instructive -- do they take the
process seriously? Do they just try to get it out of the way as
quickly as they can, treating it as if it were a checklist? Do
they have answers that appear to be internally inconsistent?
• Higher ed understands grading essay exams, theses, and
disserations. :-)
Every Site's Needs May Be Different
• Another reason why we don't want to have a "passing
score" on the CSA CCM is that even if we agree on the set
of questions we're going to ask, what's an acceptable
answer to those questions may vary from site-to-site.
• For example, site A may be interested in offering an easy-touse free application for student recreational use, and they
may have minimal security concerns as a result.
• Site B, on the other hand, might want to deploy a missioncritical application for use in their medical facility, triggering
significant worries about availability, data privacy,
compliance, etc.
• Different sites, different requirements, different thresholds
for what's acceptable.
• One uniform passing score wouldn't work for everyone.
The Goal: Give YOU The Data You Need
• Because every site's different, the goal is to give you at least
most of the data you need to make an informed decision,
without making you pry it out of the cloud provider yourself.
• Ideally, the data should even be publicly available so you
don't even need to screw around requesting it, you should
just be able to click on the data you need in a public
repository. (If a provider's reluctant to publicly share their
CSA CCM results, that might be something worth exploring,
• If something doesn't look right to you, you can follow up with
the cloud provider directly, digging in on the issue of concern
to you. Maybe the issue is just a matter of a
misunderstanding, and something that can be easily
CSA CCM and "Recursive Cloud Providers"
• We also quickly came to realize as we worked with the CSA
CCM that some parts of it are not applicable to (or even
easily answered by!) a cloud application vendor that is
hosting their cloud app on cloud infrastructure.
• For example, when it comes to the "Data Center Security"
section of the CSA CCM, a typical cloud application vendor
may have no idea how to respond to those items, because
they don't run the data center they're using, some other
cloud provider does.
• They may still be RESPONSIBLE for how that data center
works, but they may need to rely on what they're told by
their cloud infrastructure provider, but now we're getting
recursive, and infrastructure providers may not be willing to
"open the kimono" for non-customer review.
Giant Clouds and Teeny-Tiny Clouds
• Another rapid discovery: some cloud providers are giants,
with huge staffs (including entire (LARGE!) teams focused
on security and compliance and privacy).
• Other cloud providers, particularly entrepreneurial cloud app
vendors, might be tiny. If their total staff amounted to half a
dozen people, it was unlikely that one of them would be
devoted entirely to security/compliance/privacy.
• This difference in security "maturity" impacts the security
processes the vendor may have, and the amount of help
they may need when it comes to completing a framework
like the CSA CCM.
• It also shows up in things like "division of responsibility"
requirements: tiny entrepreneurial cloud providers may not
have enough staff to divide up roles and responsibilities the
way large firms do.
Note: You May Have Limited Luck Seeking
Major Changes From a Huge Cloud Provider
• Cloud providers are all about offering standardized services
at scale.
• As such, they may not be willing (or even able) to consider
modifying their service (or their practices/procedures) to
meet your preferences/needs.
• If they did make changes to meet your needs, they might
find those changes aren't welcomed by an equal number (or
more!) existing customers, customers who liked how the
provider traditionally did things. Therefore, you may need to
live with "off the rack" rather than custom tailored outfits.
• Small entrepreneurial cloud providers, on the other hand
may be much more potentially flexible.
Couldn't a Provider Just Lie
When Doing Their CSA CCM Writeup?
• That's always a possibility, but if they've provider a written
statement describing what they're doing, and that statement
subsequently proves to be factually inaccurate or
intentionally misleading, you likely have a good basis for
talking with legal counsel if things go awry.
• I discuss this and more in a draft two page document "Using
the CSA CCM with Net+" document you can retrieve from:
• If you're really worried, you can always ask for audits (but if
you really don't trust them, well...)
X. Wrap Up
Thanks For the Chance to Talk Today
Are there any questions?
If you'd like a copy of these slides, they're
available online at

similar documents