Welcome!

Microservices Expo Authors: Elizabeth White, Aruna Ravichandran, Pat Romanski, Liz McMillan, Cameron Van Orman

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
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.

Deployment
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.

Conclusion
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
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...
Transforming cloud-based data into a reportable format can be a very expensive, time-intensive and complex operation. As a SaaS platform with more than 30 million global users, Cornerstone OnDemand’s challenge was to create a scalable solution that would improve the time it took customers to access their user data. Our Real-Time Data Warehouse (RTDW) process vastly reduced data time-to-availability from 24 hours to just 10 minutes. In his session at 21st Cloud Expo, Mark Goldin, Chief Technolo...
Digital transformation leaders have poured tons of money and effort into coding in recent years. And with good reason. To succeed at digital, you must be able to write great code. You also have to build a strong Agile culture so your coding efforts tightly align with market signals and business outcomes. But if your investments in testing haven’t kept pace with your investments in coding, you’ll lose. But if your investments in testing haven’t kept pace with your investments in coding, you’ll...
In his session at 21st Cloud Expo, Michael Burley, a Senior Business Development Executive in IT Services at NetApp, will describe how NetApp designed a three-year program of work to migrate 25PB of a major telco's enterprise data to a new STaaS platform, and then secured a long-term contract to manage and operate the platform. This significant program blended the best of NetApp’s solutions and services capabilities to enable this telco’s successful adoption of private cloud storage and launchi...
DevOps is often described as a combination of technology and culture. Without both, DevOps isn't complete. However, applying the culture to outdated technology is a recipe for disaster; as response times grow and connections between teams are delayed by technology, the culture will die. A Nutanix Enterprise Cloud has many benefits that provide the needed base for a true DevOps paradigm. In their Day 3 Keynote at 20th Cloud Expo, Chris Brown, a Solutions Marketing Manager at Nutanix, and Mark Lav...
Enterprises are adopting Kubernetes to accelerate the development and the delivery of cloud-native applications. However, sharing a Kubernetes cluster between members of the same team can be challenging. And, sharing clusters across multiple teams is even harder. Kubernetes offers several constructs to help implement segmentation and isolation. However, these primitives can be complex to understand and apply. As a result, it’s becoming common for enterprises to end up with several clusters. Thi...
Containers are rapidly finding their way into enterprise data centers, but change is difficult. How do enterprises transform their architecture with technologies like containers without losing the reliable components of their current solutions? In his session at @DevOpsSummit at 21st Cloud Expo, Tony Campbell, Director, Educational Services at CoreOS, will explore the challenges organizations are facing today as they move to containers and go over how Kubernetes applications can deploy with lega...
Today 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 significant 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 reducti...
DevOps at Cloud Expo, taking place October 31 - November 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA, is co-located with 21st Cloud Expo and will feature technical sessions from a rock star conference faculty and the leading industry players in the world. The widespread success of cloud computing is driving the DevOps revolution in enterprise IT. Now as never before, development teams must communicate and collaborate in a dynamic, 24/7/365 environment. There is no time to w...
Is advanced scheduling in Kubernetes achievable? Yes, however, how do you properly accommodate every real-life scenario that a Kubernetes user might encounter? How do you leverage advanced scheduling techniques to shape and describe each scenario in easy-to-use rules and configurations? In his session at @DevOpsSummit at 21st Cloud Expo, Oleg Chunikhin, CTO at Kublr, will answer these questions and demonstrate techniques for implementing advanced scheduling. For example, using spot instances ...
SYS-CON Events announced today that Cloud Academy has been named “Bronze Sponsor” of SYS-CON's 21st International Cloud Expo®, which will take place on Oct. 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA. Cloud Academy is the leading technology training platform for enterprise multi-cloud infrastructure. Cloud Academy is trusted by leading companies to deliver continuous learning solutions across Amazon Web Services, Microsoft Azure, Google Cloud Platform, and the most...
The last two years has seen discussions about cloud computing evolve from the public / private / hybrid split to the reality that most enterprises will be creating a complex, multi-cloud strategy. Companies are wary of committing all of their resources to a single cloud, and instead are choosing to spread the risk – and the benefits – of cloud computing across multiple providers and internal infrastructures, as they follow their business needs. Will this approach be successful? How large is the ...
Many organizations adopt DevOps to reduce cycle times and deliver software faster; some take on DevOps to drive higher quality and better end-user experience; others look to DevOps for a clearer line-of-sight to customers to drive better business impacts. In truth, these three foundations go together. In this power panel at @DevOpsSummit 21st Cloud Expo, moderated by DevOps Conference Co-Chair Andi Mann, industry experts will discuss how leading organizations build application success from all...
DevSecOps – a trend around transformation in process, people and technology – is about breaking down silos and waste along the software development lifecycle and using agile methodologies, automation and insights to help get apps to market faster. This leads to higher quality apps, greater trust in organizations, less organizational friction, and ultimately a five-star customer experience. These apps are the new competitive currency in this digital economy and they’re powered by data. Without ...
A common misconception about the cloud is that one size fits all. Companies expecting to run all of their operations using one cloud solution or service must realize that doing so is akin to forcing the totality of their business functionality into a straightjacket. Unlocking the full potential of the cloud means embracing the multi-cloud future where businesses use their own cloud, and/or clouds from different vendors, to support separate functions or product groups. There is no single cloud so...
For most organizations, the move to hybrid cloud is now a question of when, not if. Fully 82% of enterprises plan to have a hybrid cloud strategy this year, according to Infoholic Research. The worldwide hybrid cloud computing market is expected to grow about 34% annually over the next five years, reaching $241.13 billion by 2022. Companies are embracing hybrid cloud because of the many advantages it offers compared to relying on a single provider for all of their cloud needs. Hybrid offers bala...
With the modern notion of digital transformation, enterprises are chipping away at the fundamental organizational and operational structures that have been with us since the nineteenth century or earlier. One remarkable casualty: the business process. Business processes have become so ingrained in how we envision large organizations operating and the roles people play within them that relegating them to the scrap heap is almost unimaginable, and unquestionably transformative. In the Digital ...
These days, APIs have become an integral part of the digital transformation journey for all enterprises. Every digital innovation story is connected to APIs . But have you ever pondered over to know what are the source of these APIs? Let me explain - APIs sources can be varied, internal or external, solving different purposes, but mostly categorized into the following two categories. Data lakes is a term used to represent disconnected but relevant data that are used by various business units wit...
The nature of the technology business is forward-thinking. It focuses on the future and what’s coming next. Innovations and creativity in our world of software development strive to improve the status quo and increase customer satisfaction through speed and increased connectivity. Yet, while it's exciting to see enterprises embrace new ways of thinking and advance their processes with cutting edge technology, it rarely happens rapidly or even simultaneously across all industries.
It has never been a better time to be a developer! Thanks to cloud computing, deploying our applications is much easier than it used to be. How we deploy our apps continues to evolve thanks to cloud hosting, Platform-as-a-Service (PaaS), and now Function-as-a-Service. FaaS is the concept of serverless computing via serverless architectures. Software developers can leverage this to deploy an individual "function", action, or piece of business logic. They are expected to start within milliseconds...