Top Threats to Cloud Computing

The CSA has recently issued a report called Top Threats to Cloud Computing in which they identify and discuss seven general threat areas:

• Abuse and Nefarious Use of Cloud Computing
• Insecure Application Programming Interfaces
• Malicious Insiders
• Shared Technology Vulnerabilities
• Data Loss/Leakage
• Account, Service and Traffic Hijacking
• Unknown Risk Profile

No priority is implied in the ordering of the top threats; the advisory committee felt that further research and greater industry participation would be required to rank the threats. My view is that ranking is less important than applying a risk management discipline to the specific requirements of an organization considering cloud services.


As we consider the seven threats individually, we should keep in mind that the CSA considers this document as a first deliverable that will be updated regularly to reflect expert consensus on probable threats to cloud services:


Abuse and Nefarious Use of Cloud Computing
Because the Cloud Service Providers (CSPs) business model is based on rapid scalability, they have emphasized ease of adoption. Therefore, in most cases anyone with a valid credit card can register for and begin using cloud services in a matter of minutes. In other words, an attacker can materialize inside your CSP's infrastructure at any time, including on the same physical hardware your cloud-based application is running on, and you need to be prepared. The best policy is one of calculated paranoia: Assume your virtual environment includes all of your competitors as well as hackers, botnets, malicious users, clueless resource hogs, and other "nefarious users." Although as a user of cloud services you need to employ a layered defense strategy to protect critical resources, you also need to rely on your CSP's onboarding and technical surveillance processes: How effective is your CSP's registration and validation process for screening new users, and how well does your CSP's monitoring of internal traffic work? 

Insecure Application Programming Interfaces
The same investor and market pressures that motivate CSPs to streamline the onboarding process also apply to how they support the configuration and use of their services by large numbers of users. The more these services can be enabled in a frictionless manner, the more profitable the CSP will be. Therefore, it's worth focusing on the APIs provided by CSPs for manging, deploying and maintaining cloud services. As the report points out, the "security and availability of general cloud services is dependent on the security of these basic APIs." Furthermore,

"From authentication and access control to encryption and activity monitoring, these interfaces must be designed to protect against both accidental and malicious attempts to circumvent policy."

One key question to ask: Does the CSP require use of X.509 certificates to access APIs? Besides being used to support the TLS protocol and WS-Security extensions to SOAP, X.509 certificates are used for code signing -- critical for secure use of APIs.


It's essential that users understand the security model of the CSP's APIs, especially to ensure that strong authentication and access controls are implemented.

Malicious Insiders
The threat from malicious CSP insiders is a threat that organizations have always had, except the threat was (and still is!) from someone they know rather than someone they don't know. An organization should compare its own policy with regard to insiders with that of the CSP, ensuring that controls such as the following exist:

• State of the art intrusion detection systems
• Background check on new hires (where permitted by law)
• Authorized staff must pass two-factor authentication 
• Immediate deprovisioning of admin when no longer has business need
• Extensive background check of staff with potential access to customer data
• All admin access logged and audited, with suspicious actions raising a real-time alarm

Organizations should require transparency of CSP security and HR practices as well as all compliance reporting, and should refer to controls such as listed above as part of any legal agreement with the CSP.

Shared Technology Vulnerabilities
The foundation of the cloud service provider's business model is sharing of computing resources: CPU; memory; persistent storage; caches; and so forth. This sharing results in a multi-tenant environment, where great trust is placed in all virtualization technologies -- especially hypervisors that enable sharing of server hardware. Hypervisors must effectively isolate multiple guest operating systems while ensuring security and fairness. The CSA paper lists five remediation tactics for shared technology vulnerabilities, but the fact they they're generic recommendations (implement security best practices..., etc) serves to reinforce the point that at the end of the day, we need to be able to rely on the assumption that the CSP employs a secure hypervisor.


One potentially useful resource is a recently-released vSphere Security Hardening Guide from VMware. Overall, the guide contains more than 100 guidelines in a standardized format, with formally defined sections, templates, and reference codes that are in alignment with formats used by NIST, CIS, and others. The guide itself is split into the following major sections:

• Introduction
• Virtual Machines
• Host
• vNetwork
• vCenter
• Console OS (for ESX)

While the document is mostly applicable to CSPs using VMWare, many of the guidelines are generic and might apply to other hypervisors. In evaluating CSPs and shared technology vulnerabilities, it would be worthwhile having the CSP respond with how they've incorporated applicable recommendations from the hardening guide into their environment.

Data Loss/Leakage
The concept of defense in depth, or a layered security strategy, comes into play when we consider the threat of data loss or leakage. All of the above threat vectors can result in data loss or leakage. Data encryption, then, becomes the last line of defense against the data loss threat.


While encryption is easy enough conceptually, in practice it's a challenge -- especially in a multi-tenant environment. The authors of Cloud Security and Privacy dedicated an entire chapter to Data Security and Storage (as I previously discussed here). In particular, the authors warn of CSPs that use a single key to encrypt all customer data, rather than a separate key for each account (see pg. 69). Best practices for key management are provided in NIST's 800-57 "Recommendation for Key Management"; your CSP should comply or have an equivalent guideline that they use.


Of course you should know whether your CSP uses standard encryption algorithms, what they key length is, and whether the protocols employed ensure data integrity as well as data confidentiality. And since encrypted data at rest can't be operated on without being unencrypted you'll want to know whether memory, caches and temporary storage that have held unencrypted data are wiped afterward. The same set of questions (and answers) apply to the issue of data migration and to processes by which failed or obsolete storage devices are decommissioned. 


Many regulatory frameworks focus on protecting against data loss and leakage. If you need to comply with PCI DSS or any other set of financial controls you will need to ensure adequate threat protection that includes encryption of data at rest.

Account, Service and Traffic Hijacking
In the online payment space there's a segment called "card not present" (CNP). That's analogous to cloud computing, where service is provided to a "user not present". All of the threats in an enterprise environment -- including phishing, fraud, shared or stolen credentials and weak authentication methods -- become magnified in the cloud. Remediation suggestions are fairly obvious: prohibit sharing of credentials; leverage strong two-factor authorization where possible; employ proactive monitoring to detect unauthorized activity; and understand CSP security policies and SLAs. I would add to CSA's recommendations that organizations should  routinely check for excessive access rights to ensure there are no unused (and unmonitored) accounts that would be vulnerable to highjacking.

Unknown Risk Profile
CSPs, hypervisor vendors, other cloud technology providers, application developers, security experts, and customers are all pushing the envelope when it comes to cloud services. The compelling economics of cloud services are driving adoption rates higher than is typical for new technologies. All together, this adds an element of technical uncertainty to the question of what are the top threats to cloud computing. 


In general, a strategy of pragmatic paranoia is recommended. Be on the alert for the unexpected. Review logs, set up monitoring and alerting systems where practical, and re-evaluate the security implications of your cloud service periodically. Most importantly, select a CSP you can trust and back it up with a strong agreement specifying all areas of concern and including SLAs -- with penalties for non-compliance.