In the most recent iteration of the Cloud Security Alliance's (CSA) Top Threats to Cloud Computing report, a number of new risks were presented, while older
As one of the three co-chairs of the working group responsible for the report, I've fielded many questions lately about the No. 4 threat on the list, "insecure interfaces and APIs." What exactly does this represent? What are some of the risks involved? And, how can organizations endeavor to assess and secure these cloud APIs? In this tip, we'll explore cloud API security and answer these pressing questions.
Defining the risk posed by insecure APIs
From the editors: More on CSP evaluations
What considerations should be made when adopting a cloud-based disaster recovery service?
Struggling with rogue cloud usage? Learn why a cloud service provider inventory can help manage multiple cloud service providers.
First, for those who aren't familiar with what cloud APIs are and how they are used, they are essentially software interfaces, typically standards-based, that cloud providers make available to customers for the purpose of managing their cloud services. APIs serve to ease many common cloud computing processes and enable automation of more complex business needs, such as configuring a variety of cloud instances among multiple providers and using a third-party management platform for both cloud and on-premises systems.
However, cloud APIs require careful attention on the part of cloud providers and cloud customers alike. As stated in the Notorious Nine report, insecure cloud APIs can pose a variety of risks related to confidentiality, integrity, availability and accountability. While all cloud service providers should be paying careful attention to the security of their APIs, your mileage may vary. That's why it's important to know how to analyze the security of cloud APIs for yourself.
A good starting point for analyzing cloud provider APIs is Gunnar Peterson's Web Services Security Checklist (PDF), which presents many of the same general categories of issues as the CSA report. The following include some of the major areas customers should be focused on:
- Transport security. Most APIs are intended to be offered via a variety of channels, but
any APIs that will interact with or carry sensitive data should be protected within a secure
channel, such as SSL/TLS
or IPSec. Creating IPSec tunnels between a cloud service provider (CSP) and a customer may prove
challenging or impossible, so most tend to settle on SSL/TLS. This brings a whole slew of potential
problems, though, including the generation and management of valid certificates from an internal or
(more commonly) external certificate authority, configuration issues with platform services, and
software integration and issues with end-to-end protection, if any proxying platforms are required
- Authentication and authorization. Many cloud APIs are focused on authentication and
authorization, so these will be key areas of focus for many customers. Questions to ask CSPs
include: Can APIs manage the encryption of usernames and passwords? Is it possible to manage
two-factor authentication attributes? Can fine-grained authorization policies be created and
maintained, and is there continuity between internal identity management systems and attributes,
and those extended by APIs from cloud providers?
- Code and development practices. Any APIs that pass JSON and XML messages or accept input
from users and applications must be adequately tested for standard injection flaws and cross-site
request forgery (CSRF) attacks, schema validation, encoding for both input and output, and so
- Message protection. Beyond ensuring that general coding best practices are followed, other key considerations for APIs include message structure, integrity validation, and encryption or encoding.
How to secure cloud APIs
Once an organization has a good grasp on the issues that can be caused by insecure APIs, it can move on to implementing some best practices for securing them. First, determine the API security of cloud providers by asking for documentation on their APIs, including any existing application assessment results and reports that demonstrate security best practices and audit results in the form of the Statement on Standards for Attestation Engagements No. 16 or other reports. The Dasein Cloud API provides a good example of cloud APIs with open and extensive documentation.
In addition to documentation, customers should ask cloud providers to allow penetration tests and vulnerability assessments to be performed against APIs, or the cloud providers can perform these tests themselves or via a third-party provider, with the results provided to customers and prospects under a nondisclosure agreement so the customer can evaluate the security practices in place. Web-services APIs should be protected against the Open Web Application Security Project top 10 list of common application security flaws using a combination of network and application controls, as well as sound development practices and QA testing.
Additionally, many CSPs offer encryption keys as an access and authentication mechanism for customers to leverage APIs. Protecting these keys is vital, both on the customer side and within the CSP environments. Security policies governing the creation, dissemination, storage and disposal of keys should be in place, and keys should be stored securely in a hardware security module or other encrypted and protected file store. Avoid embedding keys in configuration files or other scripts, as well as directly embedding keys into code, which can make key updates a nightmare for developers and others. Look explicitly for CSPs such as Amazon and Microsoft Azure that include hash-based message authentication codes with symmetric keys to both maintain integrity and avoid passing shared secrets across untrusted networks. Any third parties that build on a CSP's APIs should also strive to follow this advice, treating keys (and API security in general) as seriously as the CSP does.
With the proliferation of application development and integration in the cloud, it's no surprise that cloud consumers are taking the threat of insecure APIs seriously. Hopefully, providers will do the same, and this will be an issue that doesn't appear on the next CSA Top Threats listing.
About the author
Dave Shackleford is senior vice president of research and chief technology officer (CTO) at IANS, and a SANS analyst, instructor and course author. He has consulted with hundreds of organizations in the areas of security, regulatory compliance and network architecture and engineering. He is a VMware vExpert and has extensive experience designing and configuring secure virtualized infrastructures. He has previously worked as chief security officer for Configuresoft; CTO for the Center for Internet Security; and as a security architect, analyst and manager for several Fortune 500 companies. Dave is the author of the Sybex book Virtualization Security: Protecting Virtualized Environments, and he recently co-authored the first published course on virtualization security for the SANS Institute. He currently serves on the board of directors at the SANS Technology Institute and helps lead the Atlanta chapter of the Cloud Security Alliance.
This was first published in May 2013