Das Notfallmanagement ist beim Betrieb von IT-Systemen ein wichtiges Thema, um auch auf Ausnahmesituationen vorbereitet zu sein und in diesen angemessen und besonnen reagieren zu können. Notfälle werden vom BSI im Standard 100-4 z.B. als Funktionsstörungen definiert, die den Geschäftsbetrieb stark beinträchtigen und im Rahmen der normalen Betriebsabläufe nicht rechtzeitig gelöst werden können und daher hohe Schäden auslösen könnten.

Häufig werden im Notfallmanagement Störungen der Verfügbarkeit behandelt. Eine rechtzeitige Behebung der Situation bezieht sich dann z.B. auf die Wiederherstellung eines Systems, das entweder aufgrund von extern abgeschlossenen Service Level Agreements (SLAs) oder aufgrund interner Anforderungen der Systembenutzer innerhalb einer bestimmten Zeitspanne wieder benutzbar sein muss. Aber natürlich sollten auch Datenabflüsse von vertraulichen Daten, z.B. bei einem Hackerangriff, als Notfall eingestuft werden.

Im Bereich der Smart Metering (SM)-PKI werden für Gateway-Administratoren (GWA) in der Certificate Policy der SM-PKI insbesondere Notfallszenarien mit Auswirkung auf die Vertraulichkeit oder seine grundsätzliche Glaubwürdigkeit als relevant eingestuft. Beispiele wären Schwachstellen in verwendeten kryptografischen Algorithmen oder die Kompromittierung des eigenen privaten Schlüssels.

Wie kann ein Notfallmanagement umgesetzt werden?

Häufig werden im Vorfeld bereits Maßnahmen umgesetzt, um eine erfolgreiche Behandlung von Notfällen überhaupt erst zu ermöglichen. Allgemein führen diese Maßnahmen dazu, dass entweder die Eintrittswahrscheinlichkeit eines Notfalls reduziert wird oder die Behandlung des Notfalls erleichtert wird. Beim Ausfall eines produktiven Systems könnten diese „Vorbeugemaßnahmen“ entweder darin bestehen, dass ein Redundanzsystem bereitsteht und einfach nur in Betrieb genommen werden muss, oder dass alle relevanten Informationen, z.B. durch Datensicherungen und den Einsatz standardisierter Systeme, bereitstehen, um das ausfallende System rechtzeitig durch ein neu aufgesetztes System ersetzen zu können.

Bei den in der Certificate Policy skizzierten Notfallszenarien kann der Austausch der verwendeten kryptografischen Algorithmen ohne Probleme vorbereitet werden, in dem ein entsprechend konfiguriertes System bereitsteht. Problematisch wird es allerdings bei der ebenfalls zu betrachtenden Kompromittierung von privatem Schlüsselmaterial aus der SM-PKI, z.B. des GWA. Denn einfach einen neuen privaten Schlüssel mitsamt Zertifikat zu generieren und anschließenden zu verteilen ist nicht möglich, denn in der Anforderung 5.2.9 der Certificate Policy ist die unverzügliche Sperrung von Zertifikaten gefordert, sobald die dazugehörigen privaten Schlüssel kompromittiert oder nur ein begründeter Verdacht besteht.

Schlüssel weg! Was nun?

Da der private Schlüssel zur Kommunikation mit den Smart Meter Gateways (SMGW) benötigt wird, kann durch die notwendige Sperrung des Schlüssels auch kein neues Zertifikat für einen neu erzeugten privaten Schlüssel auf die Gateways eingespielt werden. Eine Aufrechterhaltung des GWA-Betriebs wäre also nicht möglich und ohne ein gültiges GW-Zertifikat kann mit den betroffenen SMGWs kein Kommunikationskanal mehr aufgebaut werden. Entsprechend müssten alle vom betroffenen GWA betreuten SMGWs ausgetauscht werden, da sie irreversibel unbrauchbar wären.

Um einen solchen Notfall behandeln zu können, könnte als vorbeugende Maßnahmen z.B. ein zweiter privater Schlüssel mit Zertifikat generieret werden und in allen SMGWs – quasi als „Notschlüssel“ – hinterlegt werden. Anschließend müsste nur eine gleichzeitige Kompromittierung der Schlüssel verhindert werden, z.B. indem die privaten Schlüssel getrennt voneinander gespeichert werden, um auch im Notfall – dann mit dem Notschlüssel – immer noch den Zugriff auf die SMGWs gewährleisten zu können.

Bisher bestand bei dem skizzierten Verfahren die Ungewissheit, dass in der alten Certificate Policy nicht spezifiziert war, ob ein GWA mehrere private Schlüssel mit entsprechenden Zertifikaten überhaupt besitzen darf oder ob – außer bei Zertifikatswechseln – immer nur ein gültiges Zertifikat je GWA existieren darf.

Möglichkeiten durch die neue Certificate Policy

In der überarbeiteten Version der Certificate Policy ist nun im Abschnitt 4.1.1 explizit folgender Passus aufgenommen wurden:

Ein Endnutzer (nicht SMGW) KANN sofern erforderlich weitere Zertifikate bzw. Zertifikatstriple (siehe [TR-03109-4] für sich beantragen (z.B. für Lastmanagement oder Ausfallsicherheit).

Somit ist die Möglichkeit zur Nutzung von mehreren Zertifikaten durch den GWA nun in der Certificate Policy offiziell vorgesehen und sollte unserer Meinung nach im Rahmen des Notfallmanagements auch genutzt werden. Im Rahmen des Notfallmanagements sollte dann ferner die Ausgestaltung des zweiten privaten Schlüssels und des dazugehörigen Zertifikates genau geprüft werden, wird z.B. der zweite private Schlüssel für einen anderen kryptografischen Algorithmus erstellt, das Zertifikat von einer anderen Sub-CA ausgestellt und wie können die privaten Schlüssel getrennt voneinander gespeichert werden?

Die Certificate Policy hat geliefert, wie sieht es bei den Herstellern aus?

Mit der neuen Certificate Policy sind jetzt die Regelungen entsprechend angepasst, um theoretisch ein Notfallmanagement für die Kompromittierung des privaten Schlüssels aufbauen zu können. Nun ist allerdings noch in der Praxis zu klären, ob die SMGWs der Hersteller den dauerhaften Umgang mit mehreren GWA-Zertifikaten bereits unterstützen oder nur mit einem GWA-Zertifikat gearbeitet werden kann. Eigentlich sollten alle SMGWs an die neuen Gegebenheiten der Certificate Policy angepasst werden können, da im Rahmen des GWA-Zertifikatswechsels bereits temporär zwei Zertifikate auf dem SMGW verarbeitet werden müssen

Unserer Meinung nach wäre es auf jeden Fall sinnvoll, die dauerhafte Unterstützung von mehreren GWA-Zertifikaten im Rahmen eines ggf. stattfinden Auswahlprozesses für die zu verbauenden SMGWs mit zu berücksichtigen.