Vendor Independent XML Security Policy Information File format announced.

Cadmidium, Clearswift, CommPower, eB2Bcom, Isode, JSC, Nexor and SMHS collaborate to bring a vendor independent XML SPIF (Security Policy Information File) format to facilitate multi-vendor support of information exchange using Security Labels and invite other organizations to become equal partners in this initiative.

–

London, UK, 8 April 2009 – Security Policy Information Files (SPIFs) are machine readable files that describe specific security policies relating to Security Labels (e.g, “Top Secret & For Official Use Only & Releasable to UK and US”). A SPIF is a concise definition of a security policy in terms of:

• a set of valid Security Labels;
• the presentation of Security Labels to the users;
• how to check Security Labels against Security Clearance; and
• the equivalency with Security Labels in a different security policy

The use of a single SPIF within an organization and across applications enables the consistent handling and display of Security Labels and also supports the central management of the Security Policy by administrators. A SPIF should be used wherever Security Labels are used.

There are currently two standardized SPIF formats:

• “SDN.801 Revision C: Access control concept and mechanisms” specified by the US National Security Agency in 1999; and
• “X.841: Security information objects for access control”, an ITU-T format specified in 2000

Both are encoded in ASN.1 (a standardized binary format) and consequently can only be managed using special purpose tools.

Vendors have generally either adopted one or other of these standards formats, or defined their own proprietary SPIF format for specifying a security policy.

Cadmidium, Clearswift, CommPower, eB2B, Isode, JSC, Nexor and SMHS, expanding on work originally carried by SMHS Ltd, have come together to develop an openly available XML schema that allows the generic specification of a Security Policy and encompasses both X.841 and SDN.801c functionality. This format is based on SDN.801c, and so its semantic definitions are easy to understand in the context of SDN.801c (which is well and clearly specified). This makes mapping to SDN.801c straightforward and mapping to X.841 is also straightforward.

Version 1.0 of this SPIF format definition is available from the Schema page on the xmlspif.org website. This page also links to sample SPIFs representing a range of policies, including US GENSER, Australian AGIMO and UK JSP 457. We expect supporters of this format to contribute other samples.

A primary goal of this format is to facilitate SPIF interchange between products that use different SPIF formats, and it is anticipated that this SPIF will be used by organizations to define and manage their SPIFs, and then be mapped to vendor specific SPIFS (either one of the standardized ASN.1 SPIFs or proprietary formats).

By operating in this manner, this SPIF format will support multi-vendor deployments, where vendors do not support a single common SPIF format.

Graeme Lunt of SMHS said:

“Given the lack of consensus surrounding SPIF formats and the difficulty of editing SPIFs, it became clear to us that there is a need for an extensible schema, editable with widely available tools that would encompass a number of different definitions. Our initial schema publication on the SMHS website has attracted considerable interest”

XML has two key advantages for the specification of a Security Policy. The first is that it is a text format that can be viewed and edited using widely available tools, so use of the format is low cost for all participating parties. Second, XML is a structured format that can be easily transformed into other formats using either standards tools (e.g. stylesheets) or custom converters. This means that an XML SPIF can be used as a common community reference format, and mapped into the format required for a specific product being used. This facilitates the consistent use of security labels within large deployments, which will invariably use products from different vendors.

Richard Bailey, Boldon James Development Director:

“We believe that collaborative efforts of this type are important in our industry and are happy to support and contribute to this work, which integrates well with Boldon James’s focus on SIE (Secure Information Exchange) within the defence, homeland security and corporate sectors.”

Ed Gaffney, Cadmidium:

“Common standards are a key issue for the organisations that Cadmidium support in the development and procurement of secure communications systems. We’re happy to support this important initiative, which we believe will help both supplier and end-user organisations with interoperability issues.”

Jim Craigie, Technical Director, Specialist Products, Clearswift:

“Central management to give consistent configuration of security label policy between heterogeneous products is vital to ensure correct operation in multi-vendor deployments. Clearswift have a demonstrated commitment to open standards for SPIFs in our pioneering use of X.841 SPIFs by our DeepSecure and FlashPoint products, configured through our CC EAL4 assured SPIF Editor. Conversion of X.841 SPIFs created by our SPIF Editor to SMHS’s XML format will allow this configuration data to be used by other products that don’t demand the cryptographic integrity inherent in X.841 SPIFs.”

Kathy Nuckles, CommPower CEO/President:

“The SPIF is at the heart of all of our secure messaging solutions. Unfortunately the existing ASN.1 structure and lack of editing tools has limited our expanded use of this object into non-defense environments. XML eliminates this roadblock and opens up a host of new opportunities in markets that to date have been struggling to find a cohesive, customizable and collaborative security framework.”

Dr Steven Legg, Chief Architect of eB2Bcom:

“We are keen to cooperate with SMHS and other vendors to support the openly available XML schema. Our View500 technology can store policies in both ASN.1 and XML so we are well advanced in accommodating the new schema. We are also keen to explore the use of security labels in XACML-based access control schemes.”

Steve Kille, Isode CEO:

“We adopted SMHS’s XML schema for use in our products’ security policy infrastructure as one of the SPIF formats supported by the Isode product set. The extensible nature of XML enabled us to extend the schema to include colour support for security classifications and enables other organisations to contribute extensions that can be easily removed by systems that do not support them. We’re delighted to be working with these organisations to build a common SPIF format and hope to see others join in the development and maintenance work.”

John McKinnon, JSC:

“Open standards and interoperability are crucial foundations for high-end, secure messaging systems. A common, community generated SPIF format that encourages consistent use of security labels across products is something we are happy to support.”

Colin Robbins, Nexor CTO:

“As a business focused on connecting, transforming and protecting information flows, we are committed to implementing standards based and open solutions. Having a standard based SPIF format will help to increase interoperability across products, reducing deployment costs and help to ensure security policy is implemented consistently in heterogeneous systems.”

Organizations wishing to participate in this collaborate effort should use the contact details on the Supporters page of this website.