M-Guard is an XML guard that is used at a network boundary to control traffic. An M-Guard instance is an application level data diode, with traffic flowing in one direction only. Commonly, M-Guard instances will be deployed in pairs, one controlling flow in each direction.
M-Guard takes inbound XML messages and either passes them through or blocks them. It does not perform any transformation; it expects correct messages and enforces correct behaviour.
M-Guard can be used by Isode and third-party applications. There are two primary deployment scenarios:
- Cross-Domain. When two secure domains communicate across a national of organizational boundary, it is often important to tightly control information flow across the boundary. M-Guard sits on the boundary to provide necessary controls and assurance.
- Red/Black separation. Secure systems are often split with a Red (internal/secure) and Black (external) side. Primary red-side data is always encrypted at the red/black boundary, typically with a Type 1 (NSA definition) type cryptographic system. There is often a need for management and control information to flow across the red/black boundary (crypto bypass). M-Guard is an appropriate device to control information flow across a red/black boundary.
At boundaries where simple firewall protection is insufficient, M-Guard can provide checks including:
- Prevent leak of sensitive data (e.g., by Security Label checks; sender/recipient checks)
- Prevent Covert Channels
- Prevent malware and attacks
- Encoding/Syntax/Schema checks
- Business Rule Checks
Application Integration
An M-Guard instance will sit between a pair of applications (producer and consumer), with XML messages flowing from producer to consumer. M-Guard, acting as an application level data diode, will validate messages and only pass through those that match configured criteria. These applications will be connected to the M-Guard appliance on separate networks.
M-Guard provides (optional) acknowledgement of transfer to enable reliable transfer from producer to consumer. There is no extra information included with the acknowledgement, to avoid creation of a covert channel.
When the producer application initiates a connection to M-Guard, then M-Guard will connect to the consumer application before accepting the inbound connection.
The protocol used by applications that communicate with M-Guard is the Guard Content eXchange Protocol (GCXP). Isode has published the GCXP protocol in Appendix B of the M-Guard Administration Guide. Isode has also provided a freely available C++ reference implementation of GCXP. Characteristics of GCXP:
- Transfers a stream of XML Messages.
- TLS is always used to protect the connection.
- Two way strong authentication is recommended to validate peers.
- M-Guard will always validate IP address of connecting application.
- Framing using RFC 7049 – Compact Binary Object Representation (CBOR).
Application Profiles
Each guard instance is configured with an Application Profile, which enforces basis protocol compliance to the protocol used by the application. The application profile also applies content normalization of the XML and Unicode to ensure only a single specified representation of the protocol is used. This guards against covert channels and attacks using encoding variants.
M-Guard allows import of application profiles and includes support of a generic XML profile and a profile for “Demo Protocol”. Demo Protocol provides a means to show a range of M-Guard capabilities, including support of security labels following XEP-0258 (Security Labels in XMPP) and NATO STANAG 4774/4778.
Rules & Rule Catalogs
M-Guard can apply a set of rules to check XML messages. A key benefit of using XML is that there are a wide range of standardized mechanisms to check XML messages. M-Guard supports rules using the following standards:
- XML Schema. Schema of the XML protocol.
- Xpath. A mechanism useful for specifying generic checks.
- Schematron. A flexible mechanism for specifying rules.
- Relax NG. A modern XML specification mechanism.
An application will typically have a set of Rule Catalogs. Rule Catalogs can be loaded into an M-Guard Project, and then rules from these Catalogs can be enabled for each Guard. Applications using M-Guard are expected to provide an appropriate set of Rule Catalogs.