BIO and MPIP together

Reading time: 20 minutes

The BIO is a set of guidelines for organizations in the public sector. This article explores a set of these guidelines as related to information protection.

Introduction

The Baseline Informatiebeveiliging Overheid [BIO] is the Dutch governmental information security guideline. It offers organizations in the public sector a framework of standards to correctly regulate the security of (sensitive) information. The most recent version 1.04 was expanded some time ago with specific cloud regulations (themadocument Cloud Diensten).

In this article, I combine the two to form the BIO. I want to give my interpretation of the BIO as related to the Microsoft Purview options for information protection. At the end of this article, I’ve included several tips and tricks. Please view this article as my take on this subject and as a “brain dump” of ideas.

Laws and regulations

The new, modern Microsoft 365 workplace is characterized by, among other things, the amount of information that is stored, accessed, processed, and exchanged. In the context of governmental organizations, we see a complex intertwined world of civil service, city council (mayor & aldermen), regional government, MPs, citizens, partners, suppliers, other municipalities, safety regions, water boards, and much more. And Microsoft 365 offers the world a nearly unlimited portfolio of options for sharing information.

But international and national laws and regulations require that appropriate processes and technical measures are taken to ensure the availability, integrity, and confidentiality of information, information systems, and privacy. Examples include the Baseline Information Security Government (BIO), NEN 7516, various laws governing records management (in Dutch: Archiefwet), ISO9001/ISO9002, GDPR, Freedom of Information Act (in Dutch: Wet Open Overheid) and Wet Openbaarheid van Bestuur).

The correct design of the Microsoft & Office 365 environment is essential to comply with the various laws and regulations. This includes the measures, processes, and expertise in the privacy, security, and risk management field.

Setting the scope

We must recognize that the aforementioned laws and regulations (in particular the GDPR) also affect the design of Microsoft 365 and the information security functions within it. For example, linking the sensitivity of information (BIO) with the correct retention period (Archiefwet). Or the protection of particularly privacy-sensitive data (GDPR and BIO).

Although the scope of this article is limited to the BIO in relation to MPIP, for the BIO the entire Microsoft Purview compliance & Risk portfolio must be considered.

For example, there are conceivable scenarios in which information may not be shared within the organization or where a data breach is highly undesirable. For example, the appointment of a new mayor. The cooperation and separation between council members, the mayor, and the civil service are also very specific. This must be taken into account during the design. Protection against data leakage, setting information boundaries, and secure communication is just a few additional components within the portfolio.

Shifts in IT security

The Confidentiality, Integrity, and Availability (CIA) of information and communication are guaranteed by using the right processes, and technical resources and creating awareness among employees. This also includes the optimal protection of (medical/legal/special) privacy-sensitive information and the prevention of internal and external threats. The standards framework of the BIO is based on this.

But the cloud presents us with specific challenges. In the traditional on-premises environment, the identities, information, and equipment (servers, networks, workstations) are centrally managed and mainly protected against external attacks. The management processes are also set up for this. Within the cloud environment, we see a shift. Information is accessed from any device, from any location, and at any time. Information is also easily shared with external parties.

In order to ensure that information is and remains optimally secured, access to it is increasingly based on the principle of verifying instead of trust: Zero Trust. Proper classification and security need to ensure that information is only accessible when the user, location, and risks are verified.

Baseline Informatiebeveiliging Overheid

The BIO is a specific Dutch regulation. However, it is primarily based on ISO27001/27002. Many or even all of the controls in the BIO can be related back to the ISO controls. However, the BIO does include specific guidelines on how to handle sensitive information.

The articles within the BIO fall under a so-called “apply-or-explain” principle. They can be supported by setting up the right control and security measures. The most relevant chapters for this article are classification of information (chapter 8), encryption (chapter 10), and communication security (chapter 13).

