WS-FalseSecurity: Are you at risk?

In our previous post, we mentioned how the notion of standards in SOA can be just the opposite. This is largely because the standards are generally generated by whatever tool you are using to create services – it’s not something you construct by hand. “Compliance” is never a 100% proposition.

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.

- John Michelsen

So you have a SOA Management dashboard. How do you drive it?

Lately we've done a lot of research and publishing on how Dev & QA teams can ensure better quality throughout the software development and release lifecycle. But what about the IT Operations guys? It seems we are encountering a disconnect between the Enterprise Architecture and Integration disciplines that are moving to SOA, and the people who need to monitor and maintain these systems in deployment. There are a lot of companies starting to focus on better SOA Governance, which includes the management of business processes and workflows, and the services and applications behind that. Great stuff happening on that side of the IT shop. However, often the actual running applications are still in the purview of IT Operations teams. Don't get me wrong, it is a great thing that we have a team that is manning Mission Control -- hopefully providing an impartial report and monitoring function that is crucial, when you have live customers depending upon these apps in deployment. And there are mature tools out there that provide this kind of live "dashboard" of how the implemented apps are performing, like TIBCO Hawk, HP OpenView, IBM Tivoli, CA/Wily, etc. So why would these IT Operations teams be interested in SOA testing and validation? Well, it's really about "causing the cause" of performance and latency issues in these systems. If you are trying to prove that live SOA infrastructures are ready to roll, it's not enough to sit and watch the dashboard for that "Check Engine" warning light when a condition is caused by too many customers using those apps. The point I'm making is to use automated Test Execution as a way to drive expected and unexpected behaviors into your SOA Monitoring dashboards. This can be done both at integration time in staging, and against live applications, if you can provide a test window of time to make this process happen. For instance, we recently worked with a large energy industry customer who wanted to prove that their live implementation was able to handle a realistic profile of varied transactions in their system. So instead of waiting for a rush, they manufactured one -- by executing automated test transactions into the system, and monitoring the performance results within their Operations dashboards. Then they could feed the same data out to their SOA Testing platforms to tell the tests if they performed according to service levels. We recently put out a little news on this kind of integration - it's a pretty exciting way to apply Test & Validation to the Monitoring applications that have been around and evolving for some time: http://www.itko.com/site/company/news_65.jsp To me, that is a better machine - and it takes away a lot of that disconnect between Development and Integration teams, and the Operations people who are ultimately answerable for customer service levels.

The Continuous 'C'

Several weeks back I gave you a real life experience that typified why our test strategy we call the Three C’s has Complete as one of those C’s. This blog will give you a different real-life experience on why Continuous deserves “C” status. I was meeting with a Director of development at one of the worlds largest financial institutions. Many of their trading applications have absurd levels of complexity and variability along with, of course, radical performance expectations. Really cool stuff. A certain critical service was running on a major SOA platform. The vendor released an update to that platform, and the team responsible for this service ran their unit and service level tests -- doing more than most teams I’ve seen. Turns out, they all passed, and in fact the service performed its main function 12 milliseconds faster -- COOL! Then again, maybe not. They deployed the patch and watched their entire currency trading system grind to a near halt! Wait, you sped up the service and slowed down an application? Yes. Turns out the performance of the service prevented timing issues in the orchestration layer from surfacing in use by an application. Of course it wasn’t obvious to the team that this was in fact the issue -- they were blaming the vendor, then their new code changes looking for how they could have wrecked the performance. They went on for days losing millions until they figured out what was really happening. The Continuous C solves for this type of problem. Take those same tests you would automate at the orchestration and solution levels and run them on a continuous basis at those points of integration, pre-production. You’ll get immediate notice of this type of issue along with much clearer identification of the root cause.

European SOA: Ahead of the Curve?

I'm in Germany right now, looking forward to a session at ZapThink's Practical SOA in Frankfurt event tomorrow. I'll be joining some peers from companies like T-Mobile, Swisscom, Novartis and SwissLife who are going to be sharing their own SOA success stories. Why does SOA seem to be moving forward a little faster in Europe than in North America? We've posed these kinds of questions in our surveys and forums, and often it seems that stateside, the term "SOA" can polarize some IT teams - it's an "either/or" decision at the architectural level. Talking to our EMEA director, Wilfred, he says part of the reason it seems adoption is high in Europe is that it SOA is often driven by developers working in smaller teams. Service-orientation can be started on a much smaller scale, and tested pragmatically before rollout to the larger organization. So, SOA there doesn't need to be an enterprise-level initiative in all cases, it can be something the company dabbles in before making a full commitment. The upside of this pragmatic approach is that the SOA project can leverage some small wins to pay for a bigger commitment. The downside? Companies still need to beware of publishing services without a higher level of architectural coordination between teams. This isn't to say that there aren't also companies in Europe starting from a strong enterprise architecture perspective and defining a top-down approach to SOA. I look forward to meeting both the pragmatists and the strategists this week! John