
Common Criteria for Information Technology Security Evaluation
19. August 2024
Ein internationaler Standard
In Deutschland ist das Bundesamt für Arzneimittel und Medizinprodukte (BfArM) grundsätzlich zuständig für die Zulassung von Medizinprodukten und formaler Ansprechpartner beim Thema (Patienten-)Sicherheit, worauf auch Schwachstellen aus dem Bereich Cybersecurity Einfluss haben können. Die für IT-Sicherheit zuständige und kompetente Behörde ist hingegen das Bundesamt für Sicherheit in der Informationstechnik (BSI), welches sich auch im Rahmen seiner Aufgaben gemäß §3 BSIG an der Erarbeitung technischer Standards beteiligt. Für die Organisation und Dokumentation der Security-Prozesse von Medizintechnikherstellern sind gerade diese Standards auch deshalb relevant, weil das BSI gemäß §85(5) MPDG auch für das BfArM die Fachexpertise bereitstellt, d. h. es berät, meldet bei Bedarf proaktiv konkrete Schwachstellen an das BfArM und nimmt technische Bewertungen von Sachverhalten vor, welche dann die Grundlage für Entscheidungen des BfArM z. B. für Rückrufe oder Auflagen bilden.
Einen wesentlichen solchen Standard stellen die Common Criteria for Information Technology Security Evaluation (CC) und die ergänzende Common Methodology for Information Technology Security Evaluation (CEM) dar. Die CC und CEM sind ein international anerkannter Standard, an welchem neben dem BSI auch für IT-Sicherheit zuständige Behörden weiterer Staaten – von Japan über Europa bis zu den USA – sowie ISO und IEC mitgewirkt haben. Er ist in der aktuellen Fassung von 2022 frei verfügbar und wird zusätzlich als ISO/IEC 15408-1:2022 bis ISO/IEC 15408-5:2022 bzw. ISO/IEC 18045:2022 verlegt.
Die Standards sollen helfen, die für IT-Sicherheit relevanten Aspekte eines Produkts so darzustellen, dass ein einheitliches Verständnis zwischen Hersteller und nicht an der Entwicklung beteiligten Stellen hergestellt werden kann und eine unabhängige und einheitliche Prüfung ermöglichen. Damit kann der Standard auch dazu beitragen, Missverständnisse zu vermeiden und das Vertrauen in die Prozesse und Produkte zu verbessern.
Produkt- und Prozessanforderungen
Der wesentliche Inhalt der Common Criteria ist ein Katalog von Anforderungen, welche im zweiten und dritten Teil des Standards ausgeführt sind. Der zweite Teil [CC:2022(2)] behandelt dabei sicherheitsrelevante Produkteigenschaften, sogenannte security function requirements (SFR), das heißt technische Maßnahmen, welche die Verfügbarkeit von Systemfunktionen (z. B. im Kapitel FRU: Resource utilization) oder die Vertraulichkeit und Integrität bestimmter Informationen und Vorgänge gewährleisten sollen, bspw. aus den Kapiteln Stored data confidentiality (FDP_SDC) bzw. Stored data integrity (FDP_SDI).
Der dritte Teil [CC:2022(3)] beschreibt Anforderungen an die Prüfprozesse und die Dokumentation in Form der sogenannten security assurance requirements (SAR), welche ein Mindestniveau an Vertrauen in die korrekte Umsetzung der technischen Anforderungen herstellen und die Auditierung vereinfachen sollen, z. B. für externe Prüfstellen. Unterstützt wird dies durch eine einheitliche Darstellung der Nachweismethoden und Ergebnisse, welche im vierten Teil [CC:2022(4)] spezifiziert wird.
Thematische Hierarchie und Teilkataloge
Der Anforderungskatalog ist thematisch in einer hierarchischen Struktur gegliedert. Sowohl Funktions- als auch Prozessanforderungen sind als Elemente (elements) sogenannter Komponenten (components) gruppiert, welche wiederum Familien (families) und auf oberster Ebene Klassen (classes) bilden. So bilden zum Beispiel die Anforderungen der oben genannten Kapitel die Familien FDP_SDC bzw. FDP_SDI, welche zur Klasse FDP: User data protection gehören.
Die einzelnen Gruppen sind nicht überschneidungsfrei, tatsächlich wiederholen sich grundsätzliche Aspekte regelmäßig in den einzelnen Komponenten. Diese Struktur unterstützt damit jedoch ein zentrales Konzept des Katalogs, nämlich die gezielte Definition und Verwendung von Teilkatalogen. Der Hersteller kann diese Teilkataloge so zuschneiden, dass sie den Erfordernissen des konkreten Produktes und der internen Prozesse genügen. Zur Konstruktion abgeschlossener und konsistenter Teilkataloge definiert Teil 1 mehrere Mechanismen, wie z. B. Pakete (packages) und Schutzprofile (protection profiles). Damit kann, auf Basis von Bedarfs-, Bedrohungs- und Risikoanalyse, ein gezielter Fokus auf wesentliche Aspekte gelegt und ein dem Kontext angemessener, aber dennoch praktikabler Umfang definiert werden.
Dieser erste Teil definiert dazu auch die grundlegende Terminologie und Konzepte, auf die sich die Anforderungen und Abhängigkeiten immer wieder beziehen, wie zum Beispiel der zentrale Untersuchungsgegenstand, das so genannte target of evaluation (TOE), sowie die Definition der angestrebten Schutzziele und des erforderlichen Schutzniveaus in Form der security problem definition (SPD). Letzteres basiert auf der Bedrohungsanalyse, da es zum einen relevanten Bedrohungen beschreibt und auf Basis ihrer Bewertung die Schutzziele und auch grundlegende Annahmen, z. B. über die Betriebsumgebung oder die Fähigkeiten von Angreifern, trifft. Es sind diese Definitionen, an denen sich letztendlich bemisst, ob die Auswahl der relevanten Anforderungen zweckmäßig, die Umsetzung wirksam und die Prüfmethodik ausreichend überzeugend ist.
Abbildung 1: Das sogenannte security target (ST) umfasst alle wesentlichen Spezifikationselemente wie die Problemdefinition, die Schutzziele und die entsprechend ausgewählten Anforderungen.
Es muss entsprechend der der logischen Abhängigkeiten konsistent und vollständig sein (was wiederum selbst Gegenstand bestimmter security assurance requirements (SAR) ist, welche die Prüfung eben jener Konsistenz fordern). [CC:2022(1), Fig. 4]
Eine besondere Rolle spielt in diesem Zusammenhang der fünfte und letzte Teil des Standards [CC:2022(5)]. Dieser bietet bereits die vordefinierter Teilkataloge Evaluation assurance level 1 (EAL1) bis Evaluation assurance level 7 (EAL7), welche eine zunehmend rigorose Nachweismethodik zusichern. Während für die Konformität mit EAL1 (Functionally tested) nur ein stark eingeschränktes Schutzziel adressiert und die Bedrohungslage als gering annimmt, ist die Umsetzung des Katalogs EAL7 (Formally verified design and tested) wesentlich aufwändiger und erfordert eine deutlich höhere Methodenkompetenz. Dafür adressiert er Hochrisikoszenarien und Schutzziele die einen großen Aufwand rechtfertigen.
Komposition
Weiterhin beschreibt der Standard Mechanismen zur Komposition der Dokumentation einzelner Produktteile, sodass diese modular organisiert und nach Bedarf in verschiedene Kontexte integriert werden können. Kriterien zu Abhängigkeiten, Konsistenz und Revalidierung unterstützen damit eine Plattform-orientierte Produktentwicklung.
Nutzen
Auch abseits einer vollständigen Anwendung des Standards oder gar der Zertifizierung durch eine akkreditierte Stelle, kann der Anforderungskatalog eine hilfreiche Quelle und Leitfaden für die Bewertung und Weiterentwicklung der Produkte und Prozesse eines Herstellers sein. So kann z. B. das Testmanagement anhand der Prozessanforderungen der Klasse ATE: Test auch intern Verbesserungspotential identifizieren, was im Sinne des Qualitätsmanagements zu einer besseren Prozessbeherrschung beitragen kann und die Sicherheit stärkt, dem Stand der Technik zu entsprechen. Gerade auch bei Aspekten, die schwer pauschal bewertet werden können und einen gewissen Ermessensspielraum zulassen, wie z. B. der Analyse von Schwachstellen, kann der Abgleich mit den entsprechenden Anforderungen (z. B. der Klasse AVA: Vulanarability assessment) eine gewisse Sicherheit für ein grundsätzlich valides und akzeptiertes Vorgehen geben.
Letztendlich ist die Berücksichtigung der im Standard definierten Kriterien auch eine gute Argumentationsgrundlage gegenüber prüfenden Stellen und Behörden, insbesondere wenn diese den Standard anerkannt oder selbst daran mitgewirkt haben. Die Darlegung, dass und wie einzelne Elemente des Standards berücksichtigt sind, erleichtert auch Außenstehenden den Prozess nachzuvollziehen und damit in konkreten Fällen einer Argumentation des Herstellers zu folgen und grundsätzliches Vertrauen in die Qualität eines Produkts aufzubauen.
Referenzen
- [CC:2022(1)] Common Criteria for Information Technology Security Evaluation (CC:2022) - Part 1: Introduction and general model, www.commoncriteriaportal.org, 2022
- [CC:2022(2)] Common Criteria for Information Technology Security Evaluation (CC:2022) - Part 2: Security functional requirements, www.commoncriteriaportal.org, 2022
- [CC:2022(3)] Common Criteria for Information Technology Security Evaluation (CC:2022) - Part 3: Security assurance requirements, www.commoncriteriaportal.org, 2022
- [CC:2022(4)] Common Criteria for Information Technology Security Evaluation (CC:2022) - Part 4: Framework for the specification of evaluation methods and activities, www.commoncriteriaportal.org, 2022
- [CC:2022(5)] Common Criteria for Information Technology Security Evaluation (CC:2022) - Part 5: Pre-defined packages of security requirements, www.commoncriteriaportal.org, 2022
- [CEM:2022] Common Methodology for Information Technology Security Evaluation - Evaluation methodology, www.commoncriteriaportal.org, 2022