Zertifizierung in der digitalen Transformation

In der IT kommt aktuell niemand an Digitalisierung, KI, Cloud-Computing und anderen technologischen Trends vorbei. All diese Trends stehen vor derselben Problematik: Es entsteht neuer Schutzbedarf aufgrund steigender Cyber-Kriminalität. Zertifizierungen sollen helfen, dem entgegenzuwirken, und das Vertrauen in die Produkte und die Sicherheit steigern. Welche Zertifizierungsmöglichkeiten existieren und welche Ziele diese verfolgen, verrate ich dir in diesem Artikel.

Die Cyber-Kriminalität hat längst internationale Ausmaße erreicht. Laut deutschem Verfassungsschutz sind alle russischen und auch chinesischen Dienste gesetzlich verpflichtet, Wirtschaftsspionage zu betreiben, siehe „Wirtschaftsspionage. Risiko für Unternehmen, Wirtschaft und Forschung“ .

Besonders kleine und mittlere Unternehmen (KMU) sind in letzter Zeit vermehrt Angriffen aus dem Ausland ausgesetzt. Für den Schutz der Bürger und Unternehmen in Deutschland ordnet der Gesetzgeber Regulierungen an, um sicherheitskritische Systeme und Infrastrukturen zu schützen. Er empfiehlt Unternehmen, Grundschutzmaßnahmen umzusetzen.

Parallel werden Zertifizierungen von Produkten angeordnet, um Datensicherheit, Datenschutz und Privatsphäre für Firmen und Bürger zu gewährleisten. Dazu zählt die Zertifizierung nach Common Criteria (CC).

Die CC-Zertifizierung ist ein international anerkanntes Verfahren, bei dem Systeme, ihr Lebenszyklus und ihre Dokumentation evaluiert werden. In der Praxis zeigen sich jedoch Schwachstellen dieser Herangehensweise.

Mit der Komplexität der Evaluierungsgegenstände einerseits und höheren Zertifizierungsniveaus andererseits steigt der Aufwand für Dokumentation und Evaluierung überproportional. Die Auslastung der Prüfstellen und Auditoren wächst außerdem durch die zunehmende Nachfrage. Damit die Zertifizierung erfolgreich eingesetzt werden kann, muss die Zertifizierung selbst die digitale Transformation durchlaufen.

Die Idee der Zertifizierung ist nicht neu. Für den IT-Bereich existieren unterschiedliche Definitionen. Eine davon entstammt dem Standard Glossary des IEEE aus dem Jahr 1990 und lautet:

Heute geht niemand mehr davon aus, dass es möglich ist, eine Garantie für die Sicherheit eines Systems zu geben. So werden zum Beispiel in der Zertifizierung nach Common Criteria das Vertrauen und die Vergleichbarkeit als Ziel definiert:

Außerdem soll die CC bei der Entwicklung, Evaluierung und Auswahl von IT-Produkten unterstützen. Der Fokus der CC liegt auf der Zertifizierung von Hardware- und Softwareprodukten. Es können aber auch Methoden, Entwicklungsumgebungen und andere Gegenstände zertifiziert werden.

Im Folgenden werden einige beispielhafte Zertifizierungen kurz vorgestellt, um die Diversität und die Problemstellungen von Zertifizierungen zu verbildlichen. Anschließend wird die CC-Zertifizierung ausführlicher beschrieben, da diese als Obermenge von Zertifizierungen angesehen werden kann.

