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 being a launch pad to attack the Thrower depending upon communication mode. The blog Diodes are Diodes, Guards are Guards describes different communication modes, if the information flow is 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.

Payload protection will be discussed in a future blog – watch this space.

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.

Do you have Protocol Breaks protecting your core assets?