Security Policy, Security Label  and Security Clearance

Isode has a Security Policy, Security Label, and Security Clearance infrastructure used in its products. This page examines infrastructure capabilities, which are utilized in all of Isode’s products, and provides general information to help clarify this technically complex area.

• Security Labels, Security Clearances, and Security Policy
• Security Policy Information Files (SPIFs)
• Isode’s Security Policy Architecture
• Conformance

Security Labels, Security Clearances, and Security Policy

An introduction to Security Labels, Security Clearances, and Security Policy is given in the Isode whitepaper [Access Control using Security Labels & Security Clearance]. The model of associating security labels with information and using Security Clearances (associated with users) to control access is well known. Security Labels and Security Clearances map naturally to online representations. Security Policy is central to systems applying access control using security labels. Key features of Security Policy are set out in the following sections.

NATO Alignment

Isode infrastructure is based on use of NATO Confidentiality Labels specified in STANAG 4774 “CONFIDENTIALITY METADATA LABEL SYNTAX”, published as ADatP-4774, with protocol binding specified in STANAG 4778 “METADATA BINDING MECHANISM”, published as ADatP-4778.

Isode’s infrastructure also provides support for a number of other older formats.

Security Label Validity

Different countries and organizations use different values of Security Classification and Security Categories. It would be impractical to handle all options within the Security Label definition. It would also be undesirable, as this information is often restricted. The solution to this in open standards is to define Security Label syntax generically, and to include within the definition a unique Security Policy reference, typically an Object Identifier. The Security Policy specifies the Security Classification levels are valid and their hierarchy, and defines Security Categories.

A consequence of this is that an application using Security Labels has to make two levels of check:

• A syntactic check to parse the Security Label and to identify the Security Policy.
• A check against the Security Policy, to verify that the combination of Security Classification and Security Categories is valid under the Security Policy.

Security Clearance Validity

Security Clearances are validated against Security Policy in an analogous way to Security Labels.

Rules to check Security Labels against Security Clearances

This is the Access Control Decision Function (ACDF), call CMBAC (Confidentiality Metadata Based Access Control) by NATO. Although most aspects of checking a Security Label against a Security Clearance are mechanical, some aspects are controlled by Security Policy. The main functions are:

• Whether Security Categories are ‘permissive’, ‘restrictive’, or ‘informative’. For example, a user will generally have a single country category in the Security Clearance. In contrast, a Security Label may specify several country values, only one of which needs to match a value in the Security Clearance. This is a “permissive” Security Category. A ‘restrictive’ Security Category will require all values present in a Security Label to be present in the Security Clearance. Additionally, a Security Category in a Security Label may indicate that a certain marking be displayed but not impart any authorization restriction. This is an ‘informative’  Security Category.
• Equivalent Security Policies defined within a Security Policy enable matching between Security Labels and Security Clearances defined under different Security Policies.
• Default Security Policy data defines how unlabelled data should be handled and what access users without a clearance are to have. This is often used in one of two ways:
  1. Treat unlabelled data as “unclassified” and grant users with clearances access to “unclassified” data; or
  2. Deny access to unlabelled data and deny all access to users without clearances.

How to display Security Labels

Security Labels are used in many places, and users must recognize the Security Label being used. Thus, Security Policy controls how Security Labels are displayed, to ensure consistent representation and prevent confusion. Presentation features that may be present in a Security Policy:

• String appropriate to use in a GUI.
• String with reduced character set, suitable for use in protocol. M-Switch uses this display mechanism to generate FLOT (First Line of Text) labels in email messages.
• Short string, suitable for use in compact location (e.g. “NS” for NATO SECRET)
• Colour used to display the label.

Additional Functions

It can be seen from the above that support of the Security Policy is central to an implementation using Security Labels, particularly when Access Control is applied. The following additional useful functions, while not generally a part of Security Policy, are provided by Isode’s Security Policy implementation:

• Display of Security Clearances, in a manner consistent with Security Label display.
• Creation of Security Labels and Security Clearances, so that users can be guided to create valid Security Labels and Security Clearances.

Security Policy Information Files (SPIFs)

Security Policy support is important for two types of components:

1. ‘Security Enforcing’. This is a component, such as Isode’s M-Vault server, that will make an Access Control Decision Function (ACDF) using CMBAC based on Security Labels, for example, to grant or deny access to data.
2. ‘Security Aware’. This is a component, such as Isode’s Sodium GUI, that will follow the Security Policy to correctly set and display Security Labels. A security-aware component may also warn or prevent the user from performing actions prohibited by Security Policy, but it is not assumed that it will do so.

Security Policy needs to be correctly honoured by both Security Aware and Security Enforcing components. This is usually achieved by use of a Security Policy Information File (SPIF) that is typically digitally signed by an appropriate authority. Specifying Security Policy in a single verifiable file helps to ensure that all components are correctly and consistently configured.

Isode uses the Open XML SPIF format has an agreement between a number of vendors. The semantics of Open XML SPIF are based on SDN.801c, and extended in some areas.  NATO standards make informal use of this SPIF and it is anticipated that future NATO standard will be based on this format.

Two older standardized SPIF formats are noted:

1. SDN.801c “Access Control Concept and Mechanism” is specified by the US NSA (National Security Agency) for use by the US Government and Military.
2. X.841 “Information technology – Security techniques – Security information objects for access control” is an ITU-T standard SPIF format.

Isode’s Security Policy Architecture

Isode’s Security Policy implementation architecture is illustrated below, based on the Security Policy specified according to Open XML SPIF.

Security Policy and SPIF Support

Isode provides several sample SPIFs, with capabilities fully supported by Isode’s Security Policy infrastructure:

• The US Government General Services (GENSER) Security Policy. GENSER is a complex policy that uses many of the capabilities of SDN.801c, and also defines colours for Security Classifications.
• NAC AC/322-D (2004) 0029 (INV) “INFOSEC Technical and Implementation Directive for Labelling of Information in Electronic Format”.
• JSP 457. A UK Government Policy, based on ACP 332.
• The example policies are defined in RFC 3114.

Security Labels

The format of the security label used varies from protocol to protocol. Isode’s approach is to provide a mapping between a generic internal format and various formats used by different applications. Isode supports the following Security Label formats, including mapping between the formats:

• NATO STANAG 4774 Confidentiality Label format.
• X.411 format, for use with X.400 protocols. This is the first of three very similar ASN.1 (binary) encoded Security Labels. This was the original specification, used as the basis for the next two.
• X.501 format, for use by X.500 protocols and X.500 Rule-Based Access Control. This is equivalent to the X.411 definition, but independently specified.
• ESS (Extended Security Services) security labels syntax is specified in RFC 2634 for use with S/MIME. It is also used by STANAG 4406 Military Messaging. ESS labels have a syntax very similar to X.411 labels.

Security Clearances

Isode’s preferred Security Clearance format is the one specified in STANAG 4774, which is the default used across the product set. There is also some support for an older Isode proprietary XML format and for the format standardized in X.501, which is used as both a directory attribute and as an attribute within an X.509 digital certificate.

Security Label and Security Clearance Validation

Isode’s infrastructure provides checking of both Security Labels and Security Clearances. Basic syntax checking is provided when security labels are loaded (mapped to internal format). M-Switch provides mapping between Security Label formats, allowing but not requiring checks against Security Policy. After initial load, a Security Label or Security Clearance can be checked against the Security Policy.

Security Label-based Access Control

Access Control is provided by the Access Control Decision Function called CMBAC by NATO. In CMBAC/ACDF, you match a Security Label against a Security Clearance in the context of a Security Policy (the Governing Security Policy) and get a Yes or No answer.

The best way to examine CMBAC/ACDF is in the context of an application providing this capability. This is described clearly in whitepapers for M-Vault [Using Security Labels for Directory Access Control and Replication Control], M-Link [XMPP and Security Labels], and M-Switch [Security Label Capabilities in M-Switch Products].

Security Policy is essential for the correct implementation of Access Control, as Security Policy-specific rules, such as restrictive vs permissive vs informative Security Categories, need to be followed.