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 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?