• Payment Card Industry Data Security Standard – PCI-DSS

  Verarbeitet oder speichert ein Unternehmen Kreditkartentransaktionen, ist es verpflichtet, die Regelungen des “Payment Card Industry Data Security Standards” (PCI-DSS) zu erfüllen. Dieser Standard wurde von mehreren internationalen Kreditkarten-Institutionen eingeführt, um finanzielle Schäden abzuwenden. Für die Zertifizierung müssen zwölf Anforderungen, aufgeteilt in sechs Bereiche, erfüllt werden, welche in einem Audit durch Gutachter regelmäßig geprüft werden.

  Die Häufigkeit der Re-Zertifizierung richtet sich nach dem Volumen der Transaktionen und der Häufigkeit der Angriffe auf das jeweilige Unternehmen. Den Schaden bei Finanzunternehmen kann das Management recht einfach beziffern. Solche Unternehmen haben bereits freiwillig eine verpflichtende Zertifizierung eingeführt, wodurch kein Eingreifen durch die Gesetzgeber nötig wurde.

  Am Beispiel der PCI-DSS-Zertifizierung erkennen wir, dass bei einer Zertifizierung kein konkretes Produkt adressiert wird. Stattdessen betrifft die Zertifizierung Infrastruktur, Strukturen und Prozesse.

• Technische Richtlinien – TR

  Eine Zertifizierung nach technischen Richtlinien (TR) wird immer dann erforderlich, wenn IT-Systeme und -Produkte in sicherheitskritischen Bereichen der Bundesrepublik Deutschland eingesetzt werden. Die Richtlinien selbst werden vom Bundesamt für Sicherheit in der Informationstechnik (BSI) bei Bedarf erstellt und definieren Anforderungen an Fälschungssicherheit, Betriebszuverlässigkeit und Interoperabilität von IT-Systemen und -Produkten.

  Die Evaluierung wird durch unabhängige, vom BSI akkreditierte Prüfstellen durchgeführt. Die Evaluierungsgegenstände können unterschiedlich beschaffen sein, zum Beispiel Verschlüsselungsalgorithmen, sichere Netzwerke oder bestimmte Dienste. Die große Vielfalt verschiedener TR und die Varianz der Produkte erhöht die Anforderungen an die Werkzeuge der Gutachter, da mit jeder neuen Richtlinie gegebenenfalls neue Klassen von Anforderungen aufgestellt werden.

• IT-Grundschutz

  Die Zertifizierung nach IT-Grundschutz wird für alle Unternehmen empfohlen. Für kritische Infrastrukturen der Bundesrepublik (KRITIS) ist die Absicherung sogar verpflichtend:

  Mit dem im Juli 2015 verabschiedeten IT-Sicherheitsgesetz werden Betreiber Kritischer Infrastrukturen verpflichtet, die für die Erbringung ihrer wichtigen Dienste erforderliche IT nach dem Stand der Technik angemessen abzusichern. Antworten zu häufigen Fragen zum IT-Sicherheitsgesetz finden Sie in der FAQ des BSI.

  Als Basis-Dokument empfiehlt das BSI sein IT-Grundschutz-Kompendium. Es ist ein umfangreiches Dokument, welches in die Beschreibungen von Prozessen, Anwendungen und IT-Systemen aufgeteilt ist.
  
  Zusätzlich stellt die Allianz für Cyber-Sicherheit (ACS) verschiedene Profile für unterschiedliche Unternehmenstypen zur Verfügung. Diese Profile dienen als Leitfaden für die Modellierung des jeweiligen Unternehmens.
  
  Für eine solche Modellierung aus der Sicht des IT-Grundschutzes müssen aus dem IT-Grundschutz-Kompendium zutreffende Bausteine ausgewählt und die darin empfohlenen Maßnahmen umgesetzt werden.
  
  Unter anderem gehören KMU zur Zielgruppe des IT-Grundschutzes. Da der Detailgrad beziehungsweise die Dokumentation sehr umfangreich ist, sind die meisten KMU gar nicht in der Lage, diesen Umfang zu bewältigen, und können sich folglich nicht angemessen absichern.
  
  Außerdem ist IT-Grundschutz keine Aufgabe, die einmalig ausgeführt als abgeschlossen angesehen werden kann. Er ist ein Prozess, bei dem die Überprüfung der Gegebenheiten wiederholt durchgeführt werden muss. Veränderungen in den Empfehlungen des BSI oder in den Strukturen des Unternehmens erfordern eine Neubewertung des Schutzbedarfs und gegebenenfalls eine Umsetzung neuer Maßnahmen.
  
  An dieser Stelle wird offensichtlich, dass IT-Grundschutz durch geeignete Werkzeuge unterstützt werden muss.

