Skip to main content

Intermediate SOA Security Questions


SOA security is getting more attention.  Recent document leaks show the need of inside-the-network security, and recent attacks on service providers by Wikileaks supporting hacker-nets show the need for AT LEAST “decent” SOA security.  As ZapThink wrote recently

If you’ve been even peripherally paying attention to the news lately, then you know about Wikileaks and the battle going on between supporters and opponents of the group. While you might think that these incidents have nothing to do with you, enterprise architect, IT manager, developer, vendor, or consultant at a private company or government institution, they most certainly do. You are about to become a part of the frontline in the Cyberwar battle…

Just as firms plan for server outages and deployment problems, now every firm must have a contingency plan to deal with the potential outage of their most important online suppliers…

Your company uses Google for mail, a specialty Software-as-a-Service (SaaS) supplier for its B2B network that just happens to use Amazon’s cloud computing infrastructure, and processes its online payments with an Internet-based credit card gateway. The first thing that the company notices is that it can’t process payments because the credit card processor is under siege. Then, its B2B network goes down because Amazon is under attack. Finally, you can’t even send requests for support to either the card processor or the B2B network because Gmail is down due to a distributed denial of service attack (DDOS). At this point, the company is effectively knocked off the net from a business standpoint, even if its own website is up and operational.

For just how many hours can you afford to be disconnected as collateral damage in a Cyberwar? You say you have no contingency plans to deal with direct or consequential damage from malicious attacks? Then you are due for a Cyberwar Crisis Point…

The more interconnected you are and dependent on third-parties for your IT capabilities, the more threatened you will be by these attacks. Disconnecting yourself from your suppliers and the Internet is not an option these days.

If you’re Service Oriented, your applications are exposing more and more services inside your network and connecting more and more to services outside the network.  If you are actually working with Service Oriented Architecture, the whole model of your business process interaction is cooperating services.

All this means is that a Service Security Layer is critical as the IT threats have increased significantly.  Along these lines I’m sending some vendors some questions, to understand how their products can offer at least BASIC and hopefully some INTERMEDIATE level SOA security capabilities that can be directly plugged into the average IT site…

Basic High Level SOA Security Questions for Vendors:

[ Basic means this is the average security the average IT shop should have.  If you are dealing with financial transactions or sensitive data, more than this is appropriate.  High level means these are approach and toolset questions, not a long list of details of particular protocols supported.  You should always ask your vendors what protocols and methodologies are supported and verify they match your CURRENT requirements and show good possibilities of covering FUTURE requirements. ]

Vendor, security is an integral part of today's SOA and ESB environments.  These questions are to understand how or what part of your SOA products or suite provides features for an average SOA security model, and how.

Here's what I mean by an average SOA security model:

1. Triple-A.

Authenticate - All incoming service requests, regardless of protocol (HTTP, FTP, MQ, SMTP, etc) have the source of the request authenticated.

Authorize - Validate that the requesting source is permitted to operate the service being requested against a source list of services and authorized requestors.

Audit – Appropriate information on the servicer request is captured and stored for later forensic or debugging research.  Management of the audit contents should be automatic and tightly restricted (meaning scheduled archiving and purging).

Question : Which tools do you provide that offer these required abilities?

Question : Which features (protocols, tools) do your tools offer for these abilities?

2. User context and integration with identity management tools.

It's often not feasible to synchronize security between the front end user presentation tools and the back end servicing systems.  Sometimes this is because federated identity may not be in place, other times because attempting to map actual users against each service exposing business process steps or even IT utility functions is just not reasonable.  Regardless, the ability to accept an actual User ID and pass it along as part of the service request remains a key features, to allow back end systems to trace activity back to the user initiating the action.

In environments using identity management tools, the user context may be represented as only a session token, and to store the actual user information for auditing requires querying an identity management service with the session token.

Question : Which tools and to what level of ability do they do this (versus requiring development of a unique service to do so)?

Question : With what enterprise security environment and IDM tools do your SOA security tools integrate?

 

3. Validations and Prevention.

The general assumption is that the ESB and services are not going to come under attack from inside the network.  However, recent document leaks have demonstrated to many customers that internal security is important as well.  Further, many service problems often involve programming errors on service request content and occasional placement of completely inappropriate data types.

