Summary

Anyone deploying or considering deploying a system that uses Security Labels needs to understand and consider the use of a SPIF (Security Policy Information File). Much information on SPIFs is complex and oriented towards security experts. This paper gives a short introduction to SPIFs, in order to give a high level understanding of the subject to non-experts.

Creative Commons License

Security Labels

A Security Label is attached to a document, message or other piece of information to control who can access it. For example, a document may have a label “Top Secret", and only users with a Security Clearance of "Top Secret" may read the document. A Security Label may contain additional information to more specifically control access (e.g., to restrict access to those with clearance for specific areas or projects). This extensibility is extensively used.

SPIFs and other options to control Security Policy

“Security Policy" has a very specific and constrained meaning in the context of Security Labels. A Security Policy controls which Security Labels are valid and how Security Labels are checked against Security Clearances. To understand SPIFs, it is important to remember this narrow and specific definition of Security Policy.

Security Policy needs to be handled in any system implementation that involves handling Security Labels (e.g. clients, servers and gateways). There are many ways that this could be handled. A simple approach is to hardwire the Security Policy into the product handling Security Labels, or to have the Security Policy set up as part of the system setup, appearing to the administrator as “Security Label Checking Options".

A SPIF is a file representation of the Security Policy (i.e., the definition of which Security Labels are valid and how to check them against Security Clearances). The basic concept is simple, although the details get more complex because of the desire to support complex Security Policy. By abstracting Security Policy into a SPIF, this definition becomes separate from the product that enforces or supports the Security Policy.

Update and Propagation

Where Security Policies are simple and stable, a number of different implementation approaches can work . Complex Security Policies tend to be updated frequently. One example would be a Government organization that wishes to control access on the basis of a project. The Security Label would include the project name and only those with clearance for that project would be granted access. The Security Policy would include enforcement of official project names in order to ensure that users only use correctly labeled, valid projects. As a consequence, every time a new project is created, the Security Policy needs to be updated.

In a large deployment, this updated Security Policy will need to be applied to many email clients, XMPP clients, mail servers, directory servers and boundary guards. Use of a SPIF enables this to be done efficiently. Two things are ideally needed:

  1. A centrally defined SPIF format that is supported by all products, so that only one SPIF needs to be created by the organization.
  2. Online distribution of the SPIF, so that all products can quickly pick up the new SPIF. Use of a directory service is the ideal way to achieve this. This can enable near real time propagation of Security Policy updates.

Isode SPIF Support

In order to meet the above objectives, Isode’s Security Policy approach is to be SPIF format independent. Isode supports the following SPIF formats:

  • SDN.801c. The US DoD specification.
  • The Open XML SPIF Format, available from the XML SPIF Web Site.

Isode plans to add support for the ITU-T X.841 SPIF format, in response to customer requirement for support of this format.

Isode products obtain SPIFs from the directory, and so automatic SPIF update is straightforward.

Dealing with Multi-Vendor Deployments

Real deployments will often use products from multiple vendors. Vendors with products supporting Security Labels are making a different choices on SPIF format. In order to deal with this divergence, Isode supports an industry initiative to define a common SPIF format for Interchange. This XML format is convenient for organizations to specify a Security Policy, and can easily be translated into the native format used by different vendors. This approach will facilitate deployment of multi-vendor Security Policy.

Conclusions

SPIFs are important, particularly for large deployments with complex Security Policy. There is no clear single standard for SPIF format. Isode addresses this by providing product support for multiple SPIF formats, and supporting an open XML specification suitable for vendor interchange.