Secure Tracer Strategy

Problems

Audit control and compliance requirements always expect a good collection of transaction logging information. Sometimes a copy of the SOAP messages may be retained so that raw data can be available for complicated security analysis and reporting when needed. In practice, too much data may not be helpful if administrators need to find out whether there is any suspicious identity theft from signs of identity spoofing or man-in-the-middle attacks. Further, many security audit reports do not correlate the business transactions into sender/recipient pairs or provide the flexibility to apply specific security processing rules, such as a recipient's message timestamp should be later than the sender's message timestamp.

If the sender and the recipient are operating on different platforms, the security reporting and tracing of suspicious business transactions are more complicated because administrators need to collate the service requester and the response messages together to correlate them. If the business data are encrypted, administrators are not able to scan and trace raw data manually. They need to rely on some tools to identify whether there are any sender's or recipient's messages that have invalid user credentials, such as invalid X.509 certificates, or suspicious message timestamp, for example, recipient's message timestamp is earlier than sender's message timestamp, which may suggest a message alteration or spoofing.

The Secure Tracer strategy is intended to address the challenge of tracing business transactions for suspicious activities. It allows administrators to correlate the sender's and recipient's messages in pairs and applies some security processing rules to identify any suspicious messages or to trace the source details from the central logging repository.

Solution

The Secure Tracer Strategy applies to both synchronous, asynchronous, and bridge interoperability strategies that utilize Web services. It intercepts service requests and replies in SOAP messages (whether synchronous or asynchronous) and correlates them in pairs. This also includes bridge strategy that supports Web services. In either strategy, a central logging mechanism needs to be in place.

The secure tracer strategy depends on a central logging mechanism to pull both the sender and the recipient log messages together. This can be implemented by a variety of middleware such as a basic file transfer facility, ftp, for example, or ESB.

Once the central logging mechanism is implemented, a simple message matching application can be built to correlate the sender and the recipient messages that refer to the same service request together. Figure 13-8 depicts a sequence diagram that illustrates a secure tracer strategy.

Figure 13-8. Secure Tracer sequence diagram

• Administrators start secure tracing activities (Step 1).

• Upon sending the service request (Step 2), the Sender issues a log message to the central logging system (Step 3).

• Central Logging creates a message correlation identifier for easy identification and mapping of the service request and the corresponding reply messages (Step 4).

• Upon completion of processing the service request (Step 5), the Recipient issues a log message to the central logging system (Step 6).

• The central logging system correlates the sender's message with the recipient's message by message id, message timestamp, and reference and creates a grouping between the two (Step 7).

• The central logging system also applies some security processing rules to ensure the message is authentic and genuine (Step 8). For example, it verifies the digital signature of both the sender's and recipient's messages and checks whether the recipient's timestamp is earlier than the sender's timestamp.

• Suspicious messages are flagged for administrator's attention by putting these messages under the alert queue (Step 9). Optionally, the central logging system should notify the administrator by e-mail or other predefined communication mechanism (such as fax or instant messaging).

Example

Figure 13-9 shows WSE Trace Tool (downloadable from www.gotdotnet.com/workspaces/workspace.aspx?id=ab938e2f-cabf-4145-b0e9-dbeeaf51dbe5), which correlates the incoming service request message with the outgoing reply message. It is not an implementation of the secure tracer strategy, but it illustrates a good example of correlating the service request and reply messages for manual inspection.

Figure 13-9. WSE Trace tool correlates the service requester and the response messages together.

Benefits and Limitations

Secure tracer strategy is a simple audit log reporting function that is intended to address basic security auditing, such as track and trace the secure transactions, and compliance requirements. It has the following benefits:

Support Compliance Requirements

With the changing requirements of local compliance, it is crucial to provide a secure tracing capability to meet audit control and compliance needs.

Proactive Reporting of Suspicious Activities

The capability to identify suspicious messages that may have been tampered with or to scan for any problematic digital signature in the messages can allow suspicious or potential security vulnerabilities to be detected proactively.

Limitations

The extensibility of the secure tracer implementation depends on the central logging mechanism and the processing logic for the message correlation. Not all messages can be correlated. For example, the secure tracer implementation has no clue how to correlate a collection of encrypted SOAP messages, given that the message identifiers and message digest do not show any correspondence.