Overcoming SOA Insecurity - Software Development Times On The Web

Overcoming SOA Insecurity
Experts say defend on many fronts, audit continually, hold partners accountable
By Jennifer deJong

January 15, 2008 — Talk about insecurity.

SOA applications, more often than not, run over a wire that millions of people access every day.

They are likely to include services that originate outside company walls—and, as a result, can’t be completely reigned in.

To make matters worse, SOA apps are moving targets, made up of services that couple and decouple as needed, said Andrew Brown, director of product management for SOA governance tool maker AmberPoint. “How services are wired together today is not how they will be wired together tomorrow.” That adds up to one thing, he said: “When you deploy SOA, you are deploying a new form of insecurity.”

SOA makes the security challenge radically more complex, added Roger Thornton, co-founder and chief technology officer for application security tool maker Fortify. “When services connect, you have to ask: Are you really who you say you are? Is anyone eavesdropping? Intercepting the message? Changing it?”

Security outfits and other experts interviewed by SD Times said IT organizations should attack the SOA security problem on many fronts. They need to specify which components can talk to each other, at what times, and which rules (such as data encryption) govern that conversation. They also need to hold partners accountable for strong security measures, and ensure the integrity of the code itself, subjecting it to simulated attacks, and some source code analysis. Finally, architects and developers should design the SOA infrastructure and the services themselves with security in mind, keeping crucial data—such as credit card numbers—far from the vulnerable front line.

Here’s a list of best practices for accomplishing those goals.

Deal with identity management. Determine who is looking at what and what permissions have been applied, said Danny Allan, director of security research for security tool maker Watchfire, which IBM acquired in 2007. “That is front-of-mind for SOA security.” The key is managing the identities of the services as well as those of individuals. IT organizations are accustomed to authenticating and authorizing end users, but they are not as adept at applying those policies to machine-to-machine communication, said Adam Michelson, technical architect for Boston-based consultancy Optaros. “When you look at [a company’s] LDAP directory, there is a long list of end users, and only one [listing] for business-to-business communication,” he said, referring to Lightweight Directory Access Protocol, for querying and modifying directory services such as those used for authentication.

SOA allows IT organizations to externalize identity management outside of the application, said ZapThink analyst Ron Schmelzer. That eases the problem, but it’s not a one-size-fits-all solution, he noted. “You have to specify details for each user or service,” he said, offering an example of an online merchant. “You can see this [inventory] data, but you can’t get at the credit card authorization service.”

That is sometimes trickier than it sounds, added Dan Foody, a vice president for Progress Actional, which sells SOA governance tools and other offerings. For instance, a computer repair application needs access to a service that contains customer data to find out what equipment is installed at the customer site. “You want the reps that use the repair app to see the equipment list, but not the customer’s credit or billing history,” he said. “But if you’re not careful, they can get at every piece of information about that customer.”

Tame the XML beast. SOA is based on Web services, which use XML to communicate, explained analyst Schmelzer. Because the markup language is text-based, the body of the message must be encrypted, he noted. Also presenting a challenge are XML injections, a variant of a SQL injection, where a hacker inserts a query into the code to call data that is meant to be off limits. “XML has to be parsed to make sure hackers haven’t injected malicious requests,“ he said.

Look out for denial-of-service attacks. Keep an eye on unusual traffic, said Michelson. “If you see 10 SOAP [digital] signatures come over the wire in a row, it’s probably a denial-of-service attack.” There’s no need to monitor traffic by hand, he said. “You can audit services for [such attacks] by writing that into a policy.” A denial-of-service attack attempts to shut down an application by sending it more traffic that it can handle.

Write the rules and apply them. Because SOA is based on a hub-and-spoke model of communication, which relies on a central request broker, it is easy to apply rules pertaining to digital certificates (which prove a person is who he says he is), encryption, digital signatures (evidence a message has not been tampered with), service levels and a host of other issues, Michelson said, “so do it.” Others agreed. “Someone building a service and making it available to 18 different constituencies must understand how each will use my service,” added Thornton. “I have to deliver the right data at the right time, with the right service levels.” This process of writing rules and applying them can become extremely complex, added Foody. “But if you keep it too simple, you are losing the benefits of SOA,” he said.

Provide a library of reusable components. SOA is all about reuse. To promote efficiency, give service creators access to pre-certified components that ease the job of developing services and composing an application, said Allan. This is particularly true for security services common to all SOA apps, he added. “Developers shouldn’t [waste time] worrying about things like authorization and access control.” Agreeing with Allan was Michael Sutton, security evangelist for application security tool maker SPI Dynamics, which was acquired by Hewlett-Packard in mid-2007. No one builds an application from scratch anymore, he claimed. “If you need a piece of functionality, someone has already produced it.”

