Creating and Managing a Security Label Policy

Security Label Policy (simply termed “security policy” in most security label standards) controls the detailed structure of security labels and how they are used to provide access control.

Open standards are vital for deployment of security labels outside of small localized deployments. Many of these standards are comprehensive, as a consequence of capabilities included to support complex environments.

This whitepaper introduces some of the key concepts in this area and then describes the capabilities of Isode’s Security Policy Information File (SPIF) Editor in a way that enables a quick evaluation of the product.

The Role of Security (Label) Policy

A Security Label for use by applications and documents will typically contain two pieces of information:

• Security Classification. This will typically be well known values such as “SECRET”, “TOP SECRET” and “UNCLASSIFIED” that give the basic classification of the information. In some environments, the classification can take on other values. For example the key classification in the Isode security policy is “CONFIDENTIAL”.
• Security Categories. These are used to provide additional information to provide more detailed information, as the basic classification provides insufficient control for most secure environments. A security label can contain many security categories, with multiple values for each. Some example security categories:
  • “For Official Use Only” – a simple value that may be added.
  • “Releasable To” – a list of countries or organizations to which the information may be released. For example “Releasable To NATO” or “Releasable to UK/US”,
  • A list of departments or functions which are allowed access to the information that is labelled.

The central role of a Security (Label) Policy is to specify which labels are valid. If information is being shared, it is vital that all users have a common understanding of the labels to be used and that tools adding labels only add valid labels. A shared security policy enables this. Other capabilities provided by a security policy include:

• Control of format of the associated Security Clearances.
• Control of how Access Control works (the detailed functionality of checking a Security Label against a Security Clearance).
• Control as to how security labels are displayed in different locations (e.g., on front page of document or in document header), including form of words and colour.
• How label equivalences work to support cross domain operation and security label mappings at domain boundaries.

Further information is provided in the Isode whitepaper [Access Control using Security Labels & Security Clearance].

Isode Security (Label) Policy Management Goals

Isode’s goals for support of security labels and security policy are:

1. Use open standards. Isode is an open standards company.
2. Support all common open standard security label formats, and conversion between them.
3. Provide high functionality security policy capabilities.
4. Use the Open XML SPIF format for SPIFs.
5. To provide a flexible tool to view and analyze SPIFs supplied or generated elsewhere.
6. Make it very easy to make simple changes to complex SPIFs.
7. Make it very easy to create and manage simple SPIFs.
8. Provide straightforward creation and editing functionality for complex SPIFs and advanced security policy functionality.
9. Ensure that SPIFs are valid and that errors are cleanly reported.

The rest of this whitepaper looks at the detailed SPIF creation and editing capabilities of Isode’s SPIF editor in support of the goals listed above.

Use with Isode Products and Other Applications

SPIF editing is not usually an end in itself. The security policy being managed will invariably be used in support of other applications. This section gives some pointers as to applications that can make use of SPIFs created by the Isode SPIF editor:

• The M-Switch family (including M-Switch SMTP and M-Switch X.400) are high performance message switches with advanced local and cross domain security label capabilities. Information on security label capabilities is provided in [Security Label Capabilities in M-Switch].
• Isode’s M-Link family includes XMPP servers and XMPP Boundary Gaurd (M-Link Edge). Security label capabilities are described in [Using Security Labels to Control Message Flow in XMPP Services].

Trying it out

The Isode SPIF editor is installed with all Isode products. On Windows it can be launched by selecting “SPIF Editor” from the Isode program group, on Unix by using “/opt/isode/bin/sdat”. When you run SPIF Editor you get the initial screen shown below.

We describe a number of SPIF Editor capabilites as “easy” and the rest of this whitepaper is written so that, if you wish, you can follow along with the SPIF Editor in order to validate this claim.

Some Sample Policies

The basic capabilities of the SPIF editor are best explored initially by loading some sample SPIFs. This will also show the utility of the SPIF Editor to view SPIFs. All of the SPIFs shown below can be loaded from the “load sample” option in the initial screen.

NATO

This NATO SPIF is a good example of a basic military SPIF following the NATO AC/322-D (2004) 0029(INV) model. The layout shows the named policy, the list of security classifications and then each security category and values for each category. The right hand pane is used for detail display and configuration of policy, classifcations, categories and category values.

UK Government

