Im September 2018 hat der Bund den Bericht der Expertengruppe zur Zukunft der Datenbearbeitung und Datensicherheit veröffentlicht. Diese zwölfköpfige Expertengruppe wurde in Umsetzung der Motion von Paul Rechsteiner (13.3841) vom 26. September 2013 eingesetzt.
Unser Gastautor Christoph Jaggi hat den Expertenbericht einer vertieften Analyse unterzogen und ist dabei auf eklatante Mängel, Lücken und Widersprüche gestossen. Wir bringen die Analyse und die Kommentare von Christoph Jaggi innerhalb einer Artikelserie in vier Teilen. Im dritten Teil geht der Autor auf die Themen Cloud, Standards, Zertifizierungen, Zulassungen sowie Common Criteria ein und wirft dabei einen Blick auf unser Nachbarland Deutschland.
Datenbearbeitung und Datensicherheit: Ein Kommentar von Christoph Jaggi zum Expertenbericht des Bundes (Teil 3): Cloud, Zulassungen, Common Criteria
Cloud
Auch zum Thema Cloud äussert sich der Expertenbericht. Dabei wird davon ausgegangen, dass Cloud zwangsläufig eine Auslagerung mit sich führt. Dass es nebst Public Cloud auch Private Cloud gibt, wird unterschlagen. In der Praxis wird oft eine Hybrid-Cloud, eine Mischung aus Private und Public Cloud verwendet.
Datensicherheit und Public Cloud sind ein Problem, da die Datenbearbeitung entweder auf der Hardware-Infrastruktur des Cloudanbieters (IaaS), der Hardware-Infrastruktur und Plattform des Cloudanbieters (PaaS) oder der Hardware-Infrastruktur, der Plattform und der Applikation des Cloudanbieters (SaaS) stattfindet.
Die Sicherheit wird einerseits durch die Sicherheit der Infrastruktur, der Plattform und der Applikation des Cloud-Anbieters bestimmt. Andererseits spielt auch die Sicherheit auf der Kundenseite eine massgebende Rolle. Die Sicherheit muss bei allen Beteiligten gewährleistet sein.
Während der Verarbeitung durch eine Applikation sind die Daten in der Regel ungeschützt. Der Bericht weist zwar auf die «sichere» Enklave hin, die neuere Prozessoren (Intel SGX) gewähren, unterschlägt allerdings, dass auch diese Sicherheitsrisiken bergen und nicht vor Sicherheitslücken gefeit sind. Solche Sicherheitslücken wurden bereits publik.
Bei Data-at-Rest bestehen in Bezug auf langfristige Archivierung zusätzliche Herausforderungen. Die Technik entwickelt sich immer weiter. Die verwendeten Verschlüsselungsmethoden und Schlüssellängen müssen deshalb in gewissen Abständen aktualisiert werden. Das erfordert die Entschlüsselung des Archivbestandes mit anschliessender Wiederverschlüsselung.
Keinen Einfluss auf die Sicherheit hat es, ob die Schlüssel mit Hilfe eines QRNG (Quantum Random Number Generator) oder eines "normalen" TRNG (True Random Number Generator) erzeugt werden. Entscheidend ist, dass Zufälligkeit und Entropie den gesetzten Anforderungen entsprechen. Dazu sind Zufallsgeneratoren in unterschiedliche Wirkungsklassen unterteilt. Und in der Wirkungsklasse der QRNG gibt es etliche gleichwertige Alternativen.
Standards, Zertifizierungen und Zulassungen
Standards und Zertifizierungen sind ein komplexes Thema. Unterschieden wird zwischen sensitiven und nicht-sensitiven Daten und zwischen klassifizierten und unklassifizierten Daten. Die Klassifizierung kennt mehrere Stufen. Die schweizerische Gesetzgebung bezieht sich teilweise direkt auf amerikanische Zertifizierungen nach amerikanischen Standards (ZertES bezieht sich auf FIPS 140-2 Level 3). FIPS ist für sensitive, aber nicht für klassifizierte Daten konzipiert und zertifiziert nur nach amerikanischen Standards.
Common Criteria
Common Criteria ist relativ komplex und nicht ganz so international wie auf den ersten Blick vermutbar. Um es amerikanischen Anbieter zu ermöglichen, ihre Produkte relativ einfach und schnell nach CC zertifizieren lassen zu können, hat die NSA mit NIAP ein Programm geschaffen, dass dies unterstützt. Die entsprechenden Protection Profiles sind allerdings auf amerikanische Standards und FIPS beschränkt und decken nur EAL2 ab.
Entscheidend sind bei Common Criteria das verwendete Protection Profile, das Security Target und die Evaluationstiefe. Für Anbieter ist ein vernünftiges Security-Audit ein massiver Zusatzaufwand, der zudem negative Auswirkungen auf Time-to-Market hat. Auf der anderen Seite zeigt nur ein solcher Security-Audit, was evaluiert worden ist und macht die Sicherheitsarchitektur für den Kunden transparenter. Aktuell erwarten die Anbieter, dass der Kunde selbst evaluiert (inklusive Penetration Test) und die Resultate (gefundene Schwachstellen) nachvollziehbar dokumentiert und meldet. Die Quality Assurance wird an den Kunden ausgelagert und damit Zeit und Geld gespart. Das ist allerdings der falsche Weg und müsste unterbunden werden.
Der "Expertenbericht" stellt fest: "Die Common Criteria for Information Technology Security Evaluation“ (CC) sind wohl der weitverbreitetste und anerkannteste Standard für die Überprüfung der Sicherheit von IKT-Produkten. Allerdings ist der Prüfprozess zeit- und kostenintensiv, weshalb er nur bei hochsensitiven Produkten wie etwa in der Raumfahrt zur Anwendung kommt.„
Diese Feststellung entspricht nicht den Tatsachen. Offensichtlich sind da die Experten nicht mit der gängigen Praxis vertraut.
Folgende Evaluation Assurance Levels (EAL) stehen für Common Criteria zur Verfügung und werden verwendet:
- “EAL1 is appropriate for products meeting specific customer needs requesting low assurance.
- EAL2 is a level which is often used for applications with security functionality. It is also an “entry level” for developers who are aiming at a higher level but want to get familiar with the evaluation and certification process, before.
- EAL3 is a level which is typically selected for complex products (like operating systems) in case a higher level is considered to be too costly.
- EAL4 is a level which is adequate for products and customers mandating and requiring a high assurance level.
- EAL5 is a level which is selected in case customers request extra assurance (smart card components).
- EAL6 and EAL7 are beyond the scope of this guidance. They are selected in extraordinary cases, only.”
Nur schwer bis gar nicht prüfbar sind Chips und deren Sicherheit. Sich auf versprochene Sicherheit zu verlassen ist schon fast grob fahrlässig.
Gemäss Expertenkommission ist Intels SGX (Secure Enclave) sicher, die Realität stellt sich allerdings anders dar: aktueller Bericht Heise vom Februar 2019.
Erfolgt die Netzwerkverschlüsselung auf dem Netzwerkchip, dann sind Schwachstellen noch viel schwerwiegender, da für die Verschlüsselung die Schlüssel im Klartext verwendet werden und es sich beim Netzwerkchip um den einzigen von aussen direkt zugreifbare Chip handelt.
Ein Blick auf ein Nachbarland
In Deutschland stellt das Bundesamt für Sicherheit in der Informationstechnik (BSI) technische Richtlinien zur Verfügung, die allgemein zugänglich sind, Details dazu hier.
Diese stehen im Kontext mit dem BSI IT-Grundschutz und zeigen Mindestanforderungen auf. Viele Produkte mit FIPS-Zulassung erfüllen nicht einmal diese Mindestanforderungen. Das hängt damit zusammen, dass FIPS 140-2 viele Legacy-Algorithmen und Schlüssellängen zulässt. FIPS ist in mehrere Stufen unterteilt, von Level 1 bis Level 4, die unterschiedliche Software- und Hardware-Voraussetzungen haben. Erst ab Level 3 ist Hardware manipulationssicher. Zudem wird bei FIPS nur eine einzelne Software oder ein einzelnes Gerät geprüft, aber nicht ein komplettes System, wie das bei vernetzten Lösungen notwendig wäre.
Die Mindestvoraussetzungen für Systeme für klassifizierte Daten sind in der Regel klassifiziert und deshalb nicht öffentlich zugänglich. Hingegen gibt es in einzelnen Ländern Listen der Produkte, die für klassifizierte Daten zugelassen sind, Beispiele dazu hier.
Die zugelassenen Produkte gehen deutlich über die publizierten Mindestanforderungen hinaus. Für kritische Infrastrukturen werden in der Regel vorwiegend solch zugelassene Produkte eingesetzt, Details dazu hier.
Auch in der Schweiz nimmt die Verwendung von solch zugelassenen Produkten zu, da diese in der Regel nicht nur sicher, sondern auch stabil und langlebig sind. Für Langlebigkeit und Sicherheit mitentscheidend ist die Verwendung von programmierbaren Prozessoren (FPGA), die im Gegensatz zu applikationsspezifischen Prozessoren (ASIC) aktualisierbar sind.
Bei einem FPGA erfolgt ein Update/Upgrade mittels Software, während bei einem ASIC für ein Update/Upgrade der Prozessor und damit in der Regel die gesamte Hardware ausgewechselt werden muss. FPGA sind massiv teurer als ASIC, können dafür problemlos ohne Wechsel der Hardware umprogrammiert werden.
Analyse und Kommentare zum Expertenbericht in vier Teilen
- Teil 1 | 29. April 2019
Einführung, Hintergrund und Grundlagen
- Teil 2 | 30. April 2019
Quantencomputer und Netzwerksicherheit, sichere Netzwerke
- Teil 3 | 2. Mai 2019
Cloud, Standards, Zertifizierungen und Zulassungen, Common Criteria, Blick auf ein Nachbarland
- Teil 4 | 6. Mai 2019
Abhängigkeiten, Bildung, Forschung und Produktisierung und Vermarktung, 51 Empfehlungen an den Bundesrat
