Welcome!

Microservices Expo Authors: Stackify Blog, Aruna Ravichandran, Dalibor Siroky, Kevin Jackson, PagerDuty Blog

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
How is DevOps going within your organization? If you need some help measuring just how well it is going, we have prepared a list of some key DevOps metrics to track. These metrics can help you understand how your team is doing over time. The word DevOps means different things to different people. Some say it a culture and every vendor in the industry claims that their tools help with DevOps. Depending on how you define DevOps, some of these metrics may matter more or less to you and your team.
For many of us laboring in the fields of digital transformation, 2017 was a year of high-intensity work and high-reward achievement. So we’re looking forward to a little breather over the end-of-year holiday season. But we’re going to have to get right back on the Continuous Delivery bullet train in 2018. Markets move too fast and customer expectations elevate too precipitously for businesses to rest on their laurels. Here’s a DevOps “to-do list” for 2018 that should be priorities for anyone w...
If testing environments are constantly unavailable and affected by outages, release timelines will be affected. You can use three metrics to measure stability events for specific environments and plan around events that will affect your critical path to release.
In a recent post, titled “10 Surprising Facts About Cloud Computing and What It Really Is”, Zac Johnson highlighted some interesting facts about cloud computing in the SMB marketplace: Cloud Computing is up to 40 times more cost-effective for an SMB, compared to running its own IT system. 94% of SMBs have experienced security benefits in the cloud that they didn’t have with their on-premises service
DevOps failure is a touchy subject with some, because DevOps is typically perceived as a way to avoid failure. As a result, when you fail in a DevOps practice, the situation can seem almost hopeless. However, just as a fail-fast business approach, or the “fail and adjust sooner” methodology of Agile often proves, DevOps failures are actually a step in the right direction. They’re the first step toward learning from failures and turning your DevOps practice into one that will lead you toward even...
DevOps is under attack because developers don’t want to mess with infrastructure. They will happily own their code into production, but want to use platforms instead of raw automation. That’s changing the landscape that we understand as DevOps with both architecture concepts (CloudNative) and process redefinition (SRE). Rob Hirschfeld’s recent work in Kubernetes operations has led to the conclusion that containers and related platforms have changed the way we should be thinking about DevOps and...
The goal of Microservices is to improve software delivery speed and increase system safety as scale increases. Microservices being modular these are faster to change and enables an evolutionary architecture where systems can change, as the business needs change. Microservices can scale elastically and by being service oriented can enable APIs natively. Microservices also reduce implementation and release cycle time and enables continuous delivery. This paper provides a logical overview of the Mi...
While walking around the office I happened upon a relatively new employee dragging emails from his inbox into folders. I asked why and was told, “I’m just answering emails and getting stuff off my desk.” An empty inbox may be emotionally satisfying to look at, but in practice, you should never do it. Here’s why. I recently wrote a piece arguing that from a mathematical perspective, Messy Desks Are Perfectly Optimized. While it validated the genius of my friends with messy desks, it also gener...
The next XaaS is CICDaaS. Why? Because CICD saves developers a huge amount of time. CD is an especially great option for projects that require multiple and frequent contributions to be integrated. But… securing CICD best practices is an emerging, essential, yet little understood practice for DevOps teams and their Cloud Service Providers. The only way to get CICD to work in a highly secure environment takes collaboration, patience and persistence. Building CICD in the cloud requires rigorous ar...
The enterprise data storage marketplace is poised to become a battlefield. No longer the quiet backwater of cloud computing services, the focus of this global transition is now going from compute to storage. An overview of recent storage market history is needed to understand why this transition is important. Before 2007 and the birth of the cloud computing market we are witnessing today, the on-premise model hosted in large local data centers dominated enterprise storage. Key marketplace play...
The cloud revolution in enterprises has very clearly crossed the phase of proof-of-concepts into a truly mainstream adoption. One of most popular enterprise-wide initiatives currently going on are “cloud migration” programs of some kind or another. Finding business value for these programs is not hard to fathom – they include hyperelasticity in infrastructure consumption, subscription based models, and agility derived from rapid speed of deployment of applications. These factors will continue to...
Some people are directors, managers, and administrators. Others are disrupters. Eddie Webb (@edwardawebb) is an IT Disrupter for Software Development Platforms at Liberty Mutual and was a presenter at the 2016 All Day DevOps conference. His talk, Organically DevOps: Building Quality and Security into the Software Supply Chain at Liberty Mutual, looked at Liberty Mutual's transformation to Continuous Integration, Continuous Delivery, and DevOps. For a large, heavily regulated industry, this task ...
Following a tradition dating back to 2002 at ZapThink and continuing at Intellyx since 2014, it’s time for Intellyx’s annual predictions for the coming year. If you’re a long-time fan, you know we have a twist to the typical annual prediction post: we actually critique our predictions from the previous year. To make things even more interesting, Charlie and I switch off, judging the other’s predictions. And now that he’s been with Intellyx for more than a year, this Cortex represents my first ...
"Grape Up leverages Cloud Native technologies and helps companies build software using microservices, and work the DevOps agile way. We've been doing digital innovation for the last 12 years," explained Daniel Heckman, of Grape Up 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.
The Toyota Production System, a world-renowned production system is based on the "complete elimination of all waste". The "Toyota Way", grounded on continuous improvement dates to the 1860s. The methodology is widely proven to be successful yet there are still industries within and tangential to manufacturing struggling to adopt its core principles: Jidoka: a process should stop when an issue is identified prevents releasing defective products
Defining the term ‘monitoring’ is a difficult task considering the performance space has evolved significantly over the years. Lately, there has been a shift in the monitoring world, sparking a healthy debate regarding the definition and purpose of monitoring, through which a new term has emerged: observability. Some of that debate can be found in blogs by Charity Majors and Cindy Sridharan.
We seem to run this cycle with every new technology that comes along. A good idea with practical applications is born, then both marketers and over-excited users start to declare it is the solution for all or our problems. Compliments of Gartner, we know it generally as “The Hype Cycle”, but each iteration is a little different. 2018’s flavor will be serverless computing, and by 2018, I mean starting now, but going most of next year, you’ll be sick of it. We are already seeing people write such...
It’s “time to move on from DevOps and continuous delivery.” This was the provocative title of a recent article in ZDNet, in which Kelsey Hightower, staff developer advocate at Google Cloud Platform, suggested that “software shops should have put these concepts into action years ago.” Reading articles like this or listening to talks at most DevOps conferences might make you think that we’re entering a post-DevOps world. But vast numbers of organizations still struggle to start and drive transfo...
Let's do a visualization exercise. Imagine it's December 31, 2018, and you're ringing in the New Year with your friends and family. You think back on everything that you accomplished in the last year: your company's revenue is through the roof thanks to the success of your product, and you were promoted to Lead Developer. 2019 is poised to be an even bigger year for your company because you have the tools and insight to scale as quickly as demand requires. You're a happy human, and it's not just...
"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.