Information Classification and Clearances
Last modified 15 Apr 2024 11:24 +02:00
Information classification feature
This page is an introduction to Information classification midPoint feature. Please see the feature page for more details.
EXPERIMENTAL
This feature is experimental. It means that it is not intended for production use. The feature is not finished. It is not stable. The implementation may contain bugs, the configuration may change at any moment without any warning and it may not work at all. Use at your own risk. This feature is not covered by midPoint support. In case that you are interested in supporting development of this feature, please consider purchasing midPoint Platform subscription.
Since 4.8
This functionality is available since version 4.8.
Table of Contents
For midPoint 4.8, this considered an experimental functionality. The mechanism works in midPoint 4.8 as described here, and they are based on stable functionality. However, it is planned that the mechanism will be updated for a more modern approach in midPoint 4.9. Some changes to configuration will be needed when upgrading information classification configuration to midPoint 4.9.

+ MidPoint deployments that expect extensive use of information classification capabilities should wait for release of midPoint 4.9 and base their configuration on improved mechanisms.

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

The configuration is based on two basic 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, formal government clearances or professional certifications, user categories (internal/external). Clearances 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 user assignments.

Sample definition of the archetypes for midPoint 4.8 can be found in midPoint samples for version 4.8.

The definitions of Classification and Clearance archetypes provided for midPoint 4.8 are experimental. They are based on midPoint 4.8 mechanisms only. Improvements planned for midPoint 4.9 and 4.10 are likely to impact the way the archetypes are defined, therefore the definition of these archetypes in is almost certain to change. This is likely to affect upgrade of information classification functionality from midPoint 4.8 to later versions. Manual upgrade steps are likely to be required.

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 qualified 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 users that have completed basic cybersecurity training.

  • Access to Category III systems can be provided only to users that have been explicitly cleared by security office.

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.

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

category-1.xml
<role 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>
</role>
category-2.xml
<role 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="RoleType"/>
    </inducement>
</role>
category-3.xml
<role 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="RoleType"/>
    </inducement>
</role>

Now we can classify the applications. We can assign classification categories to applications using ordinary assignments:

app-sensitive-register.xml
<service oid="1a0b9b4b-dd86-464c-b077-9b9971424351">
    <name>Sensitive Register</name>
    <description>Database containing sensitive data.</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="RoleType" />
    </assignment>
</service>

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 basic cybersecurity training. Therefore, we need to specify a clearance for basic cybersecurity training first.

basic-cybersecurity-training.xml
<role oid="5bb5c5b5-eca2-4129-b73f-34c0b0bd2736">
    <name>Basic cybersecurity training</name>
    <description>Clearance that attests that the user passed through training of basic information security practices.</description>
    <assignment>
        <!-- Clearance archetype -->
        <targetRef oid="00000000-0000-0000-0000-000000000331" type="ArchetypeType"/>
    </assignment>
</role>

We will assign this clearance to users that have completed the training. The clearance can be assigned in any way that midPoint supports. E.g. it may be assigned manually after the training is completed, 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 cybersecurity training, 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
<role 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="RoleType"/>
    </inducement>
    <inducement>
        <orderConstraint>
            <order>2</order>
        </orderConstraint>
        <policyRule>
            <name>required-cybersecurity-training</name>
            <policyConstraints>
                <hasNoAssignment>
                    <presentation>
                        <message>
                            <fallbackMessage>Cybersecurity training required</fallbackMessage>
                        </message>
                    </presentation>
                    <!-- Basic cybersecurity training clearance -->
                    <targetRef oid="5bb5c5b5-eca2-4129-b73f-34c0b0bd2736" type="RoleType" />
                </hasNoAssignment>
            </policyConstraints>
            <policyActions>
                <enforcement/>
            </policyActions>
        </policyRule>
    </inducement>
</role>

The policy rule prohibits assignment of privilege (policyAction=enforce) in case where the user does not have Basic security training clearance already assigned. The policy rule is specified in second-order inducement, therefore it is applied to all applications that have the Category II classification. The second-order inducement is the usual mechanism used in configurations based on meta-roles, such as this one.

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

special-security-clearance.xml
<role oid="147a93c6-c8c3-4430-9603-659ffeb5e544">
    <name>Special security clearance</name>
    <description>Special clearance awarded by security office, allowing access to sensitive information.</description>
    <assignment>
        <!-- Clearance archetype -->
        <targetRef oid="00000000-0000-0000-0000-000000000331" type="ArchetypeType"/>
    </assignment>
</role>

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

category-3.xml
<role 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="RoleType"/>
    </inducement>
    <inducement>
        <orderConstraint>
            <order>2</order>
        </orderConstraint>
        <policyRule>
            <name>required-special-clearance</name>
            <policyConstraints>
                <hasNoAssignment>
                    <presentation>
                        <message>
                            <fallbackMessage>Special security clearance required</fallbackMessage>
                        </message>
                    </presentation>
                    <!-- Special security clearance -->
                    <targetRef oid="147a93c6-c8c3-4430-9603-659ffeb5e544" type="RoleType" />
                </hasNoAssignment>
            </policyConstraints>
            <policyActions>
                <enforcement/>
            </policyActions>
        </policyRule>
    </inducement>
</role>

The policy requires special clearance to gain access to any category III system. The clearance will probably be awarded to individual users by security office. However, some job roles or organizational units may be cleared implicitly, given by the nature of their job. For example, the clearance may be awarded automatically to all members of Chief Audit Office organizational unit. The usual inducement can be used for that:

chief-audit-office.xml
<org oid="03a7128d-42c8-4056-9f2e-171658562eeb">
    <name>Chief Audit Office</name>
    <inducement>
        <!-- Special security clearance -->
        <targetRef oid="147a93c6-c8c3-4430-9603-659ffeb5e544" type="RoleType" />
    </inducement>
</org>

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 security training and special 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.

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