This UK Government policy is a good sample of a generic government SPIF.

Isode

Isode’s own security policy is an example of a simple commercial policy. Points to note:

• There are two classifications, but “Confidential” is the significant one, as unclassified information is not labelled (and the policy leads to applications not setting labels by default). Access control keeps confidential messages (including XMPP) to Isode and to partners that have signed NDAs.
• There is a restrictive category with one value “Internal”, which can be used with either classification. Where this category is used access control is used to keep messages internal to Isode.
• There is an informational category with one value “Sensitive”, which can be used with either classification. There is no access control associated.

Easy Editing

Where a complex SPIF (Security Policy) is used, creation of the initial SPIF is going to require some skill and care.   However, once it is deployed, it is highly desirable that routine changes are straightforward to make.   The most common change is adding a new category value, and this task is shown next.

You can select the “Add Category Value” button, when the appropriate category is selected. This presents the screen shown above. The new value is entered and “Confirm” selected.

Easy Creation

If a simple SPIF (Security Policy) is going to be used, it should be straightforward to set this up. The following section shows how SPIF Editor is used to create a simple SPIF, after selecting “Create SPIF” from the initial screen. The initial SPIF creation needs three parameters, two of which have usable defaults.

1. Each SPIF has a policy model. For basic use, the default is fine.
2. The name of the SPIF needs to be supplied.
3. Every security policy is identified by a unique “object identifier”. A random value is provided, which will suffice for many uses. It will generally make sense to get a correctly allocated object identifier for a SPIF that will be widely shared. There are many ways for organizations to obtain official object identifiers.

For basic use, only the name needs to be supplied.

The next screen enables setup of security classifications. The starting point is a set of five standard values with unclassified as the default. This list can be extended, reduced or replaced and the order and default set.

After this a basic SPIF is created. If the “top level” of the security policy is selected, “add category” can be chosen to add the first category. Two fields need to be entered in this screen (below) that creates a new category and the first value for that category:

1. “Category Name” is set to the name of the security category.
2. “First Category Name” is set to the name that is desired for the first value of the category.

To avoid a long First Category Value it is recommended that the “Category Type” is set to “Restrictive” and the “Encoding Type” to “Bitset”.

If the only reason for the SPIF is control of security label format, the value of tag type does not matter, and the default may be used. If access control is going to be done, the tag type controls how this works. “informative” means that the category is not used for access control. “permissive” and “restrictive” values define the two options for how security label and security clearance values are matched.

The following screenshot shows the SPIF after completion of the steps outlined above. Next steps might include:

• Creation of more security categories.
• Adding security category values.
• Adding colours for the classifications.

Advanced Editing

It can quickly be seen that the SPIF Editor provides a range of advanced options. In general, these will be clear to someone who needs to use them. The aim of this whitepaper has been to give a sense of the experience that the Isode SPIF Editor provides and not to give a tutorial on advanced SPIF editing. Some things that will be of common interest:

• It is often important to control how labels are displayed by various applications and documents. There is flexible configuration of marking data to achieve this.
• SPIFs are often specified in standard documents. When this happens, the SPIF needs to follow the specification. Many of the advanced features enable this to happen and allow detailed control of values in the SPIF. These features are not important where label function is the only goal. This is crucial if a specification needs to be matched.

Cross Domain and Equivalences

An important use of SPIFs is to control security label mappings in cross domain deployments. Isode’s M-Switch and M-Link Edge products provide capabilities for cross domain support. The standard SPIF model for label mapping is that a SPIF is used for the output security label format. The input label format will be defined in a separate SPIF. The output SPIF allows specifications of equivalences, that define how the labels from one or more input SPIFs are mapped to the output format.

SPIF Editor supports editing of equivalences in a SPIF by loading the input SPIFs to make editing of these mapping straightforward. These mappings are complex and do require good understanding of security labels and SPIFs. Loading the input SPIFs enables easy selection of valid values for equivalences.

This is best seen by example. One of the cross domain examples can be loaded. They will prompt to load equivalent SPIFs, which can be easily located in the supplied SPIF examples. These examples can be used to better understand how equivalence mapping works and is managed.

Conclusions

This whitepaper has given a brief tour of the Isode SPIF editor. It has shown how it achieves the goals of easy SPIF editing and creation, while giving high functionality for complex deployments and full use of open standards.