How do you evaluate an Information Exchange Gateway solution?
September 2015
How do you evaluate an Information Exchange Gateway solution? I’ve blogged previously about how Information Exchange Gateways (IEGs) need to be built in a flexible manner to meet a variety of customer requirements. The other big question from potential customers is how do they know that they can trust a solution?
Approaches to evaluation
Two common techniques are used – Product Evaluation and Solution Assurance. 
Product Evaluation is where a third party looks at the design and implementation of a specific product and certifies that it meets a defined set of security behaviours. The most widely recognised form of this is Common Criteria, an internationally recognised product evaluation scheme. It has had mixed success, but is currently undergoing transformation to address its underlying issues. It is adopting an approach more closely aligned to the CESG work on Commercial Product Assurance (CPA). The second technique is Solution Assurance, whereby a system is accredited by a third party to ensure that identified security risks have been mitigated. Mitigation may include using evaluated products. In an IEG context, it is important to note that Product Evaluation typically looks at a single product, not the IEG system as a whole; whereas Solution Assurance looks at the full IEG system. 
Product Evaluation is a comprehensive process but relatively rigid – defining a specific set of behaviours that a product should exhibit. Whereas Solution Assurance focuses on ensuring that the differing design, build and deployment requirements of each solution is done securely. These two factors can therefore work against each other – a rigid process for a product class that requires flexibility!
A modular approach to IEGs
A way to overcome this is to take a modular approach that systematically provides an accreditor with the evidence needed to give confidence in a solution and its product components. An approach where a baseline is defined for the basic good behaviours of a capability, with “top-ups” for specific behaviours and capability. 
We have already seen some examples of this approach, supported by CESG in the UK.
The Network Device Protection Profile is an example of a Protection Profile that describes “security requirements for a Network Device”, it is intended “to provide a minimal, baseline set of requirements that are targeted at mitigating well defined and described threats. It represents an evolution of “traditional” Protection Profiles”. This has then been augmented with modules to define specific profiles for Virtual Private Network (VPN) gateways, Firewalls and Session Initiation Protocol (SIP) gateways (for voice over IP). I foresee this also being the way forward for guards and application gateways as part of an IEG solution. The baseline approach being used to certify that a product’s architecture and build approach is sound and implements all the basic controls that would be expected for this class of product. 
I’m sure the topic of how best to evaluate IEG solutions will be prominent next week at NIAS ’15, the NATO Communications and Information Agency’s most important cyber security event of the year. I’ll be at NIAS ’15. Feel free to drop by the Nexor stand to discuss your organisation’s requirements. In the meantime if your organisation is considering using an Information Exchange Gateway you can read the Nexor white paper “Information Exchange Gateways: The Evolving Story” to find out what’s happening across the sector.
Author Bio - Martin Cooper
Martin Cooper is a Solution Architect at Nexor delivering cyber security solutions to governments, defence and critical national infrastructure organisations.
