Using Security Labels for Directory Access Control and Replication Control

The paper looks at the functionality that can be achieved, and how this functionality may be useful in handling a number of security problems.

Background

This paper assumes some background knowledge of Security Labels and Security Clearances. This can be found in the whitepaper [Access Control using Security Labels & Security Clearance].

Terminology

This paper talks about “Directory Access Control using Security Labels”. Capabilities in this area are defined in the X.500 Standard as “Rule Based Access Control” (RBAC). While this is a useful description, there is significant potential for confusion with the term “Role Based Access Control” which is the most common industry expansion of the term RBAC. X.500 provides Role Based Access Control, as a part of the X.500 Basic Access Control. For this reason, the term RBAC is avoided. This type of access control is also sometimes referred to a “Mandatory Access Control”.

Access Control – A Simple Example

A core feature is that users have Security Clearance. The example here will use two users:

• Fred, who has Security Clearance up to ‘Secret’
• Joe, who has Security Clearance up to ‘Top Secret’

The above diagram shows a very simple DIT (Directory Information Tree) held in a directory server. The entries in this DIT represent organizations. The access control model is that a Security Label is associated with each entry in the directory, and that label indicates the sensitivity of the information contained in the directory entry. The example DIT “organizations”, with different Security Labels.

The interaction between a user’s Security Clearance and the Security Labels on information in the directory is straightforward, and illustrated above. Joe (Clearance up to Top Secret) will access the directory, and “see” all of the entries. Fred (Clearance up to Secret) will not see the “Special Forces Unit” as he does not have the right Security Clearance. To him the directory will appear as if this entry did not exist, and it only contains the two entries that he has

This simple functionality is achieved by the directory server checking the user’s clearance against the Security Label of the entry. This will require the directory server to authenticate the user accessing the directory (quite likely using strong authentication with digital signatures), look up the user’s Security Clearance and then perform access control checks against the Security Label of the entry.

Further Access Control Capabilities

The access control model here is a very simple one: Directory Information has Security Labels; Users with appropriate Security Clearance can access this information. This overall simplicity is a key feature and benefit of this approach to access control. Where a security model is simple, there is less risk of user or administrator error. This section looks at how the basic model illustrated above can be extended. It can be seen that these extensions do not damage the basic simplicity of the approach.

While the example above is easy to understand, it is not very realistic, in that most directory servers will not allow access to users with varying security classifications (i.e., directory servers will not generally be deployed with multi-level security). A more common scenario is that all users of a directory service will be cleared to the same level (e.g., to classification “Secret”). Security Label based access control will still provide value, but the granularity of control will be finer. This control will make use of Security Categories within Security Labels that provide finer grain control. See [Access Control using Security Labels & Security Clearance] for more information on Security Categories. Security Categories are also used in the replication example below.

A directory server needs to define how to handle (new) entries without associated Security Labels provided. Options are:

• Require all entries to have Security Labels.
• Add a default Security Label to an entry if one is not provided.
• Treat entries without a Security Label as if they had a default label.

The model described so far has shown Security Labels associated with complete directory entries. This is easy to understand and apply in many situations. This model could be extended to apply Security Labels to individual attributes or to individual attribute values. For example, a Security Label could be applied to a special telephone number, and this attribute value only supplied to users with appropriate clearance.

Access control using Security Labels is performed in addition to Prescriptive Access Control (the “standard” directory access controls). Prescriptive Access Control is described in more detail later. The key point to understand here is that both forms of access control are always used. This means that in order to access information, both the Security Label access control checks and the prescriptive access controls must

Replication

Security Labels associated with directory data can also be used to control replication. This is illustrated above, with a UK military directory (server) replicating data to a US and German directory servers. The Security Labels (using Security Categories) and consequences for replication are explained in the table below:

It can be seen that all of the data in the directory is at a single security classification, but that the Security Labels define different categories that control access to the data and are also used here to control where the data is replicated to. To implement the replication control, there is a Security Clearance associated with the replication channel from the UK directory to the partner directory, and only data with Security Labels that match the Security Clearance are replicated. Security Clearance for the two links from the UK directory in the example above are shown in the table below.

This replication model can work with different replication approaches, and in particular with:

• X.500 DISP (Directory Information Shadowing Protocol). This protocol is ideal for managed replication, and provides high performance, digital signatures of replicated data, efficient link utilization and low latency.
• Directory Synchronization products, such as Isode’s Sodium Sync, which are useful when data transformation is needed at the same time. Directory Synchronization will work by connecting to the supplying directory as a user associated with the replication link, and thus having the Security Clearance of the replication link. Thus, normal access controls will enforce the correct replication access control.

An issue that needs to be considered with replication is handling of the Security Labels that are associated with the data being replicated. There are three basic options, set out in the table below:

Server Controls

So far, use of Security Labels has been considered in the context of using Security Labels on data to control user access. Security Labels can also be used at the directory server level in two ways:

1. By associating a Security Clearance with a directory server, controls can be applied on the stored data by requiring that the Security Labels on all data stored matches the Security Clearance of the directory server. This control can be used to ensure that only data appropriate to the security level of the directory server is stored.
2. By associating a set of Security Labels with a directory server, access controls can be applied to users accessing the directory server, by matching the user’s Security Clearance with the directory servers Security Labels and requiring that at least one match be made. This allows configuration to ensure that only user with requisite Security Clearance are allowed to access the directory server.

Both of these controls can be important for managing overall security policy.

Benefits to Organizations using Security Labels