Design services with a clean separation. The best architectural approach for SOA is triple-tiered, said Michelson: user interface on top, with services and data tiers below. “Don’t allow an outside audience to link to the second or third tiers,” he counseled. Sensitive services such as those that access customer credit card numbers belong in the third tier, far from the front line.

Conduct source code analysis sparingly. Auditing source code for vulnerabilities a hacker could exploit is never a bad idea. “It’s hard to argue against it,” said Michelson, but it can eat up a lot of time and deliver only diminishing returns. One approach is to pick one service and look through its source code, he noted. Another, said Mandeep Khera, vice president of marketing for application security tool maker Cenzic, is to consider SOA projects in the context of the company’s larger security priorities. “The enterprise has 100 applications,” he explained, but only “two are SOA. Look at the big picture. Prioritize the top 10.”

Break your system before someone else does. Conduct penetration testing on individual services as soon as they are created, looking for things such as whether user input is validated properly, said Allan. “Then collectively test the entire SOA.” Penetration testing pinpoints vulnerabilities by simulating hacker attacks.

Increase security around transactions. Don’t dump files with key customer data to an FTP server, said Michelson. That advice sounds obvious, but “boatloads of orders” are still handled that way, he said. “There’s no security when you are doing it in batch. And [hackers] love finding an FTP server.”

Agree on core standards with business partners. A travel Web site sells airline tickets. Its partner sites rent cars. But how does a company manage user identities in a way that it is meaningful to its partners? asked Schmelzer. “This is known as ‘identity propagation,’ where all participants know who the end user is.” Standards such as WS-Federation and Liberty Alliance help manage this problem, he admitted. “But that doesn’t mean everyone has implemented them,” so it’s imperative for all parties to meet face-to-face and agree on which standard to implement.

Keep partners accountable for the security of their services. How do you know that a partner’s service—a component in your company’s SOA—is secure? “People tend to test their piece but not their neighbor’s piece,” said SPI’s Sutton. There are a couple of solutions, said Watchfire’s Allan: Ask for proof that the component has been tested for security, and write it into a contractual agreement; or ask permission to test the component yourself. “It’s a warning sign if they say no.”

Keep on testing: SOAs are moving targets. To ensure security, you have to audit on an ongoing basis, said Allan. “There are a dozen things that could go wrong.” Is input validation working correctly? Is the system doing identity management correctly? “It’s a mistake to test for all of the problems at once,” he said.

A key thing to check for is how the SOA is using third-party components, and whether those components are functioning properly, said ZapThink’s Schmelzer. “Take down one key service, [and] you can take down [the entire app],” he noted. “Can you imagine what would happen if Google Maps went down? How many applications would I kill?” In the past, that would have been a problem for only Google, he noted, but with SOA, the impact is so much wider. “The greatest benefit of SOA—[the ability to share services]—is also the greatest problem of SOA.”

EMAIL THIS ARTICLE

SEND FEEDBACK

MORE SPECIAL REPORTS

SUBSCRIBE TODAY!

E-Newsletters:
  News on Mon/Thurs.
  Test & QA Report
  EclipseSource

SUBMIT

JOB BOARD

PDF & PRINT EDITION

* Requires Resource Account! LOGIN or SIGN UP

* Download Current Issue!
ISSUE 8/15/2008 PDF

* Need Back Issues?
DOWNLOAD HERE

Receive The Print Edition?
SUBSCRIBE HERE

EVENTS CALENDAR

Business of Software 2008
9/3/2008 to 9/4/2008
Boston
Red Gate Software

VSLive New York
9/7/2008 to 9/10/2008
New York City
1105 Media

Interop New York
9/15/2008 to 9/19/2008
New York
TechWeb

VMworld 2008
9/15/2008 to 9/18/2008
Las Vegas
VMware

Mobile Business Expo
9/16/2008 to 9/19/2008
New York City
TechWeb

MORE EVENTS

GET NOTIFIED!
About all of the latest Resources

SD TIMES 100

6th Annual SD Times 100

It's time once again to
recognize the organizations
or individuals that have
demonstrated leadership in
their markets.

HOME SITE MAP RSS CURRENT ISSUE BACK ISSUES SUBSCRIBER SERVICES ABOUT US CONTACT US BZ MEDIA