Microservices Expo Authors: Liz McMillan, Flint Brenton, Jason Bloomberg, Elizabeth White, Yeshim Deniz

Related Topics: Microservices Expo

Microservices Expo: Article

Securing Your Enterprise Web Services in a Suspicious World

Out of many pieces, a harmonious whole

Deploying XML Web services in the enterprise has many compelling advantages. Web services provide a powerful foundation for building loosely coupled distributed applications and service-oriented architectures (SOAs). Enterprises use Web services to lower the integration cost of business-to-business solutions, allowing partners to share business documents without custom coding.

Web services flexibility comes with risks: Sensitive business data may end up in the wrong hands. Web services providers may be flooded by XML denial-of-service (XDoS) attacks, preventing legitimate users from gaining access. Business documents may be forged or altered, resulting in fraudulent transactions.

In this article, I'll discuss the security considerations for building Web services in a suspicious world - the dangers of working in this world; some old, some new. I then review the technologies that may be applied to address Web services security, along with the significant challenges when using these technologies. I conclude with recommendations on a security architecture that relies on an XML Web services security gateway as the first level of defense for Web services.

The Dangers
Because much of the value of Web services is about connecting sensitive systems together, the underlying risk is quite clear: wide sharing of valuable data leads to more exposure of that data. If we examine this issue more closely, however, we see that data sharing using Web services leads to new risks that are not so obvious.

Where's the Perimeter?
In the world of client/server and operating system security, we have the concept of a trusted computing base (TCB). The TCB consists of the hardware and software mechanisms that are responsible for enforcing the security policy, which defines when a user may access a resource. The TCB creates a security perimeter - valuable resources are protected within the security perimeter, and users must authenticate and pass authorization checks before they are allowed to access data within the perimeter.

In this model, the security perimeter is easy to understand. Bad guys and good guys are outside of the security perimeter, and the TCB distinguishes between the two parties so that only the good guys can access the data within the perimeter. The whole point of a security perimeter is to make sure the bad guys do not get inside.

Figure 1 shows the typical example of this model when applied to Internet connectivity: the IP firewall.

For Web servers, IP firewalls accept or reject HTTP traffic based on corporate policy. It's common, for example, to establish a security perimeter by constraining HTTP traffic to a demilitarized zone (DMZ) in the enterprise and providing an access-control policy for protected resources. IP firewalls usually prohibit external HTTP traffic from entering the internal corporate network.

When we transmit Web services over the IP firewall the simple model of a security perimeter falls apart. XML and SOAP traffic most commonly travel over HTTP, which can be controlled by the IP firewall. However, unlike browser-based Web server traffic, XML and SOAP messages do need to get through to enterprise servers within the corporate network. If IP firewalls are configured to permit Web services traffic within the corporate network, then we have lost our perimeter. IP firewalls cannot distinguish between the trustworthy and nontrustworthy Web services traffic tunneled via HTTP. As a result, attackers could bypass firewall checks and gain access to sensitive enterprise data.

Web services don't have a clear definition of a security perimeter. Because Web services architectures are built from many different service providers distributed across different enterprises, there is no simple way to distinguish the good guys from the bad guys. It's difficult to tell who is trustworthy and who is not.

Consequently, Web services should be created as mutually suspicious islands. Every time a client uses a Web service, the client and Web service establish a trust relationship. Security is enforced at each link of the Web services chain rather than at a single security perimeter. The resulting architecture defines a layered security model where each Web service has its own layer of protection.

Next, we'll examine the security facets that are the basis of trust in the Web services world.

Security Requirements and Related Risks
Web services applications have the same basic information security requirements as any other computer system:

  • Confidentiality: Safeguard user privacy and prevent the theft of enterprise information, both stored and in transit
  • Integrity: Ensure that electronic transactions and data resources are not tampered with at any point, either accidentally or maliciously
  • Accountability: Detect attacks in progress or trace any damage from successful attacks (security auditing and intrusion detection). Prevent system users from later denying completed transactions (nonrepudiation)
  • Availability: Ensure uninterrupted service to authorized users. Service interruptions can be either accidental or maliciously caused by DoS attacks
