Wednesday | 3 December, 2008
LinuxWorld.com.au

New security threats from every which way

As virtualization, SOA and mobility projects proliferate and converge, they open the enterprise to a rash of troublesome network security problems
Deb Radcliff (Network World) 19/03/2008 10:17:28

Security for the application layer

Version and configuration controls also are big considerations for SOA, with increasingly mobile application messaging infrastructures being built on the XML-based SOAP protocol.

Web applications have been the No. 1 attack vector for the past two years. Start tying those applications together, and give them access to partner systems' back ends over a Web-services front end, and you're going to see attackers exploit this channel to get into back-end systems, consultant Janulaitis says.

As such, RedRoller and other enterprise SOA shops are finding themselves in tough spots when it comes to updating and patching. "There's no way we could provide the technology that we do to our SMB customers without our carrier partners providing access to us so we can present their pricing, peak rates and times," says Jason Ordway, CIO at RedRoller. "We had to start out with very basic, XML-based APIs, but shipping companies are moving up the chain to full-blown, enterprise-level Web services. This is great, cool and neat, but we have to change things on our side because they're sunsetting our older APIs."

Even if back-end systems were fully standards based, version controls still would be problematic, Ordway says. He describes the problem: Periodically, RedRoller's shipping and supplies partners update their systems. They might raise transaction costs, change surcharges or update service locators multiple times a year -- or in some cases, monthly -- per carrier. While new API releases are fully backward compatible, translating those updates to RedRoller's shipping applications, and then playing them forward to eBay, IBM and other connectivity partners selling the company's services is cutting deeply into the bottom line.

"With every new release we go through a compliance procedure," Ordway explains. "Soup to nuts, we walk through our existing applications, their outputs and drivers looking for interdependencies across the systems and fields of data being changed," he says.

Another security concern revolves around the parsers used in applications to translate XML into HTTP, a language universally accepted by IP firewalls. Companies using third-party parsers need to ask whether and how security hardening has been done on the parsers themselves, says Steve Orrin, director of security solutions at Intel, which offers the SOA Security Toolkit, a standards-based SOA-messaging platform that can be installed in the application server. In addition, developers need to bake security testing and hardening into their cycles.

At RedRoller, file and field encryption play big roles in protecting user and order information in databases. For transmitting SOA messages, it relies on SSL to and from its carriers and participating merchants, and through its system to the user's browser.

Orrin points to Web-application encryption standards from the Open Web Application Security Project, SOAP encryption standards and others to help build consistent encryption and authentication rules that can follow across these applications.

Gari Singh, product manager for IBM's SOA WebSphere Security Gateway products, agrees that encryption is a good best practice, and points to standards such as Security Assertion Markup Language and x.509 certificates that go along with the message to validate at the gateway. But the unintended consequences of an encrypted malicious HTTP payload getting through firewall defenses are worrisome, he says. "Now, with an encrypted message, the firewalls and [intrusion-detection systems] have no way of checking for a malicious payload going through their Web ports."

Don't forget, Singh adds, that this connection is going right back to participating partners' servers -- pathways that could be exploited through specially crafted XML messages and hacking parsers (see "Four types of emerging SOA threats," below).

Experts say federated-identity networks will be critical in managing credential-checking-request messages traversing multiple systems belonging to multiple owners in an SOA. Singh likens these networks to governance networks that will require an intermediary to handle provisioning and rights metadata.

And so the layers deepen. By 2011, IDC predicts worldwide spending for SOA-based initiatives will reach nearly US$14 billion.

Four types of emerging SOA threats

Steve Orrin, Intel's director of security solutions, has identified four types of threats and attack sectors facing an XML SOAP network. They are:

  • Payload or content threats using XML messages as the carrier. "This includes a lot of the existing Web-app attack payloads, cross-site scripting, SQL injections, request forgeries, etc."

  • XML abuse and misuse manipulating the XML protocol itself. "XPath injection is an example of using legitimate structures to do bad things, in this case using cross-site scripting in XPath messages. By injecting specifically crafted XPath, one can compromise XML documents and data resources."

  • XML-structure manipulation of XML infrastructure components. "Parsers, interpreters, processing engines - some are open source, some closed source, which are more typically targeted. These aren't often developed with security in mind."

  • SOA infrastructure attacks against content routers, authentication, Security Assertion Markup Language engines, certificate authority servers and other components. "If I can [denial-of-service] one component, I can DoS the whole infrastructure from a transactional point of view."

Additional Resources
Newsletter Subscription
Sign up for our LinuxWorld newsletters!
RSS Feeds
 
Sponsored Links