M-Guard: Isode’s XML Guard

This paper starts by looking at the technical and commercial goals for introducing an XML Guard, and why this particular approach was chosen to address problems. It then looks at the internal design of M-Guard and choices made, particularly to support product assurance/accreditation.

Solution Goals for M-Guard

There are several specific solutions that Isode is targeting to use M-Guard. The first type of solution is to support Cross Domain scenarios, where applications need to communicate across a security boundary between organizations or countries. Isode provides an XMPP cross domain solution using the M-Link Edge product. This solution is described in more detail in the Isode white paper Isode’s XMPP Cross Domain Solution. In future, Isode may produce cross domain solutions using M-Guard in support of its other products, in particular Messaging (SMTP, STANAG 4406 and ACP 127) and ACP 133 Directory.

The second class of target applications operate across red/black boundaries, where user data from red side is always encrypted at the red/black boundary. Isode has three product solutions of this type using M-Guard:

1. STANAG 5066 crypto bypass support, so that Icon-5066 product (red side) can control and monitor modems and ALE (Automatic Link Establishment) units on black side. This is described in the Icon-5066 Product Overview.
2. Support of Isode’s Red/Black product that enables monitoring and control of devices across a red/black boundary. This is described in the Isode white paper Red/Black Overview.
3. Providing separation for FAB (Frequency Assignment Broadcast) used in NATO BRASS deployments, described in the Isode white paper Isode’s Solution for BRASS (Broadcast and Ship to Shore).

M-Guard is provided as a component that can be used in conjunction with a number of Isode products. However, it is an independent product that can be used with applications provided by other vendors.

Protection will always be across a network boundary, where security considerations are paramount. It makes sense to keep the boundary product (M-Guard) as simple as possible (but no simpler). This leads to an approach where, to the largest extent viable, functionality is pushed out to the applications connecting to M-Guard, in order to minimize functionality in M-Guard. Minimizing the M-Guard functionality improves security and also helps to bring down the price of boundary protection, making the whole solution lower cost.

Why a Network Firewall is Insufficient

A common approach used at the boundary of two networks is a Network Firewall. This separates the networks and allows selected traffic through. M-Guard is performing a specialized firewall function, and it is useful to compare with a general-purpose network firewall that operates at the IP level.

A network firewall will typically allow traffic through on selected ports. An organization will use this to control which protocols are allowed across a boundary, and sometimes constraints on packet routing. There are two basic problems with this:

1. There is no guarantee as to “correct” protocol use of the port. By opening up a port in anticipation of letting one type of traffic through, it might be used for a different type of traffic.
2. Attacks can be made through the firewall. Consider a firewall that opens up port 25 to let SMTP traffic through. A malicious system could send SMTP to a server behind the firewall to exploit a vulnerability in that server.

This means that a basic network firewall is insufficient for the M-Guard target applications.

Network Separation

The network separation that is provided by a network firewall remains a critical part of how M-Guard is deployed. Typically, this will be achieved by operating M-Guard on a system with two network interfaces, one on each side. To achieve this, an M-Guard appliance will be configured with a network interface on each side (typically considered as High/Low or Red/Black). In addition an M-Guard appliance will have one or more network interfaces for management to minimize functional exposure to the connected networks. An M-Guard setup needs to ensure that all traffic will go through M-Guard and no traffic will go around it. Network separation is inherent to the architecture, with more controls than a firewall gives.

Simplicity

Isode has made a basic choice to keep things as simple as possible. If functionality is not needed in M-Guard, it can be pushed out to the applications using M-Guard. The aim is to improve security and to reduce cost of both boundary component and the whole solution.

Content Based Control

An architectural choice is that M-Guard checks are made on discrete blocks of content. This allows controls to be specified simply as “is this content allowed” with rules focussed on single messages. The model is that the checks only relate to the message being checked, so that rules for whether a given content block is allowed are not dependent on anything other than the message.

Yes/No Decision