When deploying any Web services application, you need to consider how to address each of these information security requirements. As you identify security mechanisms that will address the requirements for your Web services, you will encounter common areas of security risk, shown below. Since a Web services architecture defines service interfaces and associated messages sent to those services, the risk areas naturally fall into message, services, and interoperability-related risks:
  • Message-related risks: Caused by potential compromises of the message content transmitted by a Web service. The risks include damaging ill-formed messages, message modification and eavesdropping in transit, and messages sent from nontrustworthy sources.
  • Services-related risks: Caused by potential compromises of the Web service interface. The risks include access to the service by unauthenticated users, access of the service by unauthorized users, and unaudited use of services.
  • Interoperability risks: Caused by potential mismatches of Web services implementations. The risks include vulnerabilities from lack of interoperability with currently deployed security products, and insecure application-to-application message exchange.
As you can see, there are plenty of risks to worry about when deploying Web services applications. Although the underlying security requirements are not new, the lack of a distinct security perimeter and the list of related security risks have resulted in the creation of new technologies that address the specific needs of Web services security. We'll discuss these technologies next.

The Technologies
Standards groups, particularly the Organization for the Advancement of Structured Information Standards (OASIS), the World Wide Web Consortium (W3C), and the Internet Engineering Task Force (IETF) have been very active over the past few years on security-related topics. Several specifications have been defined that together serve as the basis for Web services security solutions.

Security Building Blocks
The security of Web services relies on three key standards: Secure Sockets Layer (SSL)/Transport Layer Security (TLS), XML Digital Signature, and XML Encryption. SSL/TLS provides public key-based transport layer security that enforces confidentiality and integrity of message content. SSL/TLS is especially pervasive for Internet-based HTTP traffic, including Web services messages. XML Digital Signature specifies how to sign XML document elements to prevent tampering, while XML Encryption specifies how to encrypt elements to prevent disclosure.

The combination of SSL/TLS, XML Digital Signature, and XML Encryption go a long way toward addressing many Web services security requirements. Why aren't they enough? Although these standards are flexible and powerful, they are often too low level for convenient use. In particular, there are so many ways to enforce security with these standards that different uses may not easily interoperate without additional guidelines.

Upper-Layer Security
Built on the security building blocks we just described, the upper-layer security standards provide Web services security support in a more convenient package:

  • WS-Security: Provides packaging for SOAP messages - it defines how to attach signature, encryption, and security tokens to SOAP messages.
  • Security Assertion Markup Language (SAML): Defines the XML format for exchanging authentication, authorization, and attribute assertions; and includes the protocol for requesting this information from security authorities.
  • Extensible Access Control Markup Language (XACML): XML specification for expressing access control policies.
  • XML Key Management Specification (XKMS): Defines the interface for accessing keys and PKI servers using XML.
The Challenges
There are several technical challenges when assembling these technologies together to secure a set of Web services. In this section, we focus on three of the most significant: interoperability, performance, and preventing XML denial of service (XDoS).

Putting Together an Interoperable Security Solution
At this point you may have the impression that there are a lot of standards and technologies involved in Web services security, and that is certainly true. The main technical problem is not whether the appropriate Web services security mechanism is available, because it probably already is. Instead, the issue facing both vendors and customers is how to assemble an effective, simple, and interoperable solution out of the many available building blocks.

Figure 2 shows a typical layering of security mechanisms and protocols in support of a Web services deployment. As shown in the figure, the Web services sender and receiver are connected via an intermediary server, which could be providing infrastructure services such as message routing, or business-level services such as an e-commerce marketplace. We can see that HTTPS (HTTP over SSL/TLS) secures the point-to-point connections from sender to intermediary, and intermediary to receiver. Because SSL/TLS is transport-level security, it cannot by itself provide end-to-end security between sender and receiver. For example, SSL/TLS is inadequate if the sender needs to send encrypted data (say, a credit card number) that is not exposed to the intermediary. In this case the sender could use XML encryption and WS-Security to tunnel encrypted data through the intermediary to reach the receiver.