Therefore we often require products offer schema validation ability at each step of the service (meaning the ESB should validate and the providing system should also validate – for it can't guarantee a request will arrive only from the ESB).  Similarly the ability to offer some level of attack prevention even inside the internal network is appropriate.  While it may seem unlikely an internal service is going to come under a DNS attack, we've seen this happen in production not due to an intentional DNS attack but due to a programming error looping a service call tens-of-thousands of times against a providing system.

Question : Which of your tools can do this?

Question : What protections and validations do they offer?

Question : How's the performance (or rather what's the performance impact)? [ It's understood if this is done on the servers as opposed to within an XML appliance the CPU impact can be significant. ]

 

4. All the above apply to each step of a service path.  Every exposed service needs to be secured, validate the requestor, log the request, and validate the safety of the request. 

Question : How do your security tools provide these abilities to every service being exposed?

Question :  Any technology limitations on where your tools can provide such abilities?

Question :  Which of your tools are required?

 

5. External Service Exposure.

Customers are more and more needing the ability to expose services outside the internal network.  Further, I'm writing this article in Israel, which is a major target for hacking attacks for ideological reasons.  So I'd like to understand the various models for securely and safely exposing web services to external customers using SOA tools.


Question : Are XML Appliance/Firewall products part of your product offerings or integration with other vendor's appliances?

Question : Please explain the interface and management of the relationship between your SOA (ESB or Security or Governance) tools and the Appliance/Firewalls.  (Meaning can I publish and operate all from 1 console or do I need to put it in a Design Time Governance or Policy Tool, push it into an ESB, then export it to an Appliance and go into the appliance management console to complete the process?

Question : Some customers are looking for a less expensive method than installing multiple XML appliances (primary, failover, disaster recovery, etc.)  Is there a secure software model using your tools for doing this?  (Perhaps, for example, installing an instance of your ESB in the DMZ and creating a secure channel to an internal instance of the ESB?)  What, how, how secure, and what additional modules or products are required to do this?

Popular posts from this blog

Integration Spaghetti™

  I’ve been using the term Integration Spaghetti™ for the past 9 years or so to describe what happens as systems connectivity increases and increases to the point of … unmanageability, indeterminate impact, or just generally a big mess.  A standard line of mine is “moving from spaghetti code to spaghetti connections is not an improvement”. (A standard “point to point connection mess” slide, by enterprise architect Jerry Foster from 2001.) In the past few days I’ve been meeting with a series of IT managers at a large customer and have come up with a revised definition for Integration Spaghetti™ : Integration Spaghetti™ is when the connectivity to/from an application is so complex that everyone is afraid of touching it.  An application with such spaghetti becomes nearly impossible to replace.  Estimates of change impact to the application are frequently wrong by orders of magnitude.  Interruption in the integration functioning are always a major disaster – both in terms of th

Solving Integration Chaos - Past Approaches

A U.S. Fortune 50's systems interconnect map for 1 division, "core systems only". Integration patterns began changing 15 years ago. Several early attempts were made to solve the increasing problem of the widening need for integration… Enterprise Java Beans (J2EE / EJB's) attempted to make independent callable codelets. Coupling was too tight, the technology too platform specific. Remote Method Invocation (Java / RMI) attempted to make anything independently callable, but again was too platform specific and a very tightly coupled protocol. Similarly on the Microsoft side, DCOM & COM+ attempted to make anything independently and remotely callable. However, as with RMI the approach was extremely platform and vendor specific, and very tightly coupled. MQ created a reliable independent messaging paradigm, but the cost and complexity of operation made it prohibitive for most projects and all but the largest of Enterprise IT shops which could devote a focused technology

From Spaghetti Code to Spaghetti Connections

Twenty five years ago my boss handed me the primary billing program and described a series of new features needed. The program was about 4 years old and had been worked on by 5 different programmers. It had an original design model, but between all the modifications, bug fixes, patches and quick new features thrown in, the original design pattern was impossible to discern. Any pattern was impossible to discern. It had become, to quote what’s titled the most common architecture pattern of today, ‘a big ball of mud’. After studying the program for several days, I informed my boss the program was untouchable. The effort to make anything more than a minor adjustment carried such a risk, as the impact could only be guessed at, that it was easier and less risky to rewrite it from scratch. If they had considered the future impact, they never would have let a key program degenerate that way. They would have invested the extra effort to maintain it’s design, document it property, and consider