When content is sent to M-Guard, a simple yes/no decision is made. The expectation is that the system sending data to M-Guard understands the boundary policy rules and will only send allowed content. This means that M-Guard’s role is one of security policy enforcement. There is no content transformation. This approach simplifies M-Guard and leads to better security.

Stateless

Not holding state is a key choice that helps simplicity and resilience of deployment when multiple guards are used. The order of processing is:

1. 1. Content arrives from producer.
   2. Rules and checks are applied. If anything fails, the content is rejected.
   3. Content is send to the consumer.
   4. Optionally, a response comes back from the consumer.
2. 1. Content of response is validated. Usually the only valid response is as simple acknowledgement. Restricting this information helps to prevent covert channel.
3. 2. Response is passed back to the producer and thus the message sent out is acknowledged.

This model places reliability requirements onto the applications using M-Guard and enables simplification of M-Guard. The normal acknowledgement mechanism means that the application can rely on reliable message transfer to the peer. It is possible to operate without this acknowledgement and without transfer reliability. The stateless approach means that an application can use multiple M-Guard instances to protect against failure of an individual M-Guard instance.

Unidirectional

M-Guard  operates as an application level data diode, with application content being exchanged through the Guard instance in only one direction. A Guard supports optional control information (success or failed transfer) for use in providing reliability delivery. This can be disabled when not required by the application or when undesirable for the deployment.

Unidirectional operation is desirable for several reasons:

1. It can support scenarios where content flows in one direction only.
2. It is straightforward to support bidirectional content flow by using a pair of M-Guards.
3. Rules for one direction of content flow can be specified simply and cleanly.
4. As a simplification, it improves security.

XML

M-Guard content is XML encoded. XML is a flexible language that enables a wide range of information to be specified. It enables M-Guard to be used to support a wide range of applications.

XML has a number of standardized mechanisms for specifying syntax and rules, including:  XML Schema; XPath; Schematron; and RELAX NG. This makes XML attractive, as these mechanisms can be used to specify exactly which messages are allowed through a guard and give options for specifying rules using an appropriate language. It also allows M-Guard to use widely used open source components to provide these checks. This reduces the amount of custom-developed functionality in M-Guard.

Guard Content eXchange Protocol (GCXP)

A key part of the M-Guard design is use of Guard Content eXchange Protocol (GCXP) to connect applications to M-Guard on either side. GCXP provides a simple protocol to exchange XML messages with a Guard. It uses Compact Binary Object Representation (CBOR) as specified in RFC 7049, to provide framing.

Isode has provided GCXP as an open specification (currently in Appendix B of the M-Guard Manual). We are not aware of any open alternatives. Isode has also provided a C++ open source reference implementation of GCXP with a permissive license.

There are two goals with this very open GCXP approach:

1. It will facilitate development of third-party applications making use of M-Guard.
2. It will allow Isode applications to use other (non M-Guard) XML Guards, when those other XML Guards provide a GCXP interface.

Architectural Approaches & Accreditation

This section looks at key choices made in M-Guard, particularly to show how M-Guard has been designed to support assurance/accreditation.

Source Code Availability

While M-Guard is distributed as an appliance, Isode can supply source code to accreditors and to partners needing the source code as part of a system accreditation.

Open Source

It is a goal of M-Guard to maximize use of open source packages, where these packages are widely used and so subject to community scrutiny. Use of widely used and tested packages helps ensure security of the M-Guard server. It also enables keeping the M-Guard server code base small, which improves security and reduces cost of accreditation.

The following key open source packages are used:

1. The NanoBSD variant of FreeBSD. This is the base appliance platform for M-Guard. It is chosen as a compact security-oriented platform suitable for this type of appliance.
2. Boost. Widely used C++ support libraries.
3. OpenSSL. Widely use TLS and cryptographic product.
4. Libxml2. Widely used XML library, with comprehensive rule and checking support.

Product Update Process