Many government and military organizations have security labeling as an important component of their overall security policy. For such organizations, Security Label based access control for directory services is a natural fit, as these controls will naturally fit with other access controls and security policies already in place. This is a key benefit to such organizations.

Where organizations are not using Security Labels, the benefits of their use for directory has to be looked at in contrast to other methods. In order to do this, the next section gives a brief summary of standard access control.

Prescriptive Access Control

This section gives a brief summary of prescriptive access control, the term used in this paper to distinguish it from Security Label based access control. This looks at X.500 basic access control, which is a flexible, standardized and comprehensive example of prescriptive access control. This is intended as a brief summary of the key features, rather than a tutorial:

• What access control is applied to: Access control can be applied to entries, attributes, attribute values and names. It controls access to information in the directory.
• Functions controlled: Access control enables a range of functions, including read, add, modify, delete and compare.
• Access control is expressed with a set of precedence ordered “tuples” that grant and deny rights, and allow sophisticated combinations of rights to be expressed.
• Access control can be applied in two ways:
  • To a specific entry in the directory.
  • To an administrative area of the directory, which is typically a subtree of the DIT (Directory Information Tree). This can be used to apply a “template” access control to many entries. X.500 defines “Simplified Access Control” as a subset of basic access control, where no specific entry access control is used, and access control is applied uniformly over a single administrative area.
• Access control is applied based on the identity of the user connecting to the directory, identified by a directory name. There are a number of options:
  • Anyone (i.e., rights for anonymous access).
  • Self. This allows control of modifying the user’s own entry. Having this as an option is important when access controls are applied over an administrative area.
  • The specific user connecting. This enables access rights to be defined for individuals.
  • Membership of a group, specified within the directory. This provides support for what is widely referred to as Role Based Access Control (RBAC). Rights are defined for a role (e.g., “marketing department data administrator”) and those individuals allowed to occupy the role are identified by membership of the group.
  • Sub-tree specification, which gives rights to users named within the subtree. This can be used as an alternate mechanism for implementing Role Based Access Control (e.g., a sub-tree specification of “ou=staff, o=mycorp” could be used to define access rights for all staff).
• The authentication level can be specified, and different rights granted for different levels of authentication. This is important, as it will often be important to require more stringent authentication for modifying sensitive data. Authentication levels supported:
  • Simple – using passwords.
  • Strong – using digital signatures for peer connection.
  • Signed – every operation signed with a digital signature.

This powerful and flexible scheme allows many things to be achieved. It generally works well for controlling data modification, as usually this is handled by a small group of individuals. Use of groups associated with management roles works well here.

Advantages of Security Label Based Controls

This section looks at how Security Label based controls can add value to directory deployments in situations that would not otherwise use Security Labels.

The first area is replication control. Because prescriptive access control is oriented to data access, it does not give a framework for data oriented control of replication. For scenarios such as the one described earlier, use of Security Labels to control selective replication of data is ideal.

The second relates to controls applying to large numbers of users – primarily situations where you want to explicitly grant read access to information to more than a few users. Where the set of users is small or the group is “natural” (and therefore easy to manage), use of groups works well. Where the list of users is ad hoc, and particularly if the users are distributed over multiple departments or agencies, managing an explicit group or managing rights in the directory for each user becomes awkward. Use of (matching) Security Clearances for the users and Security Labels on affected data becomes an elegant method of managing this sort of situation. The rest of this section looks at

• A directory of military personnel includes a number of special services staff. All information on such staff should only be made available to those with appropriate clearance. It is more convenient for users, and more practical for administrators to manage this access control with Security Labels.
• A government directory holds staff who provide Iraqi translation services. Visibility of these staff (or their translation skills) should be restricted to those with appropriate clearance.
• In a health care database, information on operation results needs to be restricted to appropriate administrators, researchers and doctors over a wide area.
• A directory is used to provide information on documents (author, title, abstract etc.), to enable users of varying clearance to search for documents. The documents have varying sensitivity, and Security Label based access control is a clean mechanism to ensure that users only see information on documents that they are cleared to see.
• A directory is used to provide information about military units or craft in a real or simulated battle management system involving users with a range of clearances and information of varying sensitivity. Dynamic information will typically come from automated systems, with the directory providing static and descriptive information associated with the objects. Security Label based access control can be used to restrict information on the data. Security Clearance and Security Label information can be taken from the directory and used to control information presentation.

What Isode Offers

Isode provides an implementation of Security Label based access control, primarily intended for demonstration and to give hands on experience. Key features:

• Support for Security Labels with Security Classification, privacy marks, and a single demonstration policy.
• GUI display of Security Labels and Security Clearances.
• Entry level access control by Security Labels.
• Demonstration data and tools to load Security Labels and Security Clearance.
• Directory Server controls (Security Label & Security Clearance).
• Replication controls based on Security Labels using Sodium Sync (Directory Synchronization).

This set of functionality gives the core functionality for Security Label based access control. To try it out, details of how to set up a system using Security Label based access control are given here (PDF).

Isode plans additional work to support Security Clearance management and access:

• Handling general Security Clearances, including Security Category support and Security Policy. In particular support for MISSI/GENSER (US) and NATO clearances.
• Full GUI editing of Security Labels and Security Clearances.
• Provision of finer grained control (attribute and attribute value level).
• Replication controls using X.500 DISP.

Feedback on these plans and on requirements in this area is welcome.

Conclusions

Security Labels provide the basis for a powerful and flexible access control mechanism that complements prescriptive access control. This is useful for:

• Organizations that operate access control based on Security Labels.
• Support for controlling access to data in situations where read access to data needs to be selectively controlled for many users.
• Controlling selective replication of data.