What is the difference between a Guard and a Gateway?

August 2013

Guards and gateways are full application layer proxies that connect to two or more networks. They accept data passed on an inbound network interface, ‘process it’, and then pass data to the outbound network interface. The difference between the two is in the ‘process it’ step.

Guards

A Guard will inspect the application level data and perform checks on it – typically checks to see if the data conforms to a security policy. This policy might be checking the data is schema compliant, known-virus free or is authorised for release. Critically a Guard does not change the data, its principle role is security enforcement.

Nexor Guardian and Nexor Sentinel are Guards.

Gateways

A Gateway may perform the same capability as a Guard, but additionally might transform the data in some way. This might be to convert to a different network protocol, content protocol or perform data normalisation to a baseline standard. Typically a Gateway has more functionality than a Guard, its principle role is to enable interoperability, but can be used to enforce security policy. (To add a little confusion, some refer to the entire solution including firewalls, guards, gateways and maybe diodes as ‘the gateway’ – but the point holds, in this scenario the gateway is transforming the data in some way.)

Nexor Merlin and Nexor Border Gateway are Gateways.

Why is the distinction so important?

In short – Assurance.

If the business objective of the application layer proxy is to enforce security, then you need to be able to trust it. In higher assurance environments this means the product either needs certification from a 3^rd party such as Common Criteria or GCHQs Commercial Product Assurance. Failing that, an accreditor will need to approve the product or overall system containing the product. Typically to gain such certification or accreditation to a high assurance level, you keep the security enforcing component as simple as possible in order to prove the capability. Thus Guards focus on security enforcement without the complication of data transformation clouding the picture.

In some cases, the overall solution needs data transformation as well. At Nexor, we prefer to separate this into a Gateway. Our Secure Information Exchange Architecture, provides for both Gateway and Guard elements – with a Gateway preparing the data for interoperability purposes, then passing it to a Guard for security enforcement. If the Gateway fails to perform a valid transformation, the Guard will prevent the data transfer as a violation of policy. This approach simplifies the assurance approach as only the Guard element is security enforcing.

Some suppliers will add transformation capabilities to the Guards, and often our customers request this too. Indeed, Nexor Merlin is to some extent a hybrid – it is transforming PDF files from an unknown state to a known-good state to reduce malware risks. For some customers this will be perfectly adequate, and better than they have today, but it is a security compromise. For high assurance customers, we’d also recommend that a Guard validates the new PDF is schema compliant having been processed by Merlin (or better still, not transfer the PDF – instead have the gateway transform the document to a simpler format that can be checked more easily for schema compliance by the guard).

Security is never easy, and is a balancing act between usability, affordability and trust. By having a modular Secure Information Exchange Architecture, with separated components (physically, or virtually) for Guards, Gateways (and flow control), we are able to work with our customers to select a solution that matches their business risk profile.

Can we help you with your secure information exchange needs?

Author Bio – Colin Robbins

Colin Robbins is Nexor’s Managing Security Consultant. He is a Fellow of the IISP, and a NCSC certified Security and Information Risk Adviser (Lead CCP) and Security Auditor (Senior CCP). He has specific technical experience in Secure Information Exchange & Identity Systems and is credited as the co-inventor of LDAP. He also has a strong interest in security governance, being a qualified ISO 27001 auditor.