It is important to keep security devices updated as attacks can be expected to be developed where there are no updates. This is particularly true of open source modules which are exposed to the community; this exposure is both a strength and a weakness. Isode addresses this by automatically tracking all updates to third party packages used an ensuring that M-Guard is kept up to date with the latest versions, as well as ongoing consideration of internal M-Guard issues.

If any security updates are made to open source packages used, Isode will assess the impact on M-Guard. In the event of changes having impact, M-Guard product updates will be rapidly made available to Isode customers with information on the security threat. In any event, Isode will make regular product updates to ensure that the latest software versions are being used.

Independent Implementation

Although M-Guard supports protocols used in other Isode products, the M-Guard implementation is entirely independent. One reason for this is to prevent systematic errors with code common to M-Guard and Isode applications using M-Guard.

Modular Open Architecture

Where possible, the M-Guard architecture is modular. A modular structure with clear interfaces supports accreditation. Detailed design documents are available to those requiring them for accreditation purposes.

Separation of Configuration Management

The M-Guard appliance is designed so that it has the necessary minimum of functionality on the appliance, with management functionality pushed externally. Configuration management is performed by M-Guard Console which is a pure Java GUI. M-Guard Console communicates securely with the M-Guard Appliance using Secure Shell. M-Guard Console Provides a number of functions:

• Configuring one or more M-Guard instances on the appliance.
• Appliance setup and management, including backup and update.
• Guard instance version control.
• Management of Rule Catalogs and Application Profiles.

Anyone with access to M-Guard Console can change configuration, which is a security risk. To minimize this risk, M-Guard will be connected through a management port. This might be a direct connection for a small setup or a tightly controlled small management network. It will generally be a sensible precaution to only connect the system running M-Guard Console when configuration changes are needed and to otherwise store the system securely and not connected. This approach will minimize risk of attack through the management console.

Guard Separation

Each guard instance on an M-Guard appliance runs in a separte FreeBSD Jail. This keeps guard information strongly separated and enables each guard to have independent naming and IP addressing.

Configuration Backups

M-Guard configuration is held in a volatile area of the appliance which is deleted on appliance restart. M-Guard Console may save this configuration to an area of the appliance which is non-volatile.

M-Guard Console may also be used to back up M-Guard configuration onto the system where M-Guard Console runs. It is recommended that backups are made onto a secure filestore and that the integrity of such backups (including digital signature) is checked prior to configuration restore.

It is also possible to script remote backup of M-Guard configuration, using secure shell access to the appliance. This will enable regular backups to be automated, which can also be used to ensure that no unexpected changes to configuration have occurred. Such backups would be done to a system running on a secure network.

Independent Monitoring

Audit and event recording is done on a special management network interface. This includes an option for operation over TCP using Reliable Event Logging Protocol (RELP) as well as Syslog over UDP. It is strongly recommended to use RELP whenever possible as this is secure and will not lose messages.

These events will need to be recorded and alerts provided to operators. In large deployments, it is anticipated the Syslog/RELP can be fed to a standard monitoring/audit system operating on a secure management network. This can alert operators to M-Guard errors and security warnings. This could use the same network interface to M-Guard as used for configuration or a separate monitoring network.

For small systems, it is also possible to configure the monitoring on the high side of the guard. This is less secure, but avoids the need for an operational monitoring network.

Normalization Checks

XML allows a number of variants. These are undesirable for a guard, because of potential to create a covert channel. Application profiles will define a set of required normalization checks appropriate to each application. M-Guard will ensure that this normalization has been applied, by applying the normalization functions to the inbound data and verifying the that binary data is unchanged which validates that the normalization was correctly applied.

Normalization also aids in development of content checks, whether part of the profile or part of a rule catalog, as it simplifies the checks needed. Typically, both syntax canonicalization (e.g., XC14N 1.1) and semantic normalization (e.g., XSLT and NFC) should be performed.

TLS & PKI

