SOA Security 101: Patching the Firewall Hole
Well, if the security considerations that applied to traditional application architectures applied to SOAs, then the aforementioned controls would be sufficient. But unfortunately service-oriented solutions are different. Unlike the interoperability challenges that stunted the growth of Common Object Request Broker Architecture (CORBA), today’s SOAs are interoperable, relying often on Web services based on standards such as XML for encapsulation and HTTP/HTTPS for transport. It is in fact this interoperability and interdependence between entities that has influenced a new frontier of security threats.
Unlike conventional application architecture, service-oriented solutions that expose Web services to external users and business partners are more susceptible to unauthorized access. Traditionally application architectures allowed limited external access with adequate security controls in place to do so. Message-level security was unnecessary because all processing was carried out internally, within the application. Instead the emphasis of security was on how the message was transported. The contents of the messages were assumed to be valid since they were coming from one trusted source within the organization.
In a service-oriented infrastructure, a solution invites all HTTP/HTTPS traffic through its firewalls, and does little to differentiate between a malicious or valid message. A typical organization’s border and internal firewalls are packet filtering and “allow” all HTTP/HTTPS traffic back to the application server from an uncontrolled zone to a DMZ to a secure zone without inspection. Thus, the service-oriented solution has introduced a hole in the firewall.
Understanding the Risks of Exposure
To offer a rudimentary understanding of the new threats, we’ll consider them in the context of a sample scenario with “Big Bank”. Suppose Big Bank is developing an application to issue checks and has implemented a Web service called “cut_check”. The cut_check service may be accessed by other Big Bank organizations and business partners on disparate networks across the world. Following best practices, the application will have its Web server in the DMZ and application server (containing business logic) in a separate security zone, away from the DMZ, protected by packet filtering.
Conventional application security architecture would not allow direct access to the cut_check service running on the application server, but instead would only accept requests through a proxy, such as an HTTP Web server in a DMZ. The cut_check service would process each transaction at the application server and would then present the results upon completion of each transaction to the Web server to display back to the user.
As illustrated in the top of portion of Figure 1, the user makes a request to the application, the application makes a request to the service, and the response is provided back to the user. However, as shown on the bottom portion of Figure 1, a service-oriented solution introduces new methods of invocation. The service may be directly exposed to the user, invoked by another Web service, or it may invoke a service directly. The service-to-service invocation can result in a chaining or composition of services to perform a specific operation.
For example, at Big Bank the clerk may issue cut_check which may rely on another service such as calc_taxes (that determines the amount of tax to be drawn prior to issuance). Consequently, the service-to-service use cases also require security controls similar to user-to-service scenarios.
Figure 1: The shifting architectural paradigms introduced by SOA.
Furthermore, SOA-based applications are incubating a new breed of security threats to Web based applications. There are numerous attack scenarios around Web services already being exploited and the list keeps growing. The types of attacks include, but are not limited to: denial of service, replay, message alteration, breach of confidentiality, man in the middle, and spoofing attacks.
In particular, XML attacks tend to be the most pervasive through well-formed SOAP messages embedded in HTTP/HTTPS protocols. Overall, there are four broad classifications of threats associated with XML, as summarized in Table 1.
Table 1 - Common types of XML attacks.
The astute architect might suggest that transport layer security mechanisms such as Secure Sockets Layer (SSL) or Transport Layer Security (TLS) addresses the XML threat. However, security at the transport layer of the OSI model is just not enough. It doesn’t address the context of SOA scenarios because it doesn’t protect against malicious content included in the message. It simply encrypts the malicious code embedded in the XML message written by a, perhaps, authorized user with access the service. Once the packet is opened by the application it is too late.
Thus network and host system controls, identity and access management controls, and data encryption controls during storage and transit must be supplemented with additional controls to protect the message payload. This additional control is required given that the application is now open to a broader audience and is accessed with standard protocols instead of proprietary extensions.
SOA Security Design Considerations
A layered security architecture provides the best defense for a service-oriented architecture. The most effective architectures certainly use strong network and host system controls, identity and access management controls, and data encryption during transit and storage, but also rely on Web service security. Two fundamental design considerations used to secure Web services focus on packet and message-level security.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)