Skip to content

Commit

Permalink
Classification and clearances
Browse files Browse the repository at this point in the history
  • Loading branch information
@semancik
semancik committed Mar 12, 2024
1 parent f2d0d1b commit b176007
Showing 1 changed file with 290 additions and 0 deletions.
290 changes: 290 additions & 0 deletions docs/roles-policies/classification/index.adoc
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,290 @@
= Information Classification and Clearances
:page-toc: top
:page-nav-title: Classification
:page-since: "4.8.3"
:page-upkeep-status: yellow
:page-feature: information-classification
:page-type: intro

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 xref:../schema/archetypes/[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 completion of security trainings, non-disclosure agreements (NDA) in place, formal government clearances or professional certifications.
Clearances allow access to classified applications.

The actual mechanism is based on combination of xref:../metaroles/[meta-roles] and xref:../policy-rules/[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.

== 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 https://www.slov-lex.sk/pravne-predpisy/SK/ZZ/2018/362/#prilohy[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
[source,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
[source,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
[source,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
[source,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
[source,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 xref:../policy-rules/[policy rule] for this purpose:

.category-2.xml
[source,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>
<!-- 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 xref:../metaroles/[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
[source,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
[source,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>
<!-- 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:

.special-security-clearance.xml
[source,xml]
----
<org oid="03a7128d-42c8-4056-9f2e-171658562eeb">
<name>Chief Audit Office</name>
<inducement>
<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.

NOTE: 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.

== Limitations

The concept of classifications and clearances is based on existing stable midPoint functionality of xref:../policy-rules/[policy rules] and xref:../metaroles/[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

* xref:../policy-rules/[]

* xref:../metaroles/[]

0 comments on commit b176007

Please sign in to comment.