Information Classification and Clearances

Last modified 19 Aug 2024 17:58 +02:00
Information classification feature
This page is an introduction to Information classification midPoint feature. Please see the feature page for more details.
Since 4.9
This functionality is available since version 4.9.
Table of Contents

Information classification is a process in which organisations assess their data and systems, with regard to the necessary level of protection. The information is classified by assigning information labels or classifications to individual assets, such as databases, filesystems, applications or even individual files.

For example, an application can be classified as secret, denoting that the application contains secret information with elevated protection needs. The policy is set up to limit access to all applications labeled as secret, requiring special security training as a pre-requisite for accessing the application. All roles that give access to any secret applications are subject to the same policy as well. The policy is evaluated for all applications and roles. Even if a role definition is wrong, including access that it should not include, the policy makes sure that such role cannot be assigned to any user who did not complete the security training.

Implementation

MidPoint contains two pre-configured archetypes:

  • Classification archetype is used to set up classification schemes. It is used to define set of classifications (information labels) that can be assigned to applications. The classifications specify security requirements that must be met to be able to gain access to classified applications.

  • Clearance archetype is used to define clearances. Clearances are objects which testify that security requirements were met by a particular user or organization. They represent knowledge gained at mandatory trainings (e.g. security training, health and safety briefing), non-disclosure agreements (NDA) in place, screening, formal government clearances or professional certifications, user categories (internal/external) or other criteria. Clearances usually allow access to classified applications.

The actual mechanism is based on combination of meta-roles and policy rules. Classifications act as meta-roles, specifying their security requirements in form of policy rules embedded in a second-level inducements. The policy rules often assert presence of clearances, which are represented by assignments of clearance objects to users.

Both classifications and clearances are supposed to be policy objects (PolicyType).

Example

Slovak transposition of European NIS1 directive specifies that all information systems operated by providers of essential services to be classified into three categories:

  • Category I: systems providing public information.

  • Category II: systems processing internal data.

  • Category III: systems processing sensitive data.

(This description is simplified, for full details please see Act 2018/362 Z.z. if you happen to speak Slovak).

We want to set up following security policy:

  • Access to Category I systems can be granted to any user, by the means of the usual midPoint process. The roles can be assigned directly by system administrator, requested by the user and approved, or automatically assigned by policy. No special security measures are applied.

  • Access to Category II systems can be provided only to employees or users that have signed explicit non-disclosure agreement (NDA).

  • Access to Category III systems can be provided only to users that have completed special security training.

The policy is additive in such a way, that systems of Category II have to satisfy all requirements for both Category II and Category I. Systems of Category III have to satisfy requirements for all three categories.

Configuration files
Full configuration files for this example can be found in midPoint samples in classification/classification-nis1-sk directory.

Classification Scheme

Firstly, we set up a classification framework. We create three policy objects representing the three classification categories.

category-1.xml
<policy oid="91a1bdf1-addc-4d34-b834-190938be3aca">
    <name>Category I</name>
    <description>Classified for public access.</description>
    <assignment>
        <!-- Classification archetype -->
        <targetRef oid="00000000-0000-0000-0000-000000000330" type="ArchetypeType"/>
    </assignment>
</policy>
category-2.xml
<policy oid="71a7cb99-3a69-48e3-9521-d9a933c2b5c5">
    <name>Category II</name>
    <description>Classified for internal access.</description>
    <assignment>
        <!-- Classification archetype -->
        <targetRef oid="00000000-0000-0000-0000-000000000330" type="ArchetypeType"/>
    </assignment>
    <inducement>
        <!-- Include Category I requirements -->
        <targetRef oid="91a1bdf1-addc-4d34-b834-190938be3aca" type="PolicyType"/>
    </inducement>
</policy>
category-3.xml
<policy oid="8296304e-4722-4792-b6bd-9693b2a42d70">
    <name>Category III</name>
    <description>Classified for restricted access.</description>
    <assignment>
        <!-- Classification archetype -->
        <targetRef oid="00000000-0000-0000-0000-000000000330" type="ArchetypeType"/>
    </assignment>
    <inducement>
        <!-- Include Category II requirements, which also includes Category I requirements -->
        <targetRef oid="71a7cb99-3a69-48e3-9521-d9a933c2b5c5" type="PolicyType"/>
    </inducement>
</policy>

Applications

Now we can classify the applications. We can assign classification categories to applications using ordinary assignments. Website application is classified as Category I:

website.xml
<service oid="45bb3cea-fde9-4590-812a-e86b37492bcd">
    <name>Public Website</name>
    <description>Company website, contains public information only.</description>
    <assignment>
        <!-- Application archetype -->
        <targetRef oid="00000000-0000-0000-0000-000000000329" type="ArchetypeType" />
    </assignment>
    <assignment>
        <!-- Category I classification -->
        <targetRef oid="91a1bdf1-addc-4d34-b834-190938be3aca" type="PolicyType" />
    </assignment>
</service>

Collaboration platform and management information system are classified as Category II:

collaboration-platform.xml
<service oid="183cdca7-91da-424c-9ef6-8b481f6aa57f">
    <name>Collaboration platform</name>
    <description>System for internal team collaboration. Contains meeting notes, memos, plans ... lots of internal stuff.</description>
    <assignment>
        <!-- Application archetype -->
        <targetRef oid="00000000-0000-0000-0000-000000000329" type="ArchetypeType" />
    </assignment>
    <assignment>
        <!-- Category II classification -->
        <targetRef oid="71a7cb99-3a69-48e3-9521-d9a933c2b5c5" type="PolicyType" />
    </assignment>
</service>
management-information-system.xml
<service oid="c6fe76ed-102b-4736-8e32-7c1e57c852c7">
    <name>Management information system</name>
    <description>Internal information for management decision-making.</description>
    <assignment>
        <!-- Application archetype -->
        <targetRef oid="00000000-0000-0000-0000-000000000329" type="ArchetypeType" />
    </assignment>
    <assignment>
        <!-- Category II classification -->
        <targetRef oid="71a7cb99-3a69-48e3-9521-d9a933c2b5c5" type="PolicyType" />
    </assignment>
</service>

Restricted research database is classified as Category III:

restricted-research-database.xml
<service oid="1a0b9b4b-dd86-464c-b077-9b9971424351">
    <name>Restricted research database</name>
    <description>Database containing sensitive data on secret research projects.</description>
    <assignment>
        <!-- Application archetype -->
        <targetRef oid="00000000-0000-0000-0000-000000000329" type="ArchetypeType" />
    </assignment>
    <assignment>
        <!-- Category III classification -->
        <targetRef oid="8296304e-4722-4792-b6bd-9693b2a42d70" type="PolicyType" />
    </assignment>
</service>

Policies and Clearances

It is time to implement our security policy. As category I applications are pretty much free-for-all, we do not need to specify any special requirements for category I. For category II, we are going to require non-disclosure agreement (NDA). Therefore, we need to specify a NDA clearance first.

nda.xml
<policy oid="09360ff0-d506-4751-b13f-4e01422693ac">
    <name>NDA</name>
    <description>Non-disclosure agreement clearance, applied to organizations/users that have signed the agreement.</description>
    <assignment>
        <!-- Clearance archetype -->
        <targetRef oid="00000000-0000-0000-0000-000000000331" type="ArchetypeType"/>
    </assignment>
</policy>

We will assign this clearance to users that have signed the NDA. The clearance can be assigned in any way that midPoint supports. E.g. it may be assigned manually after the NDA is signed, or automatically assigned based on user property mapped from HR system.

Now we are going to specify security requirements of category II. We absolutely do not want to specify the requirements in every application. The policy states that all category II systems require NDA, therefore we are going to specify policy that applied to all categtory II systems. We are going to specify it at the most natural place: the definition of category II classification. We will use policy rule for this purpose:

category-2.xml
<policy oid="71a7cb99-3a69-48e3-9521-d9a933c2b5c5">
    <name>Category II</name>
    <description>Classified for internal access.</description>
    <assignment>
        <!-- Classification archetype -->
        <targetRef oid="00000000-0000-0000-0000-000000000330" type="ArchetypeType"/>
    </assignment>
    <inducement>
        <!-- Include Category I requirements -->
        <targetRef oid="91a1bdf1-addc-4d34-b834-190938be3aca" type="PolicyType"/>
    </inducement>
    <inducement>
        <policyRule>
            <name>required-nda</name>
            <policyConstraints>
                <requirement>
                    <!-- NDA clearance -->
                    <targetRef oid="09360ff0-d506-4751-b13f-4e01422693ac" type="PolicyType" />
                </requirement>
            </policyConstraints>
            <policyActions>
                <enforcement/>
            </policyActions>
        </policyRule>
    </inducement>
</policy>

The policy rule states that assignment of application classified using this classification requires presence of NDA clearance. In other words, it prohibits assignment of privilege (policyAction is set to enforce) in case where the user does not have NDA clearance already assigned. The policy rule is specified in inducement, therefore it is applied to all objects that have this classification assigned, which means all applications that have Category II classification.

Classifications naturally act as meta-roles. Policies specified in classifications can be transitively applied through the entire assignment/inducement chain, all the way to the user.

Explicit assignment of NDA clearance is perhaps a good method for external workers. However, employees usually have non-disclosure clause as part of their employment contract. There we can set up a policy that assumes that every employee already meets the requirements for NDA. In other words, presence of NDA is assumed for every employee. The most natural way to do that is to include (induce) NDA clearance in Employee archetype:

employee.xml
<archetype oid="7f7c8cb1-9da4-4845-bd17-49d705b8546a">
    <name>Employee</name>
    <description>Archetype for employees.</description>
    ...
    <inducement>
        <description>Employees have non-disclosure clause in their contracts, therefore NDA clearance is assumed.</description>
        <!-- NDA clearance -->
        <targetRef oid="09360ff0-d506-4751-b13f-4e01422693ac" type="PolicyType"/>
    </inducement>
</archetype>

As NDA clearance is induced by the employee archetype, every user with Employee archetype satisfies requirement for NDA clearance. Therefore, systems classified as Category II can be assigned to employees without any additional manual step.

Similarly, definition of category III can be extended with requirements for special security training. We define the clearance first:

special-cybersecurity-training.xml
<policy oid="5bb5c5b5-eca2-4129-b73f-34c0b0bd2736">
    <name>Special cybersecurity training</name>
    <description>
        Clearance that attests that the user passed through special training of information security practices.
        Requirement for granting access to restricted data.
    </description>
    <assignment>
        <!-- Clearance archetype -->
        <targetRef oid="00000000-0000-0000-0000-000000000331" type="ArchetypeType"/>
    </assignment>
</policy>

We can use the approach described above to place requirement for the special clearance into category III definition:

category-3.xml
<policy oid="8296304e-4722-4792-b6bd-9693b2a42d70">
    <name>Category III</name>
    <description>Classified for restricted access.</description>
    <assignment>
        <!-- Classification archetype -->
        <targetRef oid="00000000-0000-0000-0000-000000000330" type="ArchetypeType"/>
    </assignment>
    <inducement>
        <!-- Include Category II requirements, which also includes Category I requirements -->
        <targetRef oid="71a7cb99-3a69-48e3-9521-d9a933c2b5c5" type="PolicyType"/>
    </inducement>
    <inducement>
        <policyRule>
            <name>required-special-training</name>
            <policyConstraints>
                <requirement>
                    <!-- Special cybersecurity training clearance -->
                    <targetRef oid="5bb5c5b5-eca2-4129-b73f-34c0b0bd2736" type="PolicyType" />
                </requirement>
            </policyConstraints>
            <policyActions>
                <enforcement/>
            </policyActions>
        </policyRule>
    </inducement>
</policy>

The policy requires special security training to gain access to any category III system. The clearance will probably be awarded to individual users by security office.

As the categories are meant to form a hierarchy, the security requirements specified for the categories are cumulative. Access to category III systems can be granted only if all the explicit requirements for category III, category II and category I are satisfied. In our case, the access can be granted only if the user has both the NDA and special training clearance.

The policy specified in this way acts as an ultimate policy. As long as application roles are properly associated with applications, it does not matter how business roles are defined for the policy to work. In case that a business role includes wrong application role, which provides inappropriate access to sensitive application, such role cannot be assigned unless the required clearances are present. This is an implementation of multi-layer security policy, specifying rules that must be maintained at all times.

Application roles must have inducement to applications for the policy to work. This is a general best practice in all cases that application roles are used. The roles must have inducement to applications, even if applications are "empty", not containing any construction statements. The applications are the objects that link the classifications and the roles, therefore it is essential to maintain the link.

Privileged Access Classification

MidPoint contains a pre-defined classification Privileged access. This classification is meant to mark roles that provide privileged access to systems.

Privileged access
Privileged access is defined as entitlement which allows the performance of activities that typical entities in the system cannot perform. See Privileged entitlement.

Classification Privileged access is an ordinary midPoint classification in its essence. It is meant to classify application roles that represent privileged entitlements of identity resources, such as Domain Admins or root groups.

Further Tips

  • Classifications can be used to place requirements on users that have access to classified systems. E.g. Category III classification can be used to make sure that the users accessing category III systems have enrolled in multi-factor authentication. However, the details how the multi-factor authentication is set up is specific to authentication (access mamanegement) system used in conjunction with midPoint. MidPoint cannot enforce multi-factor authentication alone.

  • Classifications (labels) can be used to set up certification policies. E.g. certify access to category III systems every 6 months, certify access to category II annually and category I is certified bi-annually.

  • As clearances are assigned to users using ordinary assignments, access certification features can be used to regularly re-certify the clearances. Furthermore, the activation mechanisms of the assignment can be used to assign clearances for a limited time period.

Limitations

The concept of classifications and clearances is based on existing stable midPoint functionality of policy rules and meta-roles, therefore the policy enforcement is fully supported. However, there are limitation regarding visibility of the policy. The classification labels are visible for applications that they are directly assigned to, yet they are not visible for roles. Generally speaking, visibility of policy rules and their execution is somehow limited in current midPoint versions.

See Also

Compliance

This feature is related to the following compliance frameworks:

Was this page helpful?
YES NO
Thanks for your feedback