Security Considerations for Infrastructure as a Service (IaaS)

Introduction

Laymen introduction

When we trust to keep our valuables in bank locker, we trust on bank protecting it. This protection includes

Are safe against theft
Are safe against damage
No one can access this valuable even for viewing
We can access it as per our need without hassle
Cost of keeping valuable should be affordable

Same consideration applies when we think to move valuable data to cloud.

Technical explanation

To achieve above requirement, public IaaS security research examines the following features:

Shared Cloud Network: public IaaS environment where different cloud customers share the same cloud service subnet. In this model, each cloud server (VM) usually has a public IP address (permanent or temporary) as well as service IP address for the internal cloud service network
Virtual Private Cloud (VPC) Network: the IaaS provider supports an isolation of customers’ cloud deployments, such that a customer can have a private subnet that is not reachable from other customers’ cloud servers or from the public Internet
Firewall: Collection of policies and rules to control the traffic allowed to and from a group of cloud servers or static IP Addresses
Identity-based access management: these are firewall rules based on user identity, allowing access of specific users to specific set of compute resources
Secure extension: ability to securely connect enterprise sites to the cloud deployment (usually a virtual private network) via static IPSec connections
Secure remote access to individual server: the ability to access an individual machine (VM) using a secure protocol (like SSH or RDP); this type of remote access is usually based on credentials that are specific to a single user and a single server
Remote VPN access: the ability of the organization’s employees to securely connect on demand to the cloud deployment remotely using VPN clients; this includes central authentication of the employees’ identity prior to gaining access to the cloud deployment (part or all of cloud servers)

Vulnerable practices

In an investigation exercise, Symantec found that incorrectly configured access permissions allowed open access to a treasure trove of sensitive information stored in the cloud. According to Symantec, researchers were able to identify more than 16,000 cloud domains by enumerating domain prefixes with words from a dictionary. Of the domains they discovered, 0.3 percent had guessable folder structures that could be read by anyone and that led to more than 11,000 publicly accessible files containing everything from user names to credit card transaction logs.

They observed that the majority of vulnerabilities in the cloud today occur because of misconfigurations made by the customer, he added. Another common mistake is the accidental publishing of access tokens that can be used by attackers, he noted. To deal with these issues, organizations should consider two-factor authentication, encryption key management, logging and governance to secure cloud resources, he said.

Safe practice

There are good questions to ask when developing a cloud security policy.

What do we want to put in the cloud – data, applications or both? Based on this, you will be able to identify criteria to determine the best cloud provider and service required such as IaaS, PaaS or SaaS.
Do we have a good data classification policy and procedure and what type of data will we allow in the cloud – sensitive corporate data, protected data such as PII, SSNs or HIPAA related, day-to-day operational data? If you don’t have a good data classification policy, create that too so you aren’t inadvertently transmitting and storing data in a cloud that you don’t want there.
What existing policy does our company have that also applies to what we want to do in the cloud?
What have others in our industry done and what can we borrow? Calling up a peer who’s already ventured into the cloud and has experience with the good, the bad and the unexpected can really help you craft your policy. Checking out what a standards body, like ISO, NIST or the CSA, has created is also a great idea for discovering policy areas you may not have considered.
Who within our organization is allowed to enter into agreements with cloud providers? Who has authority to negotiate SLA’s? Who can set up an application in or move data to the cloud and with whom should it be approved beforehand?
Where can my data or application be physically located? Where your data lives and where it could be moved to have legal and privacy implications.
What is our exit strategy and policy for removing data or application from this cloud provider? Having a clear exit strategy before you start prevents you from potentially large operational costs or downtime later.
If we choose to put sensitive or protected data in the cloud, how well does the cloud provider’s security policies and procedures align with our organizations? Ensuring your cloud provider’s security program maturity is as advanced or more advanced than yours is a good sign.
For applications in the cloud, who within our organization is allowed to modify settings on the cloud that affect performance? Define who, when and under what circumstances changes can be made.
How should we manage administrative privileges to the cloud provider? For example, do you allow application developers to make changes to security settings in the cloud to improve performance?

Reference

http://fortycloud.com/iaas-security-state-of-the-industry/

http://www.securityweek.com/inside-iaas-security-challenges-enterprises

http://www.securityweek.com/ten-questions-every-business-should-ask-developing-cloud-security-policy

http://social.technet.microsoft.com/wiki/contents/articles/3808.security-considerations-for-infrastructure-as-a-service-iaas.aspx