In Part 1 of this series (see Resources), I mentioned access and response time as two of the Web services features that should be tested before a service is made public. In Part 3 (see Resources), I showed how to develop system interruption thresholds as a way of improving your Web services' chances of meeting the service-level agreement (SLA) guarantee for uptime availability of the resources that the SOA players consume and produce dynamically. In this article, I expand these topics to include vulnerability and show how it is a related and important issue.
In Part 4 (see Resources), I explained how enterprises can put their security administration in a centralized location to better control the access control lists (ACLs) for multiple Web services and their associated services and applications in SOA. Securing Web services with ACLs, however, does not mitigate the risk of exposing Web services (and non-Web services) vulnerabilities to a malicious attack.
In this article, I talk about what information you should have on mitigating the risk of exploiting vulnerabilities with a SLA by, in part, considering three request/response pair types: transversal, vulnerability probe, and remediation. I cover how a large gap or an accumulation of numerous small gaps between the time a Web service's request or response was interrupted and the time it resumed to complete a round trip could adversely impact guaranteed uptime availability. Narrowing time gaps is important as Web services are designed to interact with one another and with non-Web services in SOA to complete the tasks of providing the information with minimal or no interruptions.
To make sure the vulnerability information you would request is the correct data, you need to assess vulnerabilities in three simple steps. The first step is to identify critical system assets -- intangible or tangible -- that are vulnerable to malicious attacks.
A tangible asset is an object you can see, feel or touch. Some examples include an IBM® Thinkpad® R Series and a Websphere® Studio system administrator. An intangible asset is an object you cannot see, feel, or touch but has an added value to the tangible object; for example, the response times to a client's queries as an added value to a WebSphere Application Server.
The second step is to identify vulnerabilities that a hacker or attacker could maliciously exploit. The third step is to provide remedies including putting safeguards in place to mitigate the risks of exploiting vulnerabilities or fixing them.
One way of mitigating the risks is to use AVDL (see Resources) or another description language in the XML format to get information on how previously known vulnerabilities were identified and how anticipated vulnerabilities against the application's components should be handled. Examples include OS type/version, Web server type, and database type.
Another way is to get information through AVDL about application legitimate usage schemes that might or might not result in an exploited vulnerability. Examples include directory structures, HTML structures, and legal entry points.
The difference between the time a request for the information was initiated and the time a response to the request was sent could spell the difference between saving or not saving the enterprise from a complete denial of service (DoS) or destruction of critical system assets. If the time gap is large, interruption thresholds can reach the level at which they can cause an adverse impact on the uptime availability guarantee.
It's far cheaper to identify vulnerabilities and put in place cost-effective safeguards, such as a disaster recovery plan and a daily backup system, than to recover from an enterprise-wide DOS or destruction of critical system assets. Trading partners should receive vulnerability and legitimate usage information in a timely manner with very little or no interruptions.
One way to protect Web services from malicious interruptions is to include information in a Web service on vulnerability assessment tools, application security gateways, reporting tools, correlation systems, and remediation tools. You can accomplish this with AVDL. The specification does not cover network layer vulnerability information such as network topology, TCP-related attacks, or other network layer issues. It does not discuss any information about authentication or access control, as these issues are covered by Security Assertion Markup Language (SAML) and eXtensible Access Control Markup Language (XACML) (see Resources).
AVDL does not currently address the issues of including information on interruption thresholds for each response type. For this reason, I have modified the concepts of transversal containers, vulnerability probes, and remediation, as discussed in the AVDL specification in order to address these issues. I group vulnerability responses into three types:
- Vulnerability transversal containers
- Vulnerability probe containers
- Vulnerability remediation containers
Any prolonged interruption in a round trip that a Web service takes to send a request and receive a response is of concern. One reason is that it might result in significant interruption thresholds that could impact the SLA guarantee.
I have observed how downloading a large batch of remedy files for an application has been interrupted numerous times due to some network problems. I was not able to use the application without the fixes (for example, firewall protocols) that I required. Luckily, the vendor wisely put a mechanism in its software to affix a temporary resumption point to the batch where the interruption occurred.
This way I was able to restart the download at the resumption point, not at the beginning. After the downloading completed its run, the firewall component of the application was working properly. The interruption threshold for this incident was significant.
Let's take a look at three containers, each of which is associated with a response type that you could use in describing application security vulnerability in a Web service.
The vulnerability transversal container is simply a view of the request and response pair in a round trip over the HTTP. It's a map showing where the request and response went in the SOA. You cannot have more than one pair inside the container. This means you cannot have more than one map for each container. As shown in Figure 1, you can have several containers to complete a series of tasks in one session while in the SOA.
Figure 1. Simple session
I am talking about one session behind the screen, not while you face the screen. You can have what I call one human-facing session while multiple sessions behind the screen are needed to complete the task of providing the information on mitigating the risks of vulnerabilities. You can have several requests and responses for each page of Web application.
The number of containers needed for a page to complete all tasks depends on the complexity and content of the page. You need to include information about what the policy is for determining interruption thresholds for vulnerability transversals as significant or insignificant. I recommend that a log be created to record the time the transveral was interrupted, the time the resumption took place, the number of times each interruption occurred, and the resulting interruption thresholds.
Each vulnerability probe container describes a single vulnerability of the Web application. Like the traversal container session, a vulnerability probe session might contain multiple containers, each of which consists of only one request-response pair needed to complete a round trip.
The probe container takes one step further than the traversal container (see Figure 2). A probe session consists of two hierarchical levels of containers, as contrasted to a transversal session consisting of only one hierarchical level of containers. This means the probe session might encompass multiple protocols, each of which contains its own request/response pair.
Figure 2. Two-hierarchy session
You also need to include information about what the policy is for determining interruption thresholds for vulnerability probes as significant or insignificant. A log on probe interruption thresholds could be combined with a log on traversal interruption thresholds.
Remediation includes a safeguard that, when it is in place, is used to close the vulnerability. In XML, the remedy is assigned a safeguard code specific to a remedy. It includes an open block in which a remedy can be hard-coded in machine language. If the remedy is anticipated to be very long, the alternative is to include information about where the remedy can be downloaded to fix the vulnerability.
The issue with the remediation container is that when numerous patches are being downloaded in a sequence, there is always a possibility of being interrupted due to some network problems with a request/response pair in one or more containers. While there is a mechanism for affixing a resumption point where the interruption occurred during the download, there are no mechanisms for logging-in the time the interruption occurred, the time the resumption took place, and how many times download interruptions occurred.
We need to establish a policy on determining interruption thresholds for remediation downloads as significant or insignificant. Such a log could be combined with those for tracking interruptions in the traversal, probe, and remediation trips and calculating interruption thesholds. I recommend that this log include other variables I mentioned in my articles in the series on SLA guarantee (see Resources).
Mitigating the risk of exploiting Web services vulnerabilities in a heterogeneous SOA requires planning ahead to resolve the problems with request/response interruptions that could occur while vulnerability and remedy information is either transmitted or downloaded. Developers should communicate with security or vulnerability specialists on the issues of specifying interruption thresholds at acceptable levels in a SLA.
- Get information on how to use SLAs in a Web services context from the other papers in this series:
- "Guarantee your Web service with a SLA" (developerWorks, April 2002)
- "Guarantee second-generation Web services applications with a SLA" (developerWorks, August 2004)
- "Integrate Web services into EAI with a SLA guarantee" (developerWorks, October 2004)
- "Secure multiple Web services with a SLA guarantee" (developerWorks, November 2004)
- "Firewall Web services with a SLA guarantee" (developerWorks, December 2004)
- "Localize Web services with a SLA guarantee" (developerWorks, January 2005)
- Need assistance with SAML and XAMCL? Go to OASIS' Web site to take a look.
- Want to know more about AVDL as a standard way of describing application security vulnerabilities using XML? Go to OASIS' Web site to find out more.
- Read Judith M. Myerson's The Complete Book of Middleware, which focuses on the essential principles and priorities of system design and emphasizes the new requirements brought forward by the rise of e-commerce and distributed integrated systems.
- Get the business insight and the technical know-how to ensure successful systems integration by reading Enterprise Systems Integration, Second Edition.
- Publish your Web service or application in IBM's UDDI version 2 registry, which features a graphical user interface and conformant APIs for public use.
- Go into the nuts and bolts of developing a service-level agreement in this IBM Redbook for Domino administrators.
- Browse for books on these and other technical topics.
- Want more? The developerWorks SOA and Web services zone hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.
Judith M. Myerson is a systems architect and engineer. Her areas of interest include middleware technologies, enterprise-wide systems, database technologies, application development, network management, security, and project management. You can contact her at jmyerson@bellatlantic.net.