From a Microsoft Purview perspective, three components are in scope for these chapters; MPIP, Office 365 Message Encryption, and the possibilities for keeping the encryption keys in-house. In this article, I will go into these.

Information classification in general

Information protection ensures that information is not accessible to unauthorized persons. This is possible, among other things, by classifying and encrypting information. In addition, access to the information is also protected and data leakage is prevented.

Most regulations include a section on data classification in the Asset Management control family. For example the ISO27001 and the BIO.

As such, governmental organizations are not new to classification schemes. Although the handling of classified information might leave something to be desired.

In The Netherlands, the central government uses the EU/NATO model for the classification of information. This model uses two distinct levels of classification. Either the information is confidential or not. In which case it is deemed “Unclassified”. The model in a nutshell (Dutch | EU | NATO):

Unclassified
Departmental – confidential – EU Restricted – NATO Restricted
State secret – confidential – EU Confidential – NATO Confidential
State secret – secret – EU Secret – NATO Secret
State secret – top secret – EU Top Secret – Cosmic Top Secret

The Unclassified level concerns information where the sensitivity does not meet the requirements for any higher classification. It can still be confidential, but from a governmental standpoint, the level of confidentiality is low.

For this article, the only information that falls within the first two classification levels is relevant. Information with a higher classification may not be stored in a (public) cloud environment. And as this article relates to Microsoft 365 and Purview, this type of information is not relevant.

Basic Security Levels (BBN)

How does this general classification model map to the BIO? First off, we must realize that the classification of information is only a part of the BIO controls. There are many more controls and these relate to the Confidentiality, Integrity, and Availability [CIA] of information.

In order to set these controls, the BIO uses the basic security levels (or Basis Beveiliging Niveaus – BBN). There are three levels: BBN1, BBN2, and BBN3. Based on a risk assessment and other factors, information of a certain BBN level is or is not allowed to be stored in the cloud.

	BBN1	BBN2 Unclassified	BBN2 Departmental confidential	BBN3
Examples	Website material	Contracts, project information, and so on.	(Medical) privacy sensitive information, information about IT systems,	State secrets
Cloud?	Permitted	Permitted provided . . .	Not permitted unless . . .	Not allowed

Note the difference within the BBN2 level. A risk-based approach is needed to determine if information can be stored in the cloud. For this article, I will use the BBN2 level as the starting point for most information systems within governmental organizations. Any organization that prides itself to be part of a “reliable government” should use this level as a minimum. The sensitivity of this type is information is such, that any leakage or other incident may cause disturbances or commotion.

The BBN levels relate to the general classification scheme as described above.

Measures taken for the BBN2 level should ensure that both unclassified information and information of the level “Departmental – confidential (DepV)” is secure. The level BBN3 runs from the level “Departmental – confidential (DepV)” and higher.

For this article, level BBN3 is irrelevant. The classification level of this type of information is such that it cannot and may not be stored in (public) cloud environments.

Also note that regardless of the BBN level (1,2 or 3), information is to be classified. For example, Articles 8.2.1 and 8.2.2 of the BIO state:

Information should be classified with respect to legal requirements, value, importance, and sensitivity to unauthorized disclosure or alteration;
To label information, an appropriate set of procedures should be developed and implemented in accordance with the data classification scheme established by the organization.

The classification of information and the BIO’s own BBN levels can be confusing. To assist in the determination of the BBN level and information classification, a specific Excel sheet has been developed. You can find this here: https://www.informatiebeveiligingsdienst.nl/product/baselinetoets-bbn-bio/

Relating the BIO with MPIP

So how can we relate the BIO with the Microsoft Purview Information Protection labels? Let’s start with a very generic model. This model is based on the governmental levels for classification. Again; the extent to which information from the departmental–confidential level is stored in the cloud and which data classification level applies, in this case, is determined on the basis of a risk/impact analysis.

