Runtime Governance for SOA and Cloud Computing

XML Gateway

Subscribe to XML Gateway: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get XML Gateway: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


XML Gateway Authors: Mamoon Yunus, Dirk Zwart, Rizwan Mallal, Mark O'Neill, Ron Schmelzer

Related Topics: XML Magazine, SOA Best Practices Digest, Cloud Security Journal , Microservices Journal, SOA Testing, XML Gateway

Cloud Security: Article

Strategies for Securing Enterprise-to-Cloud Communication

IaaS vendors and Enterprise consumers share responsibilities for enabling Cloud Security

The Cloud Security Alliance (CSA) published Version 2.1 of its Guidance for Critical Areas of Focus in Cloud Computing with a significant and comprehensive set of recommendations that enterprises should incorporate within their security best practices if they are to use cloud computing in a meaningful way.

The Guidance provides broad recommendations for operational security concerns including application security, encryption & key management, and identity & access management. In this article, we will consider security implications of REST- and SOAP-based communication between consumers and specifically, Infrastructure as a Service (IaaS) providers.

Cloud Application Security
Cloud application security requires looking at classic application security models and extending these models out to dynamic and multi-tenant architectures. While planning for cloud-based application security, DMZ-resident application security should be used as the starting point. DMZ-based security enforcement models should be extended to incorporate secure enterprise-to-cloud traffic management and operational control.  IaaS cloud providers design their management APIs to accommodate consumers with varying skill sets. Popular IaaS providers (Amazon EC2, Rackspace, Opsource, GoGrid) publish RESTful APIs for keeping a low threshold-of-difficulty to accommodate a broad set of consumers that lack sophisticated SOAP-based communication stacks but can easily consume XML/JSON using RESTful interaction. Amazon EC2, however, also provides a sophisticated WDSL for SOAP-based interaction. Although cloud providers have a greater responsibility of implementing extensive application security provisions while accommodating consumers of varying technical skills, cloud consumers also have to share the burden of risk mitigation by ensuring that their API calls into the cloud providers are secure and clean. The potential for a cascading effect in a shared, multi-tenant environment is high: a single poorly formed SOAP- or REST-based API request can cause a Denial of Service (DoS) attack potentially shutting down access to the cloud management APIs for many.

Implications for Cloud Consumers
Cloud consumers, for example enterprises, usually make outbound calls into an IaaS provider using a REST-based or a SOAP-based API for provisioning and managing server instances. Such standards-based API calls provide significant flexibility and ease for automating cloud resource management. However, this flexibility also opens the door to security risks that should be addressed. Here are a few operational recommendations, expanding on the CSA Guidance for Application Security, that cloud consumers should consider for lowering their risk profile while interacting with an IaaS:

  1. Enable Encryption: Cloud consumer should use SSL (HTTPS) for encrypting data-in-motion. When available, data-at-rest encryption (WS-Security) should also be used for invoking IaaS management services. Enabling content-level encryption for SOAP and REST responses ensures that only authorized consumer can decrypt responses with their private keys and use the API for managing their cloud images.
  2. Check Requests & Responses: Before invoking a REST- or SOAP-based call to an IaaS, consumers should determine whether the invocation is in the correct format and does not contain malware and that the request message integrity has not been compromised. The response from SOAP and REST-XML/JSON calls should also be scanned for malware and possible corruption before consumption by enterprise cloud management applications. Fortunately, structured data such as XML and SOAP provide the ability to check for message hygiene through a variety of ways starting with the simplest check: XSD Schema Validation. A schema, embedded in a WSDL file, provides constraints for message data types, structure, and content (through facets). Enforcing schema validation or simple deep-content validation through regular expression for REST calls ensures that the messages adhere to their required structure. Additional checks must be performed for malware that may be transmitted in a request or response to identify and quarantine infected messages. Such protective actions can prevent malware cascading through an enterprise or its IaaS provider.
  3. Enable Web services: For building a robust and secure framework for interacting with IaaS providers, SOAP-based interaction provides richness over RESTful XML/JSON. With SOAP use, enterprises can leverage their Public Key Infrastructure (PKI) and have full key life-cycle management including the ability to issue, sign, revoke and validate X.509 certificates being used in SOAP calls. By using key-pairs, enterprises have extensive control over authentication, message integrity and privacy while interacting with an IaaS. Using X.509 with GETs in a RESTful interaction is difficult and non-standard (other than for SSL mutual authentication that most IaaS providers do not support).

