Are you Insecure about SOA Security?

Service-oriented architecture (SOA) creates tremendous opportunities for companies to integrate across departments, across systems and across enterprises. Integration can help simplify business processes, improve speed to market, allow companies to react quicker to changes in the business, and share data and services. For example, SOA architected correctly can allow an e-commerce site to integrate seamlessly with its suppliers, distributors, credit card companies and consumers. After a customer places an order, a flurry of messages is orchestrated by the system without asking for any of the users or systems to login each time.

SOA also allows companies to rejuvenate their legacy systems by abstracting certain business processes, services, or data points without having to rip out and replace these systems. Companies can leverage their existing investments in their legacy systems while building new systems that seamlessly integrate with them.

To the end users this is nirvana. To the folks in the security department, this is their worst nightmare!

Integration Side Effects

The benefits I mentioned above come with great risks in the area of security, privacy and compliance. For services to integrate easily with other services both behind and outside of the firewall, they must be discoverable and easy to translate. Many SOA implementations use Web services. Web services use WSDL (Web Service Description Language) which describes how to invoke the service. UDDI (Universal Description, Discovery, and Integration) is a standard that is commonly used with Web Services that allow services to be discovered and retrieved. Two other important standards frequently used in an SOA are XML (eXtensible Markup Language) and SOAP (Simple Object Access Protocol). XML is a self describing format that contains information about the messages in clear text while SOAP is a protocol for exchanging XML based messages and provides important information in the clear. While these standards make it easier for companies to integrate services, it also could give the keys to the kingdom away to hackers if the proper security is not in place.

Many legacy systems were never architected to be exposed to other systems, especially systems outside of the firewall. Now with SOA, hackers can get access to systems and data that they couldn’t get to before, thanks to the discovery and self-describing nature of SOA.

Challenges Within the Enterprise

I reached out to a number of architects, vendors, trainers and security experts and asked them a simple question: What are the biggest security risks that you feel architects need to address when implementing SOA? The answers I received can be lumped into the following categories:

• Lack of awareness, knowledge within organizations of the magnitude of the risks.
• Propagating credentials across services, systems, and enterprises.
• Ability to monitor, audit, and enforce policies.

Lack of Awareness/Knowledge

It is critical that the enterprise architects get proper training so that they understand SOA well enough to identify the risks. Many SOA initiatives are driven by the EA group from the technology standpoint. If the architects are not aware of the risks and issues, not only will they not be aware of what needs to be built to secure the services, but they also won’t know when to bring in the security and auditing experts. Security needs to be built in upfront and should not be an afterthought. Building security into each service would be a burden to the performance and maintainability of each service. Security should be implemented as a set of core services that allow security to be centrally managed and maintained. In addition, management must understand the risks and provide the proper support and funding required to effectively secure the enterprise.

Propagating Credentials

Many services are “headless,” which means that they have no associated user interface. These services are invoked by and invoke other services and must pass credentials in order for the overall systems to flow from start to finish without interruption. To make matters more challenging, a single message may contain XML data for multiple service consumers.

For example, using the example of an e-commerce site, an order can trigger a message that contains XML data for a supplier, a distributor, and a credit card company with different security requirements for each. Only the credit card company should have access to the credit card information (which should be encrypted to be PCI compliant). The supplier needs to know which products where taken out of inventory, while the distributor needs information about the product and the shipping address. So you can see from this example that the old days of simply using SSL is not enough. In this example, the same message is sent to three different companies without asking any of them to log in. Many companies are adopting the WS-* standards (Ws-Security, WS-Trust, WS- Federation, Ws-Policy, etc.) to address these risks.

Best practices include XML encryption, using public keys and/or tokens, and a policy driven approach to security as opposed to hard coding. But it gets even more complex when establishing these best practices. XML encryption can create performance degradation which creates the need for XML appliances/accelerators. Policy driven security creates the need for tools for updating, maintaining, and auditing security policies. Which brings us to the next category…

Audit, Monitor, and Enforce Policies

Many of those who responded to my question stressed the importance of end to end monitoring and auditing for all services. It is one thing to state that the proper security is built into the architecture. It is another thing to prove it.

Architects who build security as a service need to consider the requirements from the auditing and regulatory viewpoint. We have SOX, HIPAA, PCI and many other regulations. Sometimes these regulations are in direct conflict with each other. For example, SOX requires us to store everything about all financial transactions while PCI states that we can’t store credit card numbers in the clear. Yet at the same time we have to pass credit card information to financial instructions. To accomplish this, there are all kinds of encryption and other security implications that companies will be audited for. To pass these audits, we must log the right level of information from each service call and provide a way to prove to the various auditors and regulatory bodies that we are abiding by their guidelines. It only takes one bad transaction to fail an audit.

A big challenge is that some services get used by external service consumers in ways that were not anticipated. Service consumption must be monitored proactively to identify unanticipated uses cases that fail security policies so that resolution can quickly be achieved before disastrous consequences result. At the end of the day we must ensure that the right data went to the right consumer at the right time.

What Can We Do?

Two things come to mind to help mitigate these risks. The first is to raise awareness. Invest in training and train everybody, not just the developers. Management needs a high level training session while architects, security specialists, auditors, developers, testers, business analysts, systems administrators, network engineers and others need training that is tailored to their needs.

Second, security is everybody’s responsibility, not just the responsibility of enterprise architects or the security architects. It takes a total commitment from the organization to secure the enterprise. I highly recommend companies either hire experienced SOA security personnel or hire a consultant to transfer the knowledge to the security department within the organization. In addition, I highly recommend the book Enterprise SOA written by Ramarao Kanneganti and Prasad Chodavarapu, and SOA Security by the same authors.

Dan Foody from Progress Software has a great analogy of the challenges that SOA brings from a Security perspective. Dan used the analogy of a visit to the White house to explain the different levels of security that SOA needs to address. The first level is the entering the White House. At this level you have a security guard who checks your identification, has you walk through a metal detector, and X-rays your belongings. Once inside the building, you notice the second level of security: security guards at various doors inside the White House. Additional information is required for you to enter through those doors but there is no need for the metal detector and the X-ray machine since you already cleared that. In the third level of security, your tour guide leads you to specific areas within the White House. You are not free to roam and in actuality you are being watched by eyes that you can’t see. This is a great example of the kind of security that is needed to secure an SOA. Unfortunately, some companies only have a few guards at the door.