• Common Criteria – CC

  Die Zertifizierung nach Common Criteria (CC-Zertifizierung) wird international von den meisten Industrienationen anerkannt. Die Akteure und die Kommunikationswege zwischen ihnen sind in Abbildung 1 (siehe unten) dargestellt.
  
  Auftraggeber einer Zertifizierung ist ein Hersteller (Manufacturer). Unabhängige und nicht weisungsgebundene Prüfstellen und Gutachter (Evaluation Body) führen die Zertifizierung anhand öffentlich bekannter Sicherheitskriterien durch.
  
  Grundsätzlich soll die Zertifizierung Vertrauen in das Konzept und in die Umsetzung schaffen.

  Der Prozess beginnt damit, dass der Manufacturer eine geeignete Prüfstelle für die Zertifizierung seines Produktes finden muss. Die Herausforderung bei der Suche besteht darin, eine Prüfstelle mit entsprechendem Know-how und Ausstattung zu finden. Die Prüfstelle muss zum Beispiel bei der Zertifizierung von Chipkarten in der Lage sein, Seitenkanalangriffe durchzuführen. Dafür benötigt sie Elektronenmikroskope und darauf geschulte Evaluatoren.
  
  Hat der Hersteller eine geeignete Prüfstelle gefunden, kann er den Antrag auf Zertifizierung beim BSI einreichen. Stimmt das BSI zu, kann die Evaluierung beginnen.
  
  Während der Evaluierung muss der Hersteller den von der Prüfstelle benannten Gutachtern neben dem Produkt (Target of Evaluation – TOE) einen umfangreichen Satz von Dokumenten sowie das Testkonzept mit der Testumgebung liefern.
  
  Anhand des gelieferten Materials erstellen die Gutachter Prüfberichte, welche beim BSI (Certification Body) durch zuständige Mitarbeiter geprüft werden. Sind alle Artefakte begutachtet und erfüllen sie die Anforderungen, wird ein Zertifikat für das Produkt ausgestellt und veröffentlicht.

  Abbildung 1: Kommunikationswege und Prozess der CC-Zertifizierung

  Auf einer anderen Ebene betrachtet, besteht der Zertifizierungsprozess aus drei Phasen.
  
  Wie in Abbildung 2 (siehe unten) dargestellt, wird in der ersten Phase ein Schutzprofil (Protection Profile – PP) entworfen, in der Regel durch ein Konsortium. Dieses Schutzprofil wird durch eine Prüfstelle evaluiert. Es beschreibt die Anforderungen an eine Gruppe von Produkten. Damit soll sichergestellt werden, dass die Evaluierungsergebnisse von Produkten unterschiedlicher Hersteller vergleichbar sind.
  
  Das Schutzprofil beinhaltet in der Regel eine Obermenge von Funktionalitäten, die ein TOE prinzipiell umsetzen kann. Als Beispiel können die Schnittstellen eines Kartenterminals herangezogen werden; ein Kartenterminal kann verschiedene Schnittstellen besitzen, zum Beispiel USB, LAN oder NFC. Alle Schnittstellen werden in das Profil aufgenommen, und die entsprechenden Sicherheitsanforderungen an sie erfasst. Die Hersteller sind jedoch nicht verpflichtet, alle Schnittstellen umzusetzen.

  Basierend auf dem Schutzprofil erstellt in der zweiten Phase jeder Hersteller für sein Produkt sein Sicherheitsziel (Security Target – ST). Das ST kann vollständig das Protection Profile übernehmen.
  
  Wurden nicht alle Schnittstellen aus dem PP übernommen, müssen nur die Sicherheitsvorgaben und Anforderungen für die geplanten Schnittstellen des TOE betrachtet werden.
  
  Das Security Target ist das Versprechen des Herstellers, das die Funktionalität und die Sicherheitsvorgaben für sein Produkt beschreibt. Die Evaluierung des Security Targets erfolgt äquivalent zum Protection Profile.

  In der dritten und letzten Phase wird das Produkt anhand des Security Targets evaluiert.

  Abbildung 2: Drei Phasen der CC-Zertifizierung.

  Die zeitintensivste Phase ist die Dritte. In dieser Phase wird abhängig vom Evaluation Assurance Level (EAL 1–7) eine definierte Menge von Dokumenten, Tests und Nachweisen gefordert, wie in folgender Tabelle dargestellt:

  Abbildung 3

  Die Zeilen der Tabelle listen die Dokumente für die Evaluierung auf. In den Spalten der EAL-Stufen wird die Ausprägung der Dokumente gemäß der CC-Anforderungen angegeben. Damit ist die Menge der Dokumente und die Erwartung an ihren Inhalt für jede EAL-Stufe fixiert.
  
  Die Dokumentation wird fortlaufend mit der Entwicklung des TOE erstellt. In der Common Evaluation Methodology (CEM) sind Abhängigkeiten zwischen den Dokumenten definiert, indem die Evaluierung jedes Dokuments bestimmte andere Dokumente oder Artefakte als Eingabe voraussetzt.
  
  So wird zum Beispiel für die Evaluierung der funktionalen Spezifikation neben der Spezifikation selbst das ST und das Benutzerhandbuch vorausgesetzt. Die Abhängigkeiten zwischen den Dokumenten geben die Bearbeitungsreihenfolge vor, in der die Evaluatoren die Dokumente erhalten müssen.
  
  Ein Beispiel für die Dokumentenlandschaft der EAL 5 lässt sich wie folgt darstellen:

  Abbildung 4

  In der Abbildung werden im Security Target enthaltene Sicherheitsanforderungen A-D (Security Functional Requirement, SFR) angedeutet, die der Hersteller bei der Evaluierung des ST als verpflichtend in sein Sicherheitskonzept aufgenommen hat.
  
  Bei der Umsetzung und Evaluierung des TOE muss die Erfüllung all dieser Anforderungen nachgewiesen werden.
  
  Hierfür muss jede Sicherheitsanforderung zunächst zum Beispiel im Systemdesign als Komponente beschrieben sein, in die Sicherheitsarchitektur einfließen und abschließend durch Tests nachgewiesen werden.
  
  Die Herausforderung bei der Evaluierung der Dokumente besteht sowohl für die Entwickler als auch für den Evaluator darin, die extrem großen dokumentübergreifende Mengen von SFRs zu verwalten.
  
  Bei Änderung an einer beliebigen Stelle in der Dokumentation oder im TOE wird stets die Konsistenz über alle Artefakte hinweg synchronisiert und geprüft. Für den Abschluss der Evaluierung müssen die vollständige Dokumentation und das Produkt mit fixierten Versionen final vorliegen. Für exakt diese Version des Produktes wird dann ein Zertifikat erteilt.

Wie wir gezeigt haben, existieren unterschiedliche Zertifizierungsverfahren, welche unterschiedliche Ziele verfolgen. Wir können Infrastrukturen, Methoden, Produkte oder deren Lebenszyklus zertifizieren, wobei die CC-Zertifizierung in diesem Zusammenhang als Beispiel für eine Obermengenzertifizierung angesehen werden kann.

All diese Zertifizierungen sollen helfen, der Cyber-Kriminalität entgegenzuwirken und das Vertrauen in die Produkte und die Sicherheit steigern. Leider sind die Hürden für eine Zertifizierung sehr hoch. Wir möchten die Zertifizierung verbessern, indem wir diese durch geeignete Werkzeuge digitalisieren.

Wie wir uns das vorstellen, erfährst du im nächsten Blogbeitrag, wenn es heißt „Digitalisierung der Zertifizierung durch geeignete Werkzeuge“.

Hast du zu meinem Blogartikel noch Fragen? Hinterlass mir gerne deinen Kommentar!