Today marks the beginning of an exciting week for me. I am on site at one of our major clients installing an Information Exchange Gateway demonstrator that I’ve been working on for the last few months. Over that time I’ve seen a growing amount of interest in Information Exchange Gateways (IEGs) from various military organisations, so I decided that it was the right time to start a mini series of blog articles on the topic.
First of all what actually is an Information Exchange Gateway?
An IEG is a system designed to facilitate secure communication between different security and management domains.
Information exchange is required in the military context to provide seamless human-to-human communication across the force for mission planning and execution.
An IEG is a solution for effecting information sharing between different security and information domains by providing a managed set of information exchange services. The purpose of the information exchange service is to connect domains that otherwise lack interoperability.
Whilst information exchange is desired, the confidentiality and other information assurance aspects of connected information domains must not be compromised and therefore suitable information protection services must be implemented.
Why is there so much interest in Information Exchange Gateways?
In today’s military operations there is an increasing reliance on both coalition partners and network-enabled capability. This combination means that there is an ever-growing requirement for the secure exchange of information between different nations’ forces.
For example during the NATO operation in Afghanistan the requirement to exchange information between nations was facilitated by the Afghan Mission Network (AMN). Based on the success of AMN the concept for a Federated Mission Network (FMN) was established, which will begin to be deployed this year.
What kind of Information Exchange Gateways exist?
NATO has defined a number of IEG scenarios, each with scenario variants. The information sharing needs span many different types of organisation and trust: between trusted NATO partners; between non-NATO military forces, between military and international organisations; and even open source intelligence from the Internet (such as Google maps to provide local situational information).
The five scenarios (A-E) take account of the security classifications of the domains that they connect, as well as the security policy, the owners and the administrators of those domains.
Flexibility should come as standard in Information Exchange Gateways
In my role as a Solution Architect, regular readers of this blog will know that this year I’ve been heavily involved in Information Exchange Gateways. I was recently over in Brussels at the European Defence Agency (EDA) headquarters to deliver a final presentation on the IEG work we have done for them. Possibly the biggest challenge that came up in the meeting was around the flexibility required in enabling secure information exchange.
Along with my colleague Neville Smikle, Head of Operations at Nexor, and our German partners at CSC, I was presenting to the member nations of the EDA. We were outlining the IEG Demonstrator that had been developed for them and looking at the issues that had been overcome in its development.
From my experience with this project and the others I’ve been working on recently, each scenario where an organisation wants to set up an information exchange gateway to enable secure sharing of information, ends up with specific factors that they require and these vary from project to project.
Some variations we’ve seen are:
- Protocol variations – for example, different protocols used for simple file exchange;
- Content inspection – the level and depth of content inspection expected;
- Node protection – for example, the number of different anti-virus engines or types of Intrusion Detection/Prevention Systems in use;
- Quarantine – how data that does not meet the security policy is to be handled;
- Cost trade-offs – virtualisation can be used to reduce size, weight and power consumption, but for some customers this can introduce unacceptable hypervisor risks into the system;
- Management integration – whether there is a need to integrate the IEG into a wider protective monitoring environment;
- Accreditation – we have seen differences in the accreditation approach and the emphasis, or otherwise, placed on product evaluations (more on this particular aspect another day);
- Through life support – differing approaches to system longevity, scalability, and adoption of newly discovered security vulnerabilities;
- Rapid reconfiguration – to meet different deployment requirements, there is often a need for rapid reconfiguration of the system to adopt different protocols and security policies.
As such it is very hard to define an exhaustive list of exactly what is needed to implement an IEG – every situation is different, so it is vital that when you are looking at how to build a solution that you have flexibility to meet these different needs.
I’ve briefly covered the issue of flexibility here. The other big challenge that we discussed in Brussels was around getting solutions accredited, so I’ll tackle that in my next post.
In the meantime, if you want to find out more about IEGs and what the hot topics are with them at the moment then take a read of the new Nexor white paper “Information Exchange Gateways: The Evolving Story”.
Deploying Information Exchange Gateway solutions
With the current interest in Information Exchange Gateways (IEGs), I wanted to update you on the work that we have been doing with the European Defence Agency over the last year or so.
In the previous two posts in this IEG mini-series, I first looked at the different scenarios that facilitate the need for an IEG; secondly we considered a reference architecture for building a solution. In this post I will take you through the Nexor approach to developing solutions.
As you may recall, the IEG architecture can be broken into four logical components:
- Node Protection;
- Information Exchange;
- Information Protection;
- Information Management.
The Nexor IEG Solution Architecture below shows how Nexor can deliver a fully functional IEG with a combination of our own technology, from our SIXA portfolio, and third-party components as required. (If you click on the diagram then you will be able to read it properly!)
The Nexor components in the darker purple lozenges, such as Sentinel or Guardian, are implemented in some of the world’s largest military organisations across a variety of land, air and maritime environments.
But it’s not just about the architecture components described in this paper, our approach at Nexor is about being able to provide a comprehensive capability either as an outsource supplier or as a specialist integrator.
One of the projects that I have been working closely on over the last year with our partners at CSC is in the development of an IEG demonstrator for the European Defence Agency. This approach to secure information exchange will allow the European Defence Agency and the different nations working within it to co-operate to achieve a common goal, whether this be in conflict; on particular initiatives (such as anti-piracy); in peace-keeping; or for humanitarian aid purposes.
The project culminated recently with an on-site visit in Germany for the successful validation of the solution. I’d also just like to say a big thank you to our hosts at the WTD81 for their hospitality.
Building an Information Exchange Gateway
One of the current projects that I’m working on meant that as I blogged last time I was on-site installing an IEG demonstrator for a client. Progress went well, but more on that another day. What I wanted to write about today was how we started to create a solution. In order to do that we need to go back to 2009 when Nexor first developed a reference architecture for an IEG.
This architecture has subsequently been widely adopted and referenced in the sector. It identifies the key components of a solution and defines their functionality. Importantly the architecture is both product and vendor independent.
The architecture presented here is one that will support the majority of the main scenarios defined by NATO. Other scenarios require either a subset of this architecture or a data diode in addition to this architecture.
The diagram below shows an IEG protecting the “A” domain, which connects to an IEG in order to communicate with the “B” domain.
The IEG can be broken into four logical components:
- Node Protection
- Information Exchange
- Information Protection
- Information Management
The IEG works on the principle of the self-protecting node; it assumes that any domain to which it might connect may be hostile. In order to allow exchange of information with other domains, it therefore must provide some protection for the domain. There are two levels of protection to be provided, Node Protection and Information Protection.
Node Protection – this protects the infrastructure of the domain by providing services such as network filtering, intrusion detection and virus/malware detection.
Information Protection – this protects the data residing in the domain by providing services to check the “releasability” of information outside of the domain.
The ultimate purpose of the IEG is to enable Information Exchange with other domains. The information exchange is controlled in an IEG through the use of proxies to enable specific information flows only. The proxies also enable information flow between non-IP routable networks which is currently the typical classified network situation between NATO and Nations.
The IEG must be managed to ensure that it is acting correctly. A separate Information Management network allows various components to be monitored and managed in a secure way.
This is a very brief overview for summary purposes but I hope it gives you the first step on how we approach building an IEG – just like the one I was installing recently.
If you want more details on how each of these four components enables you to build an IEG then I suggest you download a copy of the Nexor IEG Reference Architecture white paper or get in touch with me.