M-Guard appliance mandates use of TLS for all connections. This is seen as important security. Use of two-way strong authentication for all connections is seen as good practice and encouraged. By design, M-Guard does not have general access to external networks. This prevents standard CRL and other online certificate checking mechanisms from working. The approach taken is to not use a general purpose Certification Authority (CA). Rather, M-Guard comes with a CA built into M-Guard Console. Key pairs are always generated on the appliance and M-Guard can then export necessary certificates. In the event of compromise, the whole PKI is replaced.

There are two approaches to handling peer (application) configuration:

1. The M-Guard Console CA can be used to issue certificates to the peer, based on a Certificate Signing Request (CSR) provided by the peer; or

2. Checks of peers are based on configured Trust Anchors (root CA).

Guard Chaining

M-Guard communicates with GCXP on both sides. GCXP has been designed so that it is possible to chain multiple M-Guards together in sequence. This can be desirable to apply independent checks or where the different M-Guards are under independent management control. This could be used at a boundary for guards associated with each side of the boundary.

Rate Limiting

M-Guard provides a rate limiting mechanism, by allowing a minimum interval between messages to be configured for each guard instance. Some boundary applications see this as desirable for two reasons:

1. By limiting message rate, possibilities for covert channel are reduced; and/or

2. By limiting message rate, systems on the far side of the guard are protected from overload.

Isode notes that rate liming can introduce possibilities of Denial of Service attacks by systems sending messages and can cause problems more significant than those which the rate limiting is intended to prevent.

Digital Signatures and System Integrity

It is important to ensure that the M-Guard components are not tampered with in any way. Isode digitally signs M-Guard Appliance and M-Guard Console when they are built and provides the necessary artefacts to validate those digital signatures. Isode build process builds both the products and the tool chain used to build the products from source code. This minimizes the risks of attack in the Isode supply chain.

On startup, M-Guard Console verifies the Isode digital signature and will only run if this is validated. This ensures that the M-Guard Console Java process has not been tampered with.

When M-Guard Console loads an M-Guard Appliance (update) it will validate the signature and only load an appliance binary that is correctly signed. On initial appliance configuration, it is strongly recommended to manually check the appliance signature.

On startup, M-Guard Appliance creates a secure hash of the system, which it checks from time to time, to ensure that the appliance has not been tampered with. If it detects an error, it will log and then stop further processing.

M-Guard Console provides a further system integrity check by creating a secure seeded hash. It can repeat this check to ensure no tampering. This capability can also be scripted, so that client/server integrity checks are run at intervals. This check is stronger than the appliance check, as a sophisticated attack could modify the server hash check. The seeded hash mitigates against this sort of attack.

Application Profiles

Although M-Guard has a primary goal of supporting  a number of Isode applications, it is delivered as a “pure” XML Guard product. It is expected that applications using M-Guard will either:

1. Provide an Application Profile and associated rules as a part of the application, for loading through M-Guard Console; or
2. Make use of a third party Application Profile.

Application Profiles are described further in the Isode whitepaper [XML Guard Application Profiles].

Application Profiles specify necessary checks and other requirements for an application using M-Guard. This will typically comprise an XML schema and a set of normalization constraints. Application Profiles are described further in the Isode whitepaper [XML Guard Application Profiles].

When a guard instance is created on an M-Guard appliance, the application profile to be used is specified. There will typically be a set of rules associated with each application profile, appropriate to the application.

M-Guard Console manages projects and can load new application profiles. It comes with a generic “any XML” profile and with a profile for supporting a demonstration protocol.

Isode application profiles are supplied separately for each Isode product using M-Guard. For XMPP Cross Domain, the XMPP Application Profile is described in the Isode white paper XMPP Application Profile for use with XML Guard.

Software Appliance & Hardware

The Isode M-Guard Product is a Software Appliance. It can be delivered to run on appropriate hardware (current reference platform is Netgate 6100). It can also be run in a virtual environment (currently Microsoft Hyper-V and Oracle VirtualBox). It is anticipated that needs will arise for operation of M-Guard on special hardware (e.g., Tempest Accredited). Isode anticipates working with hardware OEM partners to deliver such solutions as a complete hardware appliance.