The Web Services Interoperability Organization (WS-I) is chartered to promote interoperability, and is working on providing guidelines for interoperability of Web services security. In particular, the WS-I Basic Security Profile Working Group is defining security scenarios and a security profile document to help enterprises piece together many of these standards to ensure interoperability.

Performance is often the most significant challenge when deploying Web services security solutions. We'll use Figure 3 to illustrate some of the performance issues you are likely to encounter. This figure offers an example of a typical set of processing steps that might be required to secure a SOAP/XML transaction. As the transaction is processed, it is parsed, its schema is validated, XPath filtering is applied, it is decrypted, and so on, until the transaction processing is completed.

The first thing to note about the example is the sheer number of security processing steps required. For Web services with security requirements that span the areas of confidentiality, integrity, accountability, and availability, this number of steps is not unusual.

In Figure 3 the numbers and colored bars show the relative computational cost of each processing step. The green bars represent the time spent in XML-related computations, such as parsing, schema validation, and transformation. The red bars represent the time spent in cryptographic-related computations, such as public key encryption and decryption. To give you an idea of the latency involved in one of these steps, an XML signature of a modest-size message using typical software-based implementations can take well over 100 milliseconds.

Although you might expect cryptographic processing to dominate Web services security processing, the example shows this is typically not true. Because XML is so expensive to analyze and transform, Web services security enforcement generally spends much more time performing XML processing than cryptographic processing.

As a consequence, it's important to realize that performance optimization for Web services security requires addressing both cryptography and XML acceleration. SSL and cryptographic hardware accelerators help speed up Web services security processing, but unless you also consider acceleration of XML processing you are unlikely to see significant performance improvement.

Finally, you should consider the additional security performance overhead due to the stateless nature of Web services. Browser-based Web server security can take advantage of a security session to optimize security. When accessing a Web server, the initial authentication step (for example, using a password or digital certificate) may be slow, but it happens only once per session, so the user experiences minimal delay. In contrast, every Web service transaction must be authenticated, so this performance penalty is paid on every transaction. The end result is a potentially lengthy fixed authentication delay built into the response time of every Web service transaction.

XML Denial of Service (XDoS)
One challenge that enterprises are only beginning to consider is XDoS. This concept may be new to most people, but experts agree that protecting against XDoS attacks will be a common issue as more Web services are exposed on the Internet.

Years of experience have shown that Web servers must be protected against DoS attacks. There are many variants on these attacks, such as the virus infections of huge numbers of consumer PCs with Trojan horse programs, which are then launched remotely at a later time to flood a target Web server host and bring it down. IP firewalls commonly contain countermeasures against these attacks by limiting the rate of traffic from an IP address and detecting hostile patterns of incoming messages.

The analogous XDoS attacks in the Web services scenario will be more serious. Because of the resources required to process XML, it is much easier for the attacker to create and transmit malicious XML than it is for the defender to process and reject the XML. XML supports rich and complex document structures, including recursion, which can potentially cause infinite loops during input processing. While IP-based DoS attacks usually require large numbers of messages, an XDoS attack can be launched on a Web service with a single 2KB malformed XML message.

Countermeasures for XDoS attacks are straightforward to define. For example, incoming XML should be schema validated to ensure that the XML conforms to a supported Web service interface. Message monitors may be installed to check thresholds on message rates, and content-based filters can be used to detect recursion depth and other complexity measures of the XML document.

Although XDoS countermeasures may be clear, their implementation is definitely a challenge. The only way to effectively deal with XDoS is to have a high-speed XML engine that can detect and dispose of these attacks before the server is overwhelmed. From our previous discussion, we have already seen that performance is a major challenge when deploying Web service security; the burden of XDoS detection compounds this problem. As in the case of IP firewalls that handle DoS attacks, it is sensible to consider an engine that offloads the Web service server from needing to handle this processing.

