In-Depth
Ten Best Practices to Secure Web Services
As more organizations embrace Web services (which opens back-office processes to partners and the Internet), a problem is emerging: who inside the organization is in charge of Web services security?
Who’s watching your Web services? As more organizations embrace Web services, opening back-office processes to partners, and the Internet, a problem is emerging: who’s in charge of its security?
Too often, the answer is “nobody.” While Web services development mirrors application development in many ways, most developers aren’t trained in Web services security. Likewise, overseeing secure code development isn't part of a security-manager's duties. To discuss best practices for creating a Web services security-aware organization, Security Strategies spoke with Eugene Kuznetsov, chairman and chief technology officer of XML-aware device manufacturer DataPower.
What sorts of threats do Web services-using organizations face today?
It’s really a blended-threat environment. You have to worry about outsiders, transferring money between accounts … and hackers on the Internet potentially taking the service down via a denial of service attack. And I think that’s the big challenge for customers, dealing with those blended threats.
In most organizations, who helms Web services security?
The issue with Web services is it’s generally something that’s viewed as a software development problem … People generally start building it to enable a particular kind of application. Then at some point they start thinking about security, and the Web services developers … aren’t security experts, but it ends up falling to them … And often the corporate security group or IT security group views it as a threat …
So you end up in a really bad situation, because the people in charge of security are focused on shutting it down, and the people building Web services often really lack the training to do Web services security … and they’re told their Web services application can’t go live because of security. Well, what I’ve seen, again and again at large organizations, is the Web services group just puts it in anyway, without telling the security group. Or … in other cases they might get a formal waiver of corporate security practices, if they have enough political pull.
Why is it so difficult for security managers to sign off on Web services?
Part of the reason the corporate security group cannot take responsibility for Web services is the majority of tools are software-based … and integrated into the application itself which involves … writing the code, recompiling, and other things network security administrators typically don’t do.
Does there need to be a security incident to wake companies up to Web services security concerns?
I made a prediction last year … that in the next two years, there will be a major Web services security breach that will become public. It will be very different [from] the credit card theft or Web site breaches we hear about now where damage is fairly limited. With Web services, we’re giving trading partners access to the back end … We’re talking about assembly lines being stopped, new credit cards not just being canceled but set up and used for fraudulent purposes. We’re really talking about disrupting the … business processes because Web services is about … giving access to the most important processes in the business. I think something like that is going to happen, and it will be unfortunately a very bad day for the company that it happens to.
How can organizations overcome a “no one owning Web services” situation?
We recommend they address it … from a product perspective … Our XML Security Gateway … [can] understand network traffic and also … gives security groups wizards for controlling the security process … So it takes it out of the world of coding and programming and into the world of the security group—it’s an appliance, easy to manage.
Also it means if there are multiple Web services projects, they all [get security]. Most of our Fortune 500 customers have 10 or 15 Web services development projects, and if left to their own devices, each implement one or two of the 20 Web services security best practices.
How does the appliance know which Web services requests are legitimate?
One of the innovations we came up with was consuming Web services descriptors … then building a firewall to use the descriptors … In those descriptors it says what the Web Service is expecting … So we have all the valid schemas, methods, and so on. If you send in a malicious message, of course it’s not described, so we’re going to reject it. Then there are other things that are built into our products of course, things like XML denial of service prevention.
On the technology front, what are your recommendations for any organization, to better secure Web services?
There are 10 recommendations that we think are important. There are many more details in them, but [this is a start]:
- Securing the transport layer: That means using SSL or IPSec as appropriate to secure the process part of network.
- Masking internal resources: Really, making sure there’s no direct path between outside and internal services, and then hiding configurations.
- XML filtering: That’s really what an XML firewall does.
- Protecting against XML denial of service attacks: One way to do this is via XML Schema Definitions (XSD), to validate every single message.
- Validating all messages: So again with XSD it’s possible to know what a message should look like.
- Transforming all messages: The reason that’s important is even if the external or internal formats are similar, by transforming it you strip out any hidden text in there.
- Digitally sign all messages: Especially on the way out. One of the good things about digital signatures is the recipient doesn’t have to have it, it’s not like encryption … and you can always go back and prove that the message was tampered with once it left your network.
- Timestamp: Create a secure timestamp for any messages leaving the network or coming in and … with XML Digital Signatures, you have non-repudiation.
- Encrypt message fields: A lot of the time, there are parts of the data that are really, really sensitive, then the rest of the data is sensitive but maybe it’s not as much of a concern. For example, the Social Security number, password, and account number have to be protected all the time, but the rest … can just be encrypted using the transport layer … saving resources
- Implementing secure auditing: This is where you have secure audit logs for all the messages that have taken place, so … you log all the hashes of messages and … if there’s an insider attack, it will help [trace the attack].
Most of our customers are taking heed and doing these 10. Some are doing even more.
Related Articles
Case Study: Circumventing Web Services Security Problems
http://esj.com/Security/article.aspx?EditorialsID=1104
XML: A Growing Security Threat?
http://www.esj.com/news/article.aspx?EditorialsID=748
About the Author
Mathew Schwartz is a Contributing Editor for Enterprise Systems and is its Security Strategies column, as well as being a long-time contributor to the company's print publications. Mr. Schwartz is also a security and technology freelance writer.