Service Firewall mode

In the example of this article--the pattern is taken from the new book "Arnon Rotem-gal-oz is writing," Arnon explains how to use the service firewall to intercept incoming and outgoing messages and review them using proprietary hardware and software.

I have mentioned in security messages (secured message) and security infrastructure patterns (secured infrastructure patterns) that "messages travel through No-man's-land." When a message travels through such an area, you can use security messages or security infrastructure to protect it. But what should we do if the sender is inherently bad? When an attacker sends us a malicious message (such as a virus as a SOAP attachment), it is not materially helpful to try to make sure that the evil message that is received is intact and no one is looking at it.

Problem

To illustrate the type of attack that a malicious sender might initiate, let's take a look at one of these examples. Figure 1 Below is an XML denial of service (XDoS) attack. In this type of attack, a malicious sender attaches a large number of digital signatures to the message. Those parsers (Parser) that are not wary of this type of attack check each signature, causing the service to process at a reduced rate below normal levels.

Figure 1: Graphical Xdos attack. A malicious sender prepares an XML message that looks valid but actually carries a large number of digital signatures. The unsuspecting parser tries to validate all of these signatures, which consumes a lot of CPU clock cycles and causes the service to be unavailable.

Figure 4.4 illustrates the attack using the portal message (incoming messages), which is just one of the threats we need to deal with, and the export message (outgoing messages) is another related threat or issue that has to be addressed. At this point, we need to ensure that private or confidential information is not disclosed outside the service. In this case, we need to find a way to ensure that the recipient can only obtain information that the contract allows to flow out of the service.

How do you protect services against malicious entry messages and prevent export messages from leaking information?

One way to deal with a malicious sender is to use the security infrastructure model (see earlier in this chapter) and to require the certificate to be granted to the client. This means that a client without a certificate does not have permission to contact the system. One problem with this approach is that it works well only when the number of consumers in the service is controllable and the service is not open to the public (e.g., on the Internet). Another flaw is that certificates cannot handle internal attacks because they have been authorized to access the system.

Another trick is to use the security logic that masks malicious content as part of the business logic. This will bring a few problems. Because, for every service, there are a lot of public threats, so you'll be repeating the code. In addition, because the business logic is infected with security logic, this makes code writing and maintenance more difficult.

A better option is to extract security into another component. Now, let's take a closer look at this approach.

Solution

In any case, SOA messages are, after all, application-level components. Message concepts are neither novel nor unique to SOA. For low level OSI stack (network layer) messages, we (the computer industry) already have a lot of experience, especially TCP Packager (packer) and UDP data packets (datagram). TCP has little in common with UDP and SOA messages, and interestingly, the purpose of this model is to mitigate the threats they face together. Now that the threat is similar, we can use the same solution that was created for TCP for SOA messages.

Implement the service firewall, intercept the access messages and examine them with special hardware and software.

Figure 2 Service Firewall mode. The service firewall is between the outside world and the real service (or edge). Service firewall scans, verifies, and audits access messages. Once the message is considered problematic, it is either filtered or purified.