The Solutions
Web services security can be enforced in a variety of places in the architecture. In this section, I make some recommendations on the best approach to use. I discuss using an XML security gateway as the first level of defense, and then adding Web services application-based security as a second level of defense as needed.

First Level of Defense: XML Security Gateway
Based on the challenges I described previously, I recommend starting with a hardware-based XML security gateway as the simplest and most effective way to enforce Web services security. An XML security gateway is typically deployed behind an existing IP firewall, and secures all XML traffic before it reaches the Web service on the application server. A hardware-based XML security gateway has many advantages, including:

  • Performance: An optimized hardware solution that addresses both XML acceleration and cryptographic processing will improve latency and throughput of XML security processing by a factor of at least 10 over software implementations. In many cases the performance improvements are considerably larger.
  • Scalability: By deploying a high-capacity XML security gateway, the number of application server platforms may be significantly reduced. An XML security gateway can handle an increased Web services transaction load without needing to add additional application servers.
  • Manageability: By channeling all Web services traffic through a small number of high-capacity gateways, the number of security enforcement points is reduced. This simplifies the security configuration and makes changes easier to manage.
  • Simplicity: An XML security gateway can enforce the majority of Web services security requirements, thus avoiding the need to write security code within the Web service applications.
  • Security: Removing security from applications is a best practice, and improves the security assurance of the architecture. As in the case of an IP firewall, an XML security gateway is a hardened security platform that protects potentially vulnerable application servers.
  • Availability: XDoS is a significant threat to Web service availability. An XML security gateway provides high-performance XDoS checking to protect Web services applications.
  • Interoperability: Web services security standards and technologies are a moving target, and will continue to evolve. An XML security gateway is a natural place in the architecture to translate across multiple transports and security standards.
  • Monitoring: Because Web services traffic passes through the gateway, it provides an effective central enforcement point for audit logging and accountability.
Second Level of Defense: Web Services Application
Although the first level of defense for Web services belongs on an XML security gateway, there are important cases where it makes sense to have a second level of defense on the Web services application platform.

Both J2EE and .NET application server platforms have their own container-based security models. In existing component deployments, the application server security policy may be an important part of protecting the application. Legacy applications may also have business-specific security embedded with in. In these cases, it is possible to integrate the security enforced at the XML security gateway with application server security. In particular, security context information that is authenticated at the XML security gateway and based on Web services standards such as WS-Security and SAML may be used to enforce authorization and audit policies on the application server.

The most common deployment of an XML security gateway is as a proxy within the enterprise DMZ (see Figure 4). In this configuration, the XML security gateway protects the application server against Internet-based XDoS attacks and enforces incoming access control, including authentication and authorization. The XML security gateway may also be deployed as a proxy to protect access within the corporate intranet.

For a more advanced deployment, the XML security gateway may be installed on the Web services client side. In this scenario, the gateway provides outgoing access control, limiting the transmission of sensitive data to the Internet. The gateway can also be used to secure a federated extranet, where the Web services client and server environments do not share common security policies and mechanisms. To address federated extranet security, the XML security gateways can use SAML as a common standardized security token to map client-side security policy to server-side security policy.

This article described many of the issues that need to be considered when deploying an enterprise Web services architecture. The traditional concept of a single security perimeter does not apply to the loosely coupled concept of Web services. Instead, I advocate viewing Web service applications as mutually suspicious islands that need to establish trust before communicating to a partner application. Mutual suspicion means that there is no central point of trust in the architecture. XML security gateways protect each Web service application and establish trust; in this manner, a security architecture is defined by the network of XML security gateways and application servers.

I described a number of security challenges when assembling a Web services security solution. The first is interoperability; the existing standards are complex and still evolving, so it's difficult to ensure that your Web services security implementation will interoperate with your partner's. Future guidelines from groups like the WS-I Basic Security Profile Working Group will help you through this process. In the meantime, an XML security gateway can serve as a translation point between incompatible security technologies, and evolve as your requirements change.

