Secure Delivery of a Payload via a Protocol Break

A secure information exchange consists of two distinct elements: the information you need to convey – the payload, and the technical method used to carry the payload – the protocol. Attackers wishing to break into your network can exploit either of these: the protocol or the payload.

In this blog, we briefly look at protecting protocol-based attacks. In a future blog, we will look at content-based (payload) attacks.

The most secure mechanism to protect protocol-based attacks is called the “Protocol Break”.

Protocol Break.

The concept is simple…

• Rather than allowing a protocol exchange directly between System A and System B, we insert a “Catcher”, often referred to as a proxy (C in the diagram).
• To System A, the Catcher looks like it is System B. So System A communicates with the Catcher quite happily.
• The Catcher extracts the payload and passes the payload to another system – the Thrower (T in the diagram).
• The Thrower then talks to System B.
• As far as System B is concerned it is getting information from System A.

The attackers may well use their tool craft to break into our Catcher. From here they can certainly interfere with the payload (‘Securing the Payload’ is the subject of a future blog), or use the Catcher as a launch pad to attack the Thrower.

There are two core techniques for preventing the Catcher from being a launchpad to attack the Thrower depending upon communication mode. The blog Diodes are Diodes, Guards are Guards describes different communication modes, if the information flow in one direction only, then data diodes can be used. The White Paper Protecting confidential information using Data Diodes explores the role of the Protocol Break in this scenario in much more depth.

Where genuine two-way communications are needed, a robust approach to the design of the Catcher / Thrower are needed – this is where Data Guards are a vital tool. This is also however, where the story gets more complex. Invariably a two-way communication requires elements of protocol to be shared between the Catcher and Thrower to enable the seamless interoperability between System A and System B. In these scenarios, the Catcher can encapsulate the required elements of protocol in meta-data passed with the payload. The Thrower then recreates the needed elements of protocol in its communication with System B. The astute reader will observe we may have lost some of the elements of the Protocol Break concept here – we can mitigate this with protection mechanisms on the payload.

While the initial concept is simple, once you get into the detail it can get complex very quickly. You should consider engaging with experts that can help understand your exact situation and advise on the right solution for your situation, and not just product vendors.

Validating the Payload

The information you need to convey – the payload, and the technical method used to carry the payload – the protocol. Attackers wishing to break into your network can exploit either of these: the protocol or the payload.

The previous blog looked at protecting protocol-based attacks. In this blog, we look at content-based attacks – on the payload.

The Attack Vector

The principle behind a content-based attack is that when delivered, the payload contains malware that will cause the end system to do something unexpected, which the attacker can take advantage of – usually to gain access.

The most common and effective technical mitigations are:

• Patching – to ensure your applications have known vulnerabilities removed
• Anti-Virus – to detect known malware

(Aside: This is why these two mitigations are fundamental to the UK Governments baseline security standard, Cyber Essentials)

However, both of these mitigations have one thing in common, they work on known problems. The skilled attacker that really wants to get you will exploit an unknown problem – the so called Zero-Day.

Threat Reduction

To reduce this threat we can use the following techniques, first described in the White Paper Protecting confidential information using Data Diodes and which explores these concepts in much more depth.

1. Accept the risk. Patching / Anti-Virus may be sufficient for the threat you face.
2. Do a very strict pattern matching on the payload, only accepting payloads recognised to be conformant (i.e. whitelisting). For example, only accept “text” files with 7bit ASCII characters in it. More advanced scenarios will perform strict schema checking on the file to ensure it conforms to an expected set of rules.
3. Convert the payload itself. Essentially, take all information out of the source file, and create a new one with the same contents. The White Paper Preventing Document-Based Malware from Devastating your Business talks about this defense technique in much more depth.
4. Do a combination of the above. For example: only accept JPEG files, convert those to PNG and drop all other payloads.

One of the most difficult aspects of the above is not technical. It’s deciding which level of control is necessary and relevant to your business or application scenario – this is where Threat Analysis, as discussed in A Brief Introduction to Threat Analysis, fits. This is not easy, and it is why you need to consider engaging with experts that can help understand your exact situation and provide advice on the right solution for your situation.