Implications for Cloud Providers
IaaS vendors usually provide a simple-to-use, web-based UI that enables user to manage cloud-based server images. This web-based interface is great to get up and running quickly, however, for enterprises that deploy numerous images, automated scripting for image management is essential. Most IaaS vendors provide REST, SOAP or Command Line scripting APIs for automating image management functions. Here are a few operational recommendations, expanding on the CSA Guidance for Application Security, that cloud providers should consider for lowering their risk profile:

  1. Provide standards-based flexibility: From the simplest of RESTful XML/JSON GETs to sophisticated signed SOAP requests with embedded X.509, IaaS providers have to address requirements from users with highly-varied technical skills. For large enterprise customers, IaaS vendors must provide strong authentication capabilities and rich SOAP-based interaction, whereas for smaller companies that may not have technical skill for handling a SOAP stack, simple RESTful interaction is usually preferred. Within simple, RESTful type interaction, there is a glaring lack of standardization on identity token use. Enterprises serious about using IaaS have to consider multi-cloud deployments for higher reliability. Standards-based identity tokens - perhaps OAuth for RESTful APIs and WS-X.509 for SOAP APIs - will provide a common management framework for enterprises to build redundancy through multi-cloud deployments.
  2. Enable comprehensive encryption: IaaS vendors must provide both data-in-motion security via protocols such as SSL and data-at-rest security through standards such as WS-Security for satisfying corporate security requirements. All IaaS vendors provide SSL-based encryption for invoking management APIs, however, content-level encryption for data-at-rest is not implement. IaaS providers such as Amazon EC2 support X.509 certificates for authentication and also provides WS-Signature capabilities for their SOAP-based API. Other IaaS vendors should provide such SOAP-based APIs along with more granular security controls. IaaS vendors should support SOAP APIs and provide granular encryption for XML/SOAP responses as an additional level of encryption control so that only enterprises with strict ownership and control of their private keys can view encrypted information within a XML/SOAP response.
  3. Perform comprehensive API testing: Before releasing a set cloud management calls to consumers, the APIs should be thoroughly tested across all exposed interaction formats, e.g., JSON/XML-REST and SOAP over HTTP(S).  The testing should be comprehensive and should cover four aspects of testing:  functional, performance, interoperability, and security.  Functional testing ensures that the cloud provisioning and management calls behave as expected and that no regression errors have been introduced.  Such functional testing has to cover all message types, identity tokens and security artifacts.  Performance testing can establish concurrency and throughput profiles for the APIs.  Interoperability testing ensures the APIs are consumable by the widest array of application platforms.  Adhering to WS-I Basic Profiles, for example, ensures that service description (WSDL) for the cloud management API can be used by .NET, Java, and LAMP environments with relative ease.  Finally, and perhaps, the most overlooked aspect of testing is a full penetration and security test for the IaaS management API that identifies REST, XML and SOAP-based vulnerabilities before the IaaS is exposed for public consumption. The multiplicative effect of a multi-tenant setting and multiple configuration APIs results is a dramatic expansion of the attack surface area. Identifying and remediating such risks through exhaustive penetration testing should be an essential component of IaaS providers Application Security operational plan.

Conclusions
Cloud application security requires extending risk planning and analysis beyond corporate boundaries. Enterprises that are already comfortable with deploying applications in the DMZ for deep integration with external trading partner have already laid the fo undations for interacting securely with IaaS cloud providers. Such mature enterprises have already figured out how to invoke external APIs via XML/SOAP, manage their identity tokens, encrypt communication and monitor traffic. Utilizing IaaS provider APIs and building a reliable multi-cloud application strategy requires extending their existing application infrastructure for centralized cloud management and control. Cloud providers, public and private, on-premise and off-premise have a higher burden of managing cloud application security than cloud service consumers. Cloud providers are required to balance security with flexibility. Greater security may discourage users with lower technical skills whereas enterprise customers may expect only the highest level of security. Cloud vendors should continue to focus on providing flexibility while extending security options available to users. They should also consider using standards-based identity tokens and work towards a standard management API that enables enterprises to build secure and reliable multi-cloud deployments.

References

  1. Guidance for Critical Areas of Focus in Cloud Computing
  2. Beginner's Guide to OAUTH
  3. Understanding WS-Security
  4. Pillars of SOA Testing

More Stories By Mamoon Yunus

Mamoon Yunus is an industry-honored CEO and visionary in Web Services-based technologies. As the founder of Forum Systems, he pioneered XML Security Gateways & Firewalls and was granted a patent for XML Gateway Appliances. He has spearheaded Forum's direction and strategy for eight generations of award-winning XML Security products. Prior to Forum Systems, Yunus was a Global Systems Engineer for webMethods (NASD: WEBM) where he developed XML-based business integration and architecture plans for Global 2000 companies such as GE, Pepsi, Siemens, and Mass Mutual. He has held various high-level executive positions at Informix (acquired by IBM) and Cambridge Technology Group.

He holds two Graduate Degrees in Engineering from MIT and a BSME from Georgia Institute of Technology. InfoWorld recognized Yunus as one of four "Up and coming CTOs to watch in 2004." He is a sought-after speaker at industry conferences such as RSA, Gartner, Web Services Edge, CSI, Network Interop, and Microsoft TechEd. Yunus has the distinction of showcasing Forum Systems' entrepreneurial leadership as a case study at the MIT Sloan School of Management. He has also been featured on CNBC as Terry Bradshaw's "Pick of the Week."