WebServices dot org

WS-FalseSecurity: Are you at risk?

Well, I wanted to take a moment to talk about the idea of Security in an SOA world. We’ve seen some similarities in this space – particularly, that WS-Security is thought of as a means to ensure that SOA applications are actually secure in practice. We've seen from our customers that QA and IT operations teams actually do have access to test mainframes in production - to run test suites and validate that unauthorized parties can't get in. That level of rigor around access got harder to maintain when we moved to a services-based model of software -- but the security technology of some leading vendors and platforms is doing a pretty good job of validating and keeping up with WS-Security, even if it comes in several proprietary flavors in execution.

However in reality, compliance to web services standards , like WS-Security protocols, will never even come close to providing the level of security we need from enterprise applications. Most of your business logic and behaviors -- beyond ensuring the “hookup” for the services themselves is using some form of this protocol -- are happening far below the service in the functioning apps and systems of record.

These systems are owned and managed by different teams, inside and outside your domain of authority. So what is the answer? More detailed testing of the OASIS definitions of commonly encountered violations and loopholes at the WS-Security layer? Automated unit testing of security protocols is important – we do it in every engagement. However, we need to remember that a set of 100, or 10,000 different protocol checks is still just that – it is only testing for the kinds of attacks we already expect. We can set up wire fences and checkpoints, but what happens once you get past that point of entry into the application?

Take for example a Sales department that is leveraging an SOA application to collect buyer interest and respond to customer opportunities, but is not automating its own process as a secure service. Since the management insists on a spreadsheet-based process, the sales guys copy or export the customer data into a spreadsheet, send that spreadsheet all over the company, then enter orders back into the SOA application based on the results of the sales meeting and customer calls. What happens when that spreadsheet inadvertently gets attached and emailed to a supplier?

Or the IT guy who creates a handy service that scours the application for all available products and inventory, and then publishes that for a reseller to tie into their own order application. Soon word spreads, and 100 resellers are drawing data out of that service - creating a performance and availability nightmare that was perfectly authorized, but never intended.

The biggest loophole in your systems hasn’t changed. It’s still the guy in the cube next to you, or the partner on the other side of the transaction. It is the unexpected behaviors of that next service you hook up with your own. The agility of SOA – its greatest strength as an architectural model – is also its greatest weakness. It just means that there are many unintended ways the Security of your applications can be compromised, besides the misuse or improper use of the WS-Security protocols.

Real trust will not come about simply through compliance. Security in SOA will be a matter of coming to grips with the way an unknown quantity of users and other services could exploit your services in unintended ways, and how the services you depend upon can possibly compromise your carefully planned exterior when they are passing transactions through your application. That level of prevention simply can't be automated - it becomes a matter of finding the integration and interface points where you have the highest risk, and prioritizing the automation of testing there first, both at a “compliance” level and the interaction level.

Prioritizing and addressing risk is the only way to truly avoid the most risky behaviors. Of course, these concerns must be met in a timely fashion, and balanced with actually allowing customers to use the intended functionality. Good automation, and virtualization of services, reduces the time required to test while also eliminating unwanted behaviors, so end users can still get the access needed to work with your applications.

I welcome your comments and examples on this topic! We'll be posting more examples of behavioral security and how to limit the your business exposure to risk soon.

reprinted from itko.blogspot.com