The document outlines necessary cloud security controls and the steps for successful cloud adoption, emphasizing the importance of risk assessments and defining specific controls for data handling, procurement, and perimeter management. It suggests implementing both active and passive controls to prevent data leakage and unauthorized use of cloud services, as well as ensuring compliance with legal standards. The author also discusses the need for continuous auditing and adapting controls to manage externalities like 'noisy neighbors' in a multitenant environment.

1. Cloud security controls
What controls would you need?
Petteri Heino, petteri.heino@hp.com
HP Enterprise Security Services
14.11.2013
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.

2. Contents
Cloud Security controls
„ What cloud security controls are needed?
„ What are the characteristics of the controls?
Young people - their expectations of daily tools are different, much more smartphone,
tablets and collaboration. It is us the people in 40ies and 50ies who need to build the next
generation IT systems for these youngsters who come after us. I vote that most of these
new applications should be cloud-based.
2

3. How your cloud adoption process should go?
Push through the noise ‟ it’s quite simple ‟ start with a risk assessment
Step 1: Carry out a risk assessment (RA)
• Assess the cloud that way how it would affect the business on a bad day, uphill and the wind blowing against its face
• Many cloud discussions start and end with a legal discussion ‟ legal is one of your topics, not the only topic
• Apart from legal also think about provider longevity, reliance on network, design of your applications and how they would work in
cloud, the technical compatibility, how to transition
• It would help you if how much the cloud opportunity (or saving) would be in USD or EUR, and how the figures were reached
• Knowing the opportunity’s worth and its breakdown would make your work easier, and you could focus on the right things
• Try to convince the organization to accept it does need to release funds for cloud controls ‟ this way cloud adoption is treated like any
other substantial investment ‟ and not like someone just grabs something from the web
• Finally, look at the scenario without cloud services ‟ are you facing refresh investments to on-premise equipment, do you have access
to funds for them, what’s your risk if you don’t get the funds, and is it better to go for cloud because of that
• It is probably best to itemize the risks, value each identified risk in terms of impact to the business, and probability of each risk
• Recommendation Your RA outcome is a relatively simple spreadsheet document where you list and value each identified risk
3

4. How your cloud adoption process should go?
Push through the noise ‟ it’s quite simple ‟ then put in place the controls
Step 2: Put in place the controls
• Generally you need to focus on 4 x things
1.
How do you handle business data
2.
How do you handle PII personally identifiable information
3.
How do you actively prohibit certain usage or behavior
4.
How do you passively (afterwards) audit the usage or behavior
• You would have to prohibit certain behaviour (like uploading content with social security numbers or evident trade secrets to cloud)
• On many use cases and types of data you can rely on an audit or investigation afterwards , no active measures are required
• Admit that you would need some new technology/equipment to facilitate the controls
• I have drawn a flow chart how the decisions on cloud controls could be made (following slide)
• Recommendation Your document should include a topology drawing of the endstate of your environment (first make it work in
PowerPoint)
4

5. Cloud Security controls
4 x angles on it
RA
Policies
Regulation
Deployment of controls
2
1
Controls of content
Legal
4
3
Control of procurement
Control of ”cloud perimeter”
Control of externalities
Data classification
Active / Access
Passive / Audit
Data Loss Prevention, Log mgmt and SIEM
systems
encryption
Control of
automata in
the cloud
Control of
user-initiated
procurement
Active / Access
Testing tools
Change Mgmt
practises, helpdesk tools
IPS, Session Control,
Virtual environment
specific controls, 2FA
Forensics / Incident Response
5
May need additional tools or capabilities after cloud
Passive / Audit
Log mgmt and
SIEM systems
Reactive
2 x cloud providers,
reserve capacity on
premises
Proactive
Maybe some
financial info
service feed?

6. Controls of content
In another words, controls on which data can be sent / copied from cloud
The sub-area in practise
• Prevent business data and PII information from leaking into cloud or from the cloud (if it is not allowed by policy)
Control tools
• You need Classification document, schema or equivalent definition what is allowed on cloud (may not be trivial)
• Prepare that you do need the ”Active” control ‟ if you leak company information to cloud and it’s exploited, an audit function after 6
months would not help you, mistake already happened
• In absense of classification, then split data into very small number of categories (< 5)
−
If you split your company’s data into two categories, it would be: Category A: data with social security number Category B: data without it
−
Substitute your category item with ”credit card number”, ”street address”, ”phone number”, but plan for something simple which you know would work in a
control tool like DLP Data Loss Prevention
−
Some content can be classified while it’s created, a DLP system would put a marker onto the file, allowing / prohibiting upload to cloud, this might apply to
i.e. CAD drawings
Goal for the control
• If a user or a system tried to upload content onto cloud, the system would verify if it’s allowed, and provide a response, to some extent
the control should work on download as well (meaning cloud-based content download)
• If the control is prohibitive, then you should be able to provide the alternative or allowed solution, that might be an on-premise
6
arrangement or encryption before upload

7. Controls on content - encryption is key
Securing “data-in-process,” in addition to “at rest” and “in motion”
Advances
Alternatives
• Broadcast encryption: encryption for
• Tokenization. Data sent to the public cloud is
groups and memberships
• Searchable symmetric encryption:
securely search encrypted data
• Identity-based encryption: ad-hoc PKI,
user chooses his own public key
• Predicate encryption: fine-grained PKI
• Homomorphic encryption: emerging
techniques to compute on ciphertext
7
altered (tokenized) and contains a reference
to the data residing in the private cloud.
• Data anonymization. Personally identifiable
information (PII) is stripped before
processing. (Watch assumptions!)
• Utilizing cloud database controls. Using
(fine-grained) access controls at database
layer to provide segregation.

8. Controls on procurement
In another words, controls over non-excessive use of cloud services
The sub-area in practise
• Prevent a user or a system from signing on and using payable services beyond budget or other commercially reasonable limitation
• In an on-premise world, the server is bought, deployed and enjoyed, no additional expense after it’s installed
• In a cloud you pay more if you use more, that can result in budget overdrafts and additional expenses if not controlled
Control tools
• You need A cloud service with functionality to limit invoicing
−
If not possible, there might be possibilities to alert by SIEM or by IPS if certain traffic / addresses are in use ”longer than x period”
−
Tools like the HP ArcSight CloudConnector (a combination of technology and partnerships) possible, but are limited in coverage of supported cloud services
• Cloud services might be used for systems which require / provide scaling, for those you need
−
Need to limit reactive scaling to only be commercially reasonable, not what is technically available
−
Need to test any automata created with cloud scaler abilities  may require additional testing tools or effort
−
May need to limit user / department from vertical / horizontal scaling if they are a function of the cloud service
Goal for the control
• Need to limit to what’s commercially reasonable or limit to certain budget
8

9. Control of the perimeter
In another words, prohibit attacking from the cloud and to the cloud
The sub-area in practise
• Technology and/or services to withstand possible attacks over the ”cloud perimeter border”
Control tools
• Different approaches exist for active (access) control
−
Network based protection, either in firewall or in an IPS device, may also be specific to advanced targeted malware
−
Tokenization, has been primarily used in securing the PCI DSS environments but technologies exist to control access to cloud in transparent fashion, useful
in hybrid arrangements
−
Session based methods, for controlling access to cloud services
−
2FA is recommended to be more immune to service hijacking
• The passive control is needed for audits, but also for possible forensics
−
Think about how you make ongoing audits on cloud usage, cloud is way too dynamic for annual or bi-annnual controls
−
Some services allow RESTful download of logs, use that where possible
−
It is likely log cannot be gathered from the cloud service per se, instead the evidence needs to be created as evidence from a number of devices’ logs
−
Deploy DVR (meaning the user’s screen is recorded) where logging is not feasible / possible
Goal for the control
• Prevent adversaries to attack you from the cloud, and prevent your network to be utilized in attacks to the cloud
9

10. Control of the externalities
In another words, manage the circumstances of noisy neighbours in the cloud
The sub-area in practise
• This is to manage the circumstances when customer procures from a multitenant infrastructure, and that provider then has other
customers who use the capacity so excessily that your services are affected (”noisy neighbour”)
Control tools
• Obvious control would be not allow procurement of multitenant services, but that would raise cost, and the cloud phenomen is driven
by efficiency of multitenant model
−
Watch your trust chain: externality event risk might be inside SaaS services if the ISV itself utilizes public cloud services
• Should an externality event occur, the action would be to move the services back to on-premise or to another cloud service provider
• You need
−
Define minimum cloud services in quantity‟ it might be practical to have two public cloud providers, and ensure transportability between them
−
Define decision criteria - under which cicrcumstances are the services transferred to another provider? Performance degradation? Something else?
−
Define migration priority - how is the actual fallback / migration carried out? By whom? Prioritized by what? Or laissez-faire?
−
Define reserve capacity if you want to keep something on-premises How much excess capacity is reserved for possible ”fallback from the clouds”
Goal for the control
• Users are provided with commercially reasonable service
10

11. Final comments
Have fun with your cloud controls 
Yes – all this is absolutely doable
• The above describe your controls when you aim for public Amazon-like clouds
• If you have in your crosshairs more like a private cloud or a system where someone manages the cloud for you, you can axe most of
what was mentioned
Some say there should be additional legal control
• A customer pointed that they started with an outsourcing provider, and then gradually moved to cloud-like services, and then again
gradually moved to services delivered from outside of EU, and that the legal issues in terms of geopgraphy would need a separate
cloud control
• While sympathetic to the worry, it is likely there already was a control insisted by the customer in the outsourcing contract to prohibit
this behavior
• If not, and if according to the customer’s RA cloud services from outside of EU are not tolerated, a contract change would have to be
requested by the customer to facilitate this additional control
• In the end of the day, you might have requirements which are incompatible with some cloud providers or with some cloud use cases
11

12. Petteri Heino
Sales Specialist for ESS Enterprise Security Services Finland & Baltics
18 years in various sales jobs, last 6,5 years at HP , previously i.e. at Digital, Cisco Systems and Computer Associates
Author of 4 IT books
Email petteri.heino@hp.com
My fourth book:
Pilvipalvelut – cloud computing
While the phenomen was in 2010 still
in its infancy I wrote for publisher
Talentum a book on it. I have also been
a presenter in their seminars on ”cloud
for lawyers”. The book is widely
available in Finnish public libraries.
Everybody knows much more about
cloud nowadays, but I am still not
overly embarrased of the content.
Maybe some more punch into the
security and privacy chapters...
I am silently working with baby steps
on my next book, codename ”9X”.
12