The other major challenge of Web services security is performance. I described the close relationship between security and performance, which is due to the large processing burden of XML as well as the additional processing load caused by XDoS attacks. An XML security gateway has the processing capacity to handle XML security traffic quickly and efficiently.

More Stories By Bret Hartman

Bret Hartman, VP of Technology Solutions at DataPower, has more than 23 years of experience in information security and secure systems development. His expertise includes Web Services security, distributed component security, policy development and management, and security modeling and analysis. Bret is a nationally recognized expert on distributed systems security; and he is a book author, regular speaker, and panelist on a variety of secure distributed system topics.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

@MicroservicesExpo Stories
Most companies are adopting or evaluating container technology - Docker in particular - to speed up application deployment, drive down cost, ease management and make application delivery more flexible overall. As with most new architectures, this dream takes a lot of work to become a reality. Even when you do get your application componentized enough and packaged properly, there are still challenges for DevOps teams to making the shift to continuous delivery and achieving that reduction in cost ...
Don’t go chasing waterfall … development, that is. According to a recent post by Madison Moore on Medium featuring insights from several software delivery industry leaders, waterfall is – while still popular – not the best way to win in the marketplace. With methodologies like Agile, DevOps and Continuous Delivery becoming ever more prominent over the past 15 years or so, waterfall is old news. Or, is it? Moore cites a recent study by Gartner: “According to Gartner’s IT Key Metrics Data report, ...
All organizations that did not originate this moment have a pre-existing culture as well as legacy technology and processes that can be more or less amenable to DevOps implementation. That organizational culture is influenced by the personalities and management styles of Executive Management, the wider culture in which the organization is situated, and the personalities of key team members at all levels of the organization. This culture and entrenched interests usually throw a wrench in the work...
Many organizations are now looking to DevOps maturity models to gauge their DevOps adoption and compare their maturity to their peers. However, as enterprise organizations rush to adopt DevOps, moving past experimentation to embrace it at scale, they are in danger of falling into the trap that they have fallen into time and time again. Unfortunately, we've seen this movie before, and we know how it ends: badly.
In his session at Cloud Expo, Alan Winters, U.S. Head of Business Development at MobiDev, presented a success story of an entrepreneur who has both suffered through and benefited from offshore development across multiple businesses: The smart choice, or how to select the right offshore development partner Warning signs, or how to minimize chances of making the wrong choice Collaboration, or how to establish the most effective work processes Budget control, or how to maximize project result...
In his keynote at 19th Cloud Expo, Sheng Liang, co-founder and CEO of Rancher Labs, discussed the technological advances and new business opportunities created by the rapid adoption of containers. With the success of Amazon Web Services (AWS) and various open source technologies used to build private clouds, cloud computing has become an essential component of IT strategy. However, users continue to face challenges in implementing clouds, as older technologies evolve and newer ones like Docker c...
For organizations that have amassed large sums of software complexity, taking a microservices approach is the first step toward DevOps and continuous improvement / development. Integrating system-level analysis with microservices makes it easier to change and add functionality to applications at any time without the increase of risk. Before you start big transformation projects or a cloud migration, make sure these changes won’t take down your entire organization.
Without a clear strategy for cost control and an architecture designed with cloud services in mind, costs and operational performance can quickly get out of control. To avoid multiple architectural redesigns requires extensive thought and planning. Boundary (now part of BMC) launched a new public-facing multi-tenant high resolution monitoring service on Amazon AWS two years ago, facing challenges and learning best practices in the early days of the new service.
You often hear the two titles of "DevOps" and "Immutable Infrastructure" used independently. In his session at DevOps Summit, John Willis, Technical Evangelist for Docker, covered the union between the two topics and why this is important. He provided an overview of Immutable Infrastructure then showed how an Immutable Continuous Delivery pipeline can be applied as a best practice for "DevOps." He ended the session with some interesting case study examples.
Both SaaS vendors and SaaS buyers are going “all-in” to hyperscale IaaS platforms such as AWS, which is disrupting the SaaS value proposition. Why should the enterprise SaaS consumer pay for the SaaS service if their data is resident in adjacent AWS S3 buckets? If both SaaS sellers and buyers are using the same cloud tools, automation and pay-per-transaction model offered by IaaS platforms, then why not host the “shrink-wrapped” software in the customers’ cloud? Further, serverless computing, cl...
"We view the cloud not as a specific technology but as a way of doing business and that way of doing business is transforming the way software, infrastructure and services are being delivered to business," explained Matthew Rosen, CEO and Director at Fusion, in this SYS-CON.tv interview at 18th Cloud Expo (http://www.CloudComputingExpo.com), held June 7-9 at the Javits Center in New York City, NY.
Without lifecycle traceability and visibility across the tool chain, stakeholders from Planning-to-Ops have limited insight and answers to who, what, when, why and how across the DevOps lifecycle. This impacts the ability to deliver high quality software at the needed velocity to drive positive business outcomes. In his general session at @DevOpsSummit at 19th Cloud Expo, Eric Robertson, General Manager at CollabNet, will discuss how customers are able to achieve a level of transparency that e...
We all know that end users experience the internet primarily with mobile devices. From an app development perspective, we know that successfully responding to the needs of mobile customers depends on rapid DevOps – failing fast, in short, until the right solution evolves in your customers' relationship to your business. Whether you’re decomposing an SOA monolith, or developing a new application cloud natively, it’s not a question of using microservices - not doing so will be a path to eventual ...
"DivvyCloud as a company set out to help customers automate solutions to the most common cloud problems," noted Jeremy Snyder, VP of Business Development at DivvyCloud, in this SYS-CON.tv interview at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY.
We all know that end users experience the Internet primarily with mobile devices. From an app development perspective, we know that successfully responding to the needs of mobile customers depends on rapid DevOps – failing fast, in short, until the right solution evolves in your customers' relationship to your business. Whether you’re decomposing an SOA monolith, or developing a new application cloud natively, it’s not a question of using microservices – not doing so will be a path to eventual b...
"This all sounds great. But it's just not realistic." This is what a group of five senior IT executives told me during a workshop I held not long ago. We were working through an exercise on the organizational characteristics necessary to successfully execute a digital transformation, and the group was doing their ‘readout.' The executives loved everything we discussed and agreed that if such an environment existed, it would make transformation much easier. They just didn't believe it was reali...
"Opsani helps the enterprise adopt containers, help them move their infrastructure into this modern world of DevOps, accelerate the delivery of new features into production, and really get them going on the container path," explained Ross Schibler, CEO of Opsani, and Peter Nickolov, CTO of Opsani, in this SYS-CON.tv interview at DevOps Summit at 21st Cloud Expo, held Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA.
Your homes and cars can be automated and self-serviced. Why can't your storage? From simply asking questions to analyze and troubleshoot your infrastructure, to provisioning storage with snapshots, recovery and replication, your wildest sci-fi dream has come true. In his session at @DevOpsSummit at 20th Cloud Expo, Dan Florea, Director of Product Management at Tintri, provided a ChatOps demo where you can talk to your storage and manage it from anywhere, through Slack and similar services with...
"I focus on what we are calling CAST Highlight, which is our SaaS application portfolio analysis tool. It is an extremely lightweight tool that can integrate with pretty much any build process right now," explained Andrew Siegmund, Application Migration Specialist for CAST, in this SYS-CON.tv interview at 21st Cloud Expo, held Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA.
Explosive growth in connected devices. Enormous amounts of data for collection and analysis. Critical use of data for split-second decision making and actionable information. All three are factors in making the Internet of Things a reality. Yet, any one factor would have an IT organization pondering its infrastructure strategy. How should your organization enhance its IT framework to enable an Internet of Things implementation? In his session at @ThingsExpo, James Kirkland, Red Hat's Chief Archi...