[SD] Best Practice Datenklassifizierung

In der Security Demopalooza adressiere ich #Security Themen, die in meiner täglichen Arbeit oft/öfter gefragt werden. Für eine Liste der bisher behandelten Themen besuche einfach die Übersichtsseite der Security Demopalooza.

Best Practice Datenklassifizierung

oder: Ich möchte Datenklassifizierung einführen, durch die unterschiedlichen Anforderungen der einzelnen Abteilungen (HR, Finance, Legal, Board, R&D, Marketing) bekomme ich aber unzählige Klassen, wie gehe ich mit dieser Thematik um? 

Wenn es um das Thema Datenklassifizierung geht bekommen wir meistens die gleichen Reaktionen:

• „Ugh, ne, das wollen wir zwar schon lange machen, ist uns aber zu aufwändig“
• „Das verstehen die User eh nicht“
• „Brauch ich nicht“

Um ehrlich zu sein überrascht mich, dass das Thema nicht deutlich verbreiteter ist – denn grade im Umgang mit der DS-GVO ist es alles andere als leicht konform zu sein und zu bleiben, wenn ich nicht weiß, welche Daten(typen) ich wo und wie verarbeite. Und genau dabei kann Klassifizierung helfen.

Außerdem wenn es darum geht „welche Prozesse werden auf welche Daten angewendet“ wird es praktisch unmöglich dies sinnvoll umzusetzen.

„Hä? Daten und Prozesse?“

Ganz einfach: welche Daten dürfen wo liegen, mitgenommen, verschickt werden? Wann sind Daten zu verschlüsseln und mit wem darf ich sie teilen? Wann müssen Daten gelöscht werden und wie lange muss ich bestimmte Daten aufheben?

Das sind alles Themen, die durch Datenklassifizierung gelöst werden können, denn auf eine Klasse können Tools reagieren und den User dabei unterstützen das Richtige zu tun oder gar verhindern etwas falsches zu tun.

Bei der Bedarfsanalyse von Datenklassen in Business Units bekommt man meist eine ganze Menge an Anforderungen, die sich ggf. nur marginal unterscheiden. D.h. es ist keine Seltenheit bei einem Kunden die Anforderung für 20-100 oder sogar noch mehr Klassen genannt zu bekommen.

Jetzt wäre es fatal, wenn der brave Implementierungspartner sagen würde „alles klar, hast du morgen.“!

Denn es muss dem User so einfach wie möglich gemacht werden!

Und das bedeutet, dass die Anzahl der möglichen „Standardklassen“ <10, besser sogar noch <=5 ist!

Und hier sollte auch nicht eingeknickt werden, sonst ist der Verwaltungsaufwand immens und die Useradoption praktisch 0.

Für den Labeling/Klassifizierungsansatz bei Microsoft bedeutet das, dass die für alle gültige „global policy“ am Besten nur 4 Klassen enthält [die Namen hier entsprechen den Microsoft Empfehlungen]:

• Public
• General
• Confidential
• Strictly Confidential

Ggf., wenn die private Nutzung erlaubt ist noch additiv „non-business“.

Bei einer solchen einfachen Struktur ist dem normalen Anwender zumutbar die Unterscheidung von „confidential“ zu „strictly confidential“ selbständig und mit der Unterstützung der „Description“ zu treffen.

Jetzt gibt es aber noch Business Units die mit Recht weiteren Bedarf an Klassen haben, z.B. Legal, Finance, R&D, HR, BR, Aufsichtsrat, Board, …

Für diese sollten eigene Policies angelegt werden, die nur auf die betreffenden Nutzergruppen angewendet werden und ggf. durch das Setzen von „default labeln“ unterstützt werden.

Die Definition der Label könnte also beispielsweise so aussehen:

Wichtig dabei ist, dass die Label NICHT für alle User sichtbar sind!
Das könnte dann z.B. so in Word aussehen:

Durch eine passende Konfiguration werden die notwendigen Einstellungen wie Verschlüsselung, Header/Footer/Wasserzeichen, etc. geregelt. Insb. bei dem Thema Verschlüsselung sollte es aber auch nicht übertrieben werden.
Auf die einzelnen Möglichkeiten möchte ich in diesem Post nicht eingehen, da es hier mehr um das „Drumherum“ geht.

Halten wir also fest:

1. Es mit der Anzahl der Labels nicht übertreiben
2. Labels auf User(gruppen) targeten
3. Es mit der Restriktion (=>Verschlüsselung) nicht übertreiben, damit die Useability insb. mit Externen nicht leidet
4. Nicht erwähnt aber auch wichtig: die MCAS und DLP Möglichkeiten nutzen um das Abwandern von Daten/Informationen zu verhindern
5. Weniger ist mehr!

Wer sich näher mit den Möglichkeiten und der Konfiguration von Microsoft Information Protection auseinandersetzen möchte, dem möchte ich folgende Links ans Herz legen:

• Video: Understanding how Microsoft Information Protection capabilities work together to protect sensitive info across devices, apps and services
• Azure Information Protection Deployment Acceleration Guide
• The Azure Information Protection unified labeling client is now generally available