Summary

This whitepaper looks at how Isode’s Security Label Server product can be used to provide Security Label and Security Label based Access Control services for an external application, via a simple interface which gives good functional separation and low integration cost. EDRMS (Electronic Document and Records Management System) is used as an example application, to illustrate the benefits of this approach and to consider how best to use Security Labels with EDRMS.

Creative Commons License

Security Labels and Access Control

Security Labels are placed on to documents and other information for two reasons:

  1. To clearly label information in an unambiguous manner, in order to facilitate human handling of the information.
  2. To enable a computer to perform an Access Control on the information, so that the information is accessed only by appropriately cleared people in appropriate locations.

The first reason will benefit from a structured security label, as this will help to ensure that only a valid security label is used and may also facilitate label mapping into a different security domain. The second reason requires a structured electronic security label to work.

Access Control uses an Access Control Decision Function (ACDF), checking Security Label against Security Clearance in the context of a Security Policy, leading to a yes/no answer for the access control. This is described in [Access Control using Security Labels & Security Clearance].

Attaching a security label to information is most important when information is shared; both of the reasons for security labels are in the context of information sharing. There is less reason to label a document that will only be seen by the document creator.

Isode has provided Security Label and Access Control in its products: Messaging (M-Switch); XMPP (M-Link) and Directory (M-Vault). These involve formal information exchange, and are natural places to provide security label support.

Security Label Server

Isode has developed a flexible security label infrastructure which has been used to support Isode's server products. This paper looks at ways that this infrastructure may be used to support third-party applications.

Isode's Security Label Server provides a Web Server protocol interface exposes the capabilities of Isode's security label infrastructure in a manner that is straightforward to integrate with third party applications. Some benefits of this approach include:

  • It saves application developers the cost of implementing security label support
  • It provides end-users with integrated security label capabilities that can be managed consistently with Isode and non-Isode applications
  • Isode does not need to develop applications that are outside its core area of competence simply because of a requirement for high quality security label support

Having the Security Label Server means that the following complexities can be hidden:

  • The rules of Security Policy, such as US GENSER or NATO AC/322-D (2004) 0029 (INV), which leads to significant complexity both in Security Label syntax (particularly security categories) and access control rules for checking Security Labels against Security Clearance.
  • Security Policy (SPIF) management and storage.
  • Security Label Format. Security Label Server allows a choice of security label formats, and the client does not need to be aware of these.
  • Security Clearance lookup for a user.
  • Rules for checking labels against clearances.
  • Catalog management.

The whitepaper [Easy Security Label Support for Email Clients] shows how Security Label Server can be used to support Security Label Aware applications by providing lightweight access to security label capabilities. Email client support is given as an example of this, contrasting with Security Enforcing Functionality using Security Label based Access Control in Isode’s M-Switch server.

Security Label Server provides access to other Security Label capabilities and in particular to Access Control (ACDF). A goal of this paper is to show, by example, how Isode Security Label Server can be used to support an application that provides Security Enforcing Functionality using Security Label based Access Control.

EDRMS & Security Labels

“Documents” (in the broad sense) are likely to require security labels in environments that make use of security labels. These labels are particularly important when documents are shared. Email is a common way to exchange documents, and so support for security labels in messaging systems is important. This is considered in the Isode whitepaper [Easy Security Label Support for Email Clients].

In low security environments, electronic documents are likely to be exchanged and shared by a range of ad hoc techniques, such as: shared file stores; web servers; USB sticks. But in a high security environment that uses security labels, these techniques will not generally be used, as they fail to meet access control and audit requirements.

High security environments will generally use some form of EDRMS (Electronic Document & Record Management System). There are many EDRMS systems available on the market. The rest of this section considers how Security Labels can be handled in EDRMS systems.

Security Labels may be associated with documents using one of three mechanisms:

  1. Embedding. A label can be inserted into the document. This is straightforward from some document formats, which have extensible mechanisms, but hard to impossible for other formats. The lack of standards in this area would mean that document and label formats would need to be clearly defined for the target users.
  2. Encapsulation. Wrap the document in a format containing the label. S/MIME format would be a good choice, as this also adds digital signatures.
  3. EDRMS Meta Data. Because documents are held in an EDRMS, the security label can also be managed by the EDRMS.

This choice is likely to be important for overall system design, but it does not affect the three main places of EDRMS security label integration, which are now considered.

Labelling Documents

The first key action is to assign a security label to a document. This task is performed by the EDRMS User. This task is pretty much identical to that of an Email client assigning a security label to a message, described in [Easy Security Label Support for Email Clients].

The EDRMS user can contact the Security Label Server to get a catalog of Security Labels that this EDRMS user can utilize. The EDRMS user will securely authenticate to the Security Label Server (most likely using HTTPS and strong authentication). This will enable the Security Label Server to determine the user’s Security Clearance. The security labels provided might be selected from a system catalog and a personal catalog. The labels returned to the user will be filtered so that only those appropriate to the user's Security Clearance are included. The EDRMS may also filter based on other appropriate Security Clearances, such as one associated with the target EDRMS. The EDRMS user sees a simple XML Catalog that can be displayed to the user, enabling the user to identify the desired security label (and associated display marking). The EDRMS user may make use of the display marking within the document.

The EDRMS User can then provide the EDRMS system with a Security Label that it can store within or alongside the associated document. The EDRMS system will check the document and file it in an appropriate place, which may be dependent on the Security Label. This has been achieved with an absolute minimal awareness of security label capability in the EDRMS User application.

Retrieving Documents and Access Control

The second task is to retrieve a document from the EDRMS. Documents will have associated Security Labels, and so Access Control can be applied, with the EDRMS providing Security Enforcing Functionality (SEF).

To achieve this, the EDRMS will access the Security Label Server. When there is a request from a user to access a document, the EDRMS will provide the User Name, and the Security Label (associated with the requested document) to the Security Label Server, with a simple HTTP Command requesting an ACDF (Access Control Decision Function). The EDRMS will authenticate to the Security Label Server with an identity that has privilege to determine user clearances.

The Security Label Server will look up the user’s Security Clearance, so this can be transparent to the EDRMS. The Security Label Server will then perform a standard ACDF check between the Security Label and Security Clearance in the context of the Governing Security Policy, and then return a yes/no answer to the EDRMS. This will tell the EDRMS whether or not to provide the requested document. If the document is provided, the EDRMS will also provide to the user:

  1. A display marking for the Security Label, so that the EDRMS User can appropriately display the label information associated with the document. The EDRMS may store this with the document, or use Security Label Server to determine it.
  2. The Security Label. This will not be used directly, but may be useful to the EDRMS user, for example if the document is attached to an email message.

It can be noted again, that the interface needed by the EDRMS to the Security Label Server is very simple, and can be added to an EDRMS in a straightforward manner.

Listing and Searching for Documents

The final action for which labelling is relevant is locating documents, where the EDRMS user will search for or list documents. The EDRMS system should only show documents to which the user has access. The information flow is almost identical to document retrieval. The EDRMs user will request a list or search, which the EDRMS will then perform. Before returning the results, the EDMRS server will perform an ACDF check on each document that is being listed (exactly the same check that would be made prior to document retrieval. The yes/no decision is used to filter the results returned.

What would be Needed to add Security Label Checks to an EDRMS?

Having described the architecture, this section summarizes what would need to be implemented to build such a system. Interactions between Security Label Server and Directory use LDAP, which is provided. Interactions between EDRMS User and EDRMS are standard to the EDRMS.

The key integration would be the interactions between the EDRMS Components (EDMRS; EDRMS user) and Security Label Server. Security Label Server uses Web Access over TLS (HTTPS). There is wide support for this in development kits. The commands are simple strings that are easy to construct. The results are XML, which can be handled by many libraries. Generally an EDRMS would implement that client side of the Security Label Server protocol, as this would be easier than trying to integrate a client toolkit.

The associated logic needs to be provided, and the EDRMS needs to be modified so that it stores and requires Security Labels with documents and that it performs the access control checks. The EDRMS user needs to be able to add labels, and to correctly display them when a document is rendered.

Conclusions

This paper has shown how Security Labels can be applied to EDRMS, and how Isode Security Label Server product could be used to support this.