Please note: I’m not a very big supporter of a label called “Internal”. In this model, I’ve chosen to go for “General”. The main reason for this: being able to explain these labels to our workers. It’s very hard to explain a label called “Internal” when this is added to information that can also be shared with external parties. For example.

Using this model, we can use both the labeling from MPIP and bring this in line with the BIO. However, the model is still very generic which limits the model. And this goes for most models that only work with top-level labels.

Unstructured information within the organization is not easy to capture in a generic model. It is therefore not easily scalable for both internal use and use in (external) collaborations.

But let’s use this model as a starting point for setting up an MPIP label taxonomy. This taxonomy is applicable to documents, e-mail messages, SharePoint Online sites, and Microsoft Teams environments.

Expanding the label model (BIO chapter 8)

As stated above, this basic level is insufficient. It does not offer the possibility to differentiate sufficiently. It is therefore extended with specific additional levels of classification levels. For very specific use cases, this taxonomy can be enhanced even further. Based on the BIO and my expertise, I would recommend the following taxonomy:

In this model, I haven’t separated these labels into specific policies – which will make sense. Using this model, we can use the MPIP security measures for encryption and restrictions on access. Further differentiation is possible for specific groups – for example, the Internal Audit department.

Encryption (BIO chapters 10/13)

Encryption is discussed in chapter 10 of the BIO. A more recent Data Privacy Impact Analysis [DPIA] performed for the Dutch government also mentioned the use and prerequisites for encryption within governmental organizations.

MPIP provides both document encryption and encrypted messaging. Document encryption uses a hybrid model with both symmetric (AES 128/256 bits) and asymmetric (RSA 2048 bits) encryption and hashing (SHA256). Information Rights Management (IRM), Secure/Multipurpose Internet Mail Extensions (S/MIME), and Office Message Encryption (OME) are used to apply e-mail message encryption.

Information Rights Management	Used when additional rights must be given to the e-mail message. For example, “do not print” or “do not forward” and/or when the same should apply to the attachments.
S/MIME	Used in peer-to-peer encryption scenarios. For example, between government agencies.
Office 365 Message Encryption	Used when sensitive information needs to be shared via email with people outside the organization. These people do not have to install separate software or make specific settings.

The BIO (and the DPIA) address the subject of key management. The processes for key management, including the maintenance and storing of encryption keys, need to be the responsibility of the governmental organization. In The Netherlands, we have the PKIOverheid, which provides certificates and keys for these types of organizations.

Encryption in Microsoft 365 and MPIP uses a so-called Microsoft Azure managed key. The encryption key(s) are managed by Microsoft and this does not comply with the BIO and DPIA. Other options are the concept of Bring Your Own Key and Double Key Encryption.

Double Key Encryption offers the best protection and complies with the BIO and DPIA. However, this option does have disadvantages. For example, this type of encryption only works within MPIP and Office documents. Also, several other compliance components (eDiscovery) will break when using Double Key Encryption.

In my opinion, the Bring Your Own Key option (also known as Customer Key) is best when the organization needs to manage the encryption keys. These are stored in the Microsoft environment (Azure Key Vault), with additional high-end hardware security modules (HSMs).

Conclusions and recommendations

The BIO provides organizations with guidance on how to shape information security. Based on the standard guide, however, it is often difficult to shape this. This article outlines a solution with which MPIP can be set up and is in line with the guide.

For further implementation, start from the risk that needs to be mitigated, set up use cases, and enhance the basic model for labels. Use the knowledge and expertise within the organization for this.

Avoid the pitfall of securing all information and all sources of information in one big bang;

Crawl: Evaluate the model in this article. Determine additional requirements for additional labels and settings. Create use cases and ultimately use them to test and evaluate functionality. Start small and grow quickly. Protect the most sensitive information directly. Start with an awareness program.
Walk: Build on the functionality based on previous experiences. Think of specific labels and settings.
Run: expands functionality by introducing automated classification and detection of sensitive information and linking to additional platforms. Actively control the use of the labels with the help of available dashboards.

Information security is not a purely technical exercise. As article 7.2.2 of the BIO already indicates:

All employees of the organization and, to the extent relevant, contractors should receive appropriate awareness education and training and regular further training of policies and procedures of the organization, to the extent relevant to their function.

Information security still involves humans working with that information. And people consciously or unconsciously make mistakes.

General MPIP recommendations

Where necessary, use the so-called Rights management connector to provide on-premises Exchange environments with information security;
Use recognizable names for the labels – as included in this article;
Avoid using sensitive terms in the label (“Reorganisation department X”);
Use child labels (“sub-labels”) for specific use cases; However, establish a transparent process for using this label. When should a project, team, or detailed information be sub-labeled? And record the process for requesting/creating sub-labels and policies;
Offer a clear level of labels (up to five) and use policies for this;
Do not change the labels frequently and announce new labels in a timely and complete manner;
Use auto-labeling for both the employee (while working on information) and in the background (SharePoint Online, OneDrive for Business);
If the environment is used by employees in multiple geographic locations and languages, use multilingualism (Publiek | Public | Öffentlich);
The use of a default label reduces the burden on employees to classify information. However, please note; There is a risk that employees will no longer take into account the actual sensitivity of the information;
It is possible to set a different default label for documents and email messages. As a result, these do not have to be the same;
Start with the data classification and security model mentioned in this document;
Extend this model for specific information, processes, and departments;
Quickly extend the model to a data classification model for containers (SharePoint Online, Microsoft Teams) and the corresponding settings for accessing information;
Properly record the responsibilities of Microsoft and its own organization around the management of keys;
Use the dashboards available in Microsoft Compliance Center to request information about the use of sensitive information;
Set up rules for data loss prevention;
Extend the model to other information storage locations, using Azure Purview and Microsoft Defender for Cloud Apps;
Extend the model to the employee’s devices (telephone, laptop), so that sensitive information is also safe there;
Work with automated detection of sensitive information to simplify classification;
Use Office 365 Message Encryption for standard email security. For example, for the security of outgoing e-mail messages;
Use the Microsoft Compliance Manager and Compliance Score to view and recommend compliance within the Microsoft 365 tenant.

Tips and tricks

Tip 1 – Active Directory

The encryption of information within Microsoft 365 requires accounts in the Azure Active Directory at all times. This has consequences for sharing information with people outside the organization. There’s a good chance that these people won’t be able to open a document. Take this into account when designing the labels.

Tip 2 – Office attachments are encrypted

When an unprotected Office document is sent as an attachment with a protected e-mail message, this document is also encrypted. Opening this document in a Microsoft Office application is then only possible if the recipient has an Azure Active Directory account or the attachment is decrypted during downloading it (to be set by the admins).

Tip 3 – Share and protect

Sharing a document from OneDrive for Business, SharePoint Online (and Teams) using the One-Time-Passcode method (default) can prevent a protected document from being opened. Again, this is due to the Azure Active Directory account. The solution to this is to work with guest-user accounts.

Tip 4 – Working with PDF documents

MPIP is not able to protect encrypted or signed PDF documents. The standard Adobe software or Microsoft Edge is enough to open (MPIP) protected PDF documents.

Tip 5 – Working together in documents

Activate the option to enable Microsoft office collaboration and auto-save for encrypted documents. This is not (currently) the case by default. This option changes the metadata model for documents. Pay attention to this if there are systems that use this metadata, for example, non-Microsoft solutions for data loss prevention.

Tip 6 – Labels at container level

Note that a label or container level (SharePoint Online site and Microsoft Teams environment) does not affect the information within this container. If a certain group of employees has to use a certain type of label by default, realize this via a label policy and not with a container label. You can set a default sensitivity label on a document library.

These are my thoughts on the subject. If you have any to share, please do so in the comments. I might be wrong or have a different approach. But I love to hear yours.