DNP3 hat einen Sicherheitsstandard. Verschlüsselt wird damit nichts.
Secure Authentication v5 ist echte Kryptografie, in IEEE 1815 normiert, und sie belegt, wer einen Befehl gesendet hat. Über den Leser sagt sie nichts. Dieser Leitfaden zeigt, was SAv5 tatsächlich schützt, warum so wenige Versorger sie betreiben und was mit dem Verkehr geschieht, den sie im Klartext lässt.
Zuletzt aktualisiert:
Was ist DNP3-Sicherheit, und was bringt SAv5 wirklich?
DNP3-Sicherheit meint zwei getrennte Dinge, die leicht verwechselt werden. Secure Authentication v5, definiert in IEEE 1815, ergänzt eine Challenge-Response-Authentifizierung, mit der eine Außenstation prüfen kann, ob ein kritischer Befehl wirklich von dem Master stammt, der ihn gesendet haben will. Das ist Authentifizierung und Integrität. Es ist keine Vertraulichkeit: Mit aktivem SAv5 bleibt der Verkehr auf der Leitung lesbar. Verschlüsselung ist eine eigene Entscheidung und kommt daher, DNP3 über TLS zu führen.
DNP3 kam in den 1990er-Jahren für Strom- und Wasserversorger auf und kann mehr als Modbus: Zeitstempel, Ereignisprotokollierung, unaufgeforderte Meldungen und Betrieb über lange, gestörte Strecken. Dieser Funktionsumfang erklärt, warum es in der Fernüberwachung überall steckt, und er gibt einem Angreifer zugleich mehr an die Hand, wenn nichts den Verkehr authentifiziert.
Warum ist SAv5 so selten eingeschaltet?
Der Standard ist seit 2012 verfügbar. Die Verbreitung im Feld ist gering, und das nicht, weil Betreiber ihn ablehnen. Vier praktische Hürden erklären den Großteil.
Schlüssel müssen verstreute Außenstationen erreichen
SAv5 setzt voraus, dass Update- und Sitzungsschlüssel jede Außenstation erreichen. Bei einem Versorger sind das Pumpwerke, Umspannwerke und Fernwirkeinheiten über ein ganzes Versorgungsgebiet verteilt, oft nur über eine langsame oder zeitweise verfügbare Strecke erreichbar. Dieses Schlüsselmaterial über einen solchen Bestand zu verteilen und zu erneuern, das ist die eigentliche Arbeit, und deshalb bleibt die Funktion ungenutzt.
Beide Seiten müssen sie beherrschen
SAv5 wird ausgehandelt. Eine Außenstation, die sie beherrscht, gewinnt nichts, wenn der Master es nicht tut, und ein über zwei Jahrzehnte gewachsener Bestand hat sie selten an beiden Enden jeder Strecke. Das älteste Gerät setzt die Obergrenze.
Sie schützt kritische Funktionen, nicht alles
Der Standard authentifiziert kritische Funktionscodes: Operate, Direct-Operate, Neustarts, Konfigurationsänderungen. Routineabfragen und Telemetrie sind standardmäßig nicht abgedeckt. Das ist technisch richtig, bedeutet aber, dass SAv5 einzuschalten nicht die ganze Kommunikation authentifiziert.
Sie wird oft für Verschlüsselung gehalten
Das ist der Punkt, der echten Schaden anrichtet. Teams schalten SAv5 ein, verbuchen die Maßnahme als erfüllt und nehmen an, die Strecke sei nun vertraulich. Ist sie nicht. Prozesswerte, Punktnamen und die Form des Vorgangs bleiben für alles auf dem Weg lesbar.
Was kann ein Angreifer mit einer nicht authentifizierten Außenstation anfangen?
DNP3 ordnet Daten in Objekte und Punkte und kennt unaufgeforderte Meldungen. Diese Struktur macht es für Versorger nützlich, und sie ist zugleich eine gut dokumentierte Landkarte für jeden, der den Port erreicht.
Unbefugte Steuerbefehle
Ein Operate oder Direct-Operate auf einen Relaisausgangsblock, von einem Master, der so etwas nie gesendet hat, oder auf einen Punkt, der so etwas nie empfangen hat. Das ist der klassische Vorbote einer unbefugten Schalthandlung, und ohne SAv5 unterscheidet nichts im Protokoll ihn von einem legitimen Befehl.
Auskundschaften der Datenkarte
Anfragen nach Objekten, Varianten oder Punktbereichen außerhalb des üblichen Profils der Station. Weil DNP3 selbstbeschreibend ist, kann ein Angreifer die Datenkarte des Geräts lernen, ohne etwas zu senden, das bösartig aussieht.
Wiedereinspielen mitgeschnittenen Verkehrs
Früher gültige Pakete erneut senden, um eine Aktion auszulösen oder eine Änderung zu verdecken. SAv5 verhindert das mit Challenge-Response und Sitzungs-Nonces; ohne sie bleibt nur die Analyse von Zeitstempeln und Sequenzen, und das ist Erkennung, nicht Verhinderung.
Missbrauch von Neustart und Konfiguration
Kaltstart, Warmstart und Konfigurations-Funktionscodes außerhalb eines geplanten Wartungsfensters. Genau diese kritischen Funktionen sollte SAv5 schützen, und darum ist ein nicht authentifizierter Bestand ihnen ausgesetzt.
Was deckt Secure Authentication v5 ab?
SAv5 ist ein Challenge-Response-Verfahren, das in DNP3 selbst transportiert wird. Sendet ein Master eine kritische Anfrage, fordert die Außenstation ihn heraus, und der Master antwortet mit einem Nachrichten-Authentifizierungscode, der über die Anfrage mit einem gemeinsamen Sitzungsschlüssel berechnet wird. Die Station handelt nur, wenn dieser Nachweis stimmt.
| Eigenschaft | Mit SAv5 | Was das praktisch bedeutet |
|---|---|---|
| Authentifizierung | Ja, bei kritischen Funktionscodes | Die Station kann belegen, dass ein Steuerbefehl vom Inhaber des Sitzungsschlüssels kam und nicht von irgendetwas anderem, das den Port erreicht hat. |
| Integrität | Ja | Ein unterwegs veränderter Befehl scheitert an seinem Authentifizierungscode und wird abgewiesen. |
| Schutz vor Wiedereinspielung | Ja | Challenge-Response mit Sitzungs-Nonces sorgt dafür, dass ein mitgeschnittenes Paket nicht einfach erneut gesendet werden kann. |
| Vertraulichkeit | Nein | Verschlüsselt wird nichts. Prozesswerte, Punktnamen und die Struktur des Vorgangs bleiben auf der Leitung lesbar. |
| Abdeckung | Kritische Funktionen | Routineabfragen und Telemetrie werden standardmäßig nicht authentifiziert, SAv5 einzuschalten authentifiziert also nicht die ganze Sitzung. |
Verschlüsselt DNP3 Secure Authentication den Verkehr?
Nein, und das ist das folgenreichste Missverständnis rund um DNP3-Sicherheit. SAv5 belegt, wer einen Befehl gesendet hat und dass er nicht verändert wurde. Sie verbirgt weder, was der Befehl sagt, noch die zurücklaufende Telemetrie. Wer Vertraulichkeit braucht, führt DNP3 über TLS, eine eigene Maßnahme mit eigenen Zertifikaten und eigener Schlüsselverwaltung. Eine Checkliste, die SAv5 als Erfüllung einer Transportverschlüsselungs-Anforderung verbucht, verbucht etwas Unwahres.
Wie verschlüsselt man DNP3 tatsächlich?
Verschlüsselung für DNP3 entsteht dadurch, es in TLS zu kapseln, nicht durch das Protokoll selbst. Das ist eine echte Option mit echten Kosten, und an diesen Kosten bleiben die meisten Bestände hängen.
TLS auf der Strecke
DNP3 über TLS bringt Vertraulichkeit und eine zweite, transportnahe Authentifizierung der Endpunkte. Es braucht Zertifikate auf beiden Seiten, also eine Zertifizierungsstelle, einen Verteilweg und einen Erneuerungsprozess, die jede Außenstation erreichen.
Das Zertifikatsproblem ist wieder das Schlüsselproblem
Dieselbe Hürde, die SAv5 ungenutzt lässt, nur anders gekleidet. Wenn Update-Schlüssel ein abgelegenes Pumpwerk praktisch nicht erreichen, erreichen es ablaufende Zertifikate ebenso wenig.
Serielle Strecken verschieben die Frage
Ein großer Teil von DNP3 läuft weiterhin seriell oder über Seriell-zu-IP-Umsetzer. TLS setzt einen IP-Pfad voraus, auf diesen Strecken verlagert sich die Vertraulichkeitsfrage also auf das, was das serielle Signal trägt, nicht auf DNP3.
Oder das Problem von den Stationen wegholen
Wo Zertifikatsarbeit pro Gerät unrealistisch ist, sorgt das Terminieren der Sitzung auf einem protokollkundigen Proxy dafür, dass eine Komponente Schlüssel und Zertifikate hält, statt dass jedes entfernte Gerät einen Teil des Problems trägt.
Welcher Master, oder welcher Techniker?
SAv5 beantwortet eine engere Frage, als die meisten annehmen. Ein Sitzungsschlüssel ist ein Geräte-Credential: Er belegt, dass die Anfrage von etwas kam, das diesen Schlüssel hält. Wer an der Tastatur saß, sagt er nicht, und an einem geteilten Engineering-Arbeitsplatz sind das sehr verschiedene Tatsachen.
Was SAv5 belegt
Dass die Anfrage von einer Partei kam, die den Sitzungsschlüssel dieser Strecke hält, und dass sie weder verändert noch wiedereingespielt wurde. Für eine Maschine-zu-Maschine-Abfrage zwischen Master und Außenstation ist das genau die richtige Zusicherung, und sie genügt.
Was er nicht belegen kann
Welche Person den Befehl abgesetzt hat. Ein Schlüssel, den sich Leitwarte, Wartungslaptop und die Fernsitzung eines Integrators teilen, authentifiziert alle drei gleich. Wird der Schlüssel kopiert, ist die Kopie vom Original nicht zu unterscheiden.
Das zählt vor allem dort, wo DNP3 auf Menschen trifft: Wartungsfenster, Integratorzugriff, alles über Fernwartung. NERC CIP-004 und CIP-005 fragen, wer wann Zugriff hatte, und ein im Team geteiltes Geräte-Credential kann das nicht beantworten. Namentliche Identität muss aus der Schicht kommen, die die Sitzung vermittelt, nicht aus dem Protokoll.
Wo scheitert DNP3-Sicherheit in der Praxis?
Wie bei den meisten OT-Protokollen liegen die Fehler beim Ausrollen, nicht bei der Kryptografie.
SAv5 als Verschlüsselung verbucht
Die Compliance-Zeile sagt verschlüsselt, die Leitung sagt etwas anderes. Prüfen Sie, was die Maßnahme wirklich verlangt hat.
Nur auf einer Seite aktiviert
Eine fähige Außenstation an einem Master, der SAv5 nicht aushandeln kann, erhält keinen Schutz, und die Bestandsliste führt sie oft trotzdem als aktiviert.
Update-Schlüssel nie erneuert
Bei der Inbetriebnahme eingespielt und nie wieder angefasst. Nichts fällt aus, also löst nichts eine Prüfung aus, und die Reichweite eines einzigen kompromittierten Schlüssels bleibt dauerhaft.
Standardport bleibt erreichbar
DNP3 lauscht üblicherweise auf TCP-Port 20000. Eine Station, die dort aus einem flachen Netz erreichbar ist, ist für alles in diesem Netz erreichbar, authentifiziert oder nicht.
Seriell-zu-IP-Umsetzer als neutral behandelt
Eine serielle Strecke auf IP zu legen, setzt sie allem aus, dem IP sie aussetzt. Der Umsetzer wird selten so geprüft wie das Endgerät.
DNP3-Härtungs-Checkliste: was zu prüfen ist
Das meiste davon ist Prüfen statt Bauen, und vieles lässt sich aus einem Mitschnitt und einer Bestandsliste beantworten.
- 01
Feststellen, welche Strecken SAv5 tatsächlich aushandeln, an beiden Enden, statt welche Geräte sie als Fähigkeit führen.
- 02
Prüfen, dass die kritischen Funktionscodes, Operate, Direct-Operate, Neustart und Konfigurationsänderung, auch die authentifizierten sind.
- 03
Im Risikoregister und in jedem Compliance-Nachweis ausdrücklich festhalten, dass SAv5 Authentifizierung ist und keine Verschlüsselung.
- 04
Entscheiden, wo Vertraulichkeit wirklich gefordert ist, und dort TLS einsetzen, statt anzunehmen, das Protokoll liefere sie.
- 05
Update-Schlüsseln einen Erneuerungsplan und einen Verantwortlichen geben und Ausgabe- und Ablaufdaten mit dem übrigen Netzzustand dokumentieren.
- 06
Für jede Station eine Referenz der Objekte, Varianten und Funktionscodes aufnehmen, die sie normalerweise sieht, damit alles außerhalb dieses Profils auffällt.
- 07
Sicherstellen, dass TCP-Port 20000 von nirgendwo erreichbar ist, wo er nicht gebraucht wird, unabhängig vom Authentifizierungsstand.
Diese Maßnahmen entsprechen NERC CIP-005 für den elektronischen Sicherheitsperimeter und CIP-007 für die Systemsicherheit, der Identifizierung und Authentifizierung (FR1) und der Nutzungskontrolle (FR2) nach IEC 62443 sowie NIST SP 800-82r3 für OT-Systeme.
Wie sichert man DNP3, das sich nicht umkonfigurieren lässt?
Alles bisher Gesagte setzt voraus, dass man den Endpunkt ändern und Schlüssel zu ihm bringen kann. In einem verteilten Versorgerbestand trägt diese Annahme oft nicht: Das Gerät ist älter als SAv5, der Hersteller gibt die Änderung nicht frei, oder der Standort liegt zwei Autostunden von der Person entfernt, die sie vornehmen könnte. Die Alternative ist, den Schutz vor die Station zu setzen.
Ein Ort hält die Schlüssel
Access Gate betreibt eine eigene PKI und terminiert die Sitzung, sodass Zertifikate und Schlüsselmaterial auf der Appliance liegen statt auf jeder entfernten Außenstation. Das Gerät, das einen wechselnden Schlüssel nie hätte halten können, muss es nicht mehr.
Vertraulichkeit, ohne das Protokoll anzufassen
Der Kanal zur Gate ist TLS 1.3 mit post-quantensicherem Schlüsselaustausch (ML-KEM-768), gegen diese PKI geprüft, vor einer Station, die davon kein Wort spricht.
Default-Deny nach Identität und Protokoll
Einem Techniker DNP3-Zugriff auf eine Station zu geben, gibt ihm sonst nichts. Jedes Protokoll auf jedem Asset ist eine ausdrückliche Freigabe, also genau die Durchsetzung, die eine nicht authentifizierte Station für sich selbst nicht leisten kann.
Nachweise für CIP-005 und CIP-007
Derselbe Proxy, der die Sitzung kontrolliert, zeichnet sie auf: welche Identität, welche Station, welches Protokoll, wann. Das ist der Zugriffsnachweis, den NERC CIP verlangt, erzeugt aus dem Betrieb heraus statt aus einem separaten Projekt.
Einen DNP3-Bestand in den Griff bekommen, ohne jeden Standort anzufahren
Wenn Ihre Außenstationen kein SAv5 können oder Schlüsselerneuerung über das Versorgungsgebiet nicht realistisch ist, gehen wir gemeinsam durch, wie das Absichern des Kanals in Ihrem Netz aussieht.
Stromnetz und Umspannwerke
Wie dieselbe Architektur für SCADA, Fernwirkeinheiten und Schutzrelais im Stromnetz greift.
Am eigenen Bestand ansehen
Eine Durchsprache an Ihrer Topologie: welche Stationen exponiert sind, wie die Durchsetzung aussieht und was das Ausrollen verlangt.
Fragen zur DNP3-Sicherheit
Der Standard-TCP-Port von DNP3. Eine hier ohne Authentifizierung erreichbare Station führt jeden wohlgeformten Befehl aus, den sie empfängt.
Nein. SAv5 liefert Authentifizierung, Integrität und Schutz vor Wiedereinspielung für kritische Funktionscodes. Vertraulichkeit liefert sie nicht, die Nutzlast bleibt also auf der Leitung lesbar. Verschlüsselung für DNP3 entsteht dadurch, es über TLS zu führen, eine eigene Maßnahme mit eigenen Zertifikaten und eigener Schlüsselverwaltung. SAv5 gegen eine Transportverschlüsselungs-Anforderung zu verbuchen, heißt etwas Unwahres zu verbuchen.
Es ist der Sicherheitsmechanismus aus IEEE 1815, der Norm, die DNP3 spezifiziert. Sendet ein Master eine kritische Anfrage, etwa ein Operate oder einen Neustart, stellt die Außenstation eine Challenge, und der Master muss mit einem Nachrichten-Authentifizierungscode antworten, der mit einem gemeinsamen Sitzungsschlüssel berechnet wurde. Die Station handelt nur bei gültigem Nachweis, was sowohl gefälschte als auch wiedereingespielte Befehle stoppt.
Schlüsselverwaltung. SAv5 verlangt, dass Update- und Sitzungsschlüssel jede Außenstation erreichen, und bei einem Versorger liegen diese Stationen über ein Versorgungsgebiet verteilt, an Strecken, die langsam oder zeitweise verfügbar sind oder beides. Sie muss zudem an beiden Enden einer Strecke unterstützt sein, was ein über zwei Jahrzehnte gewachsener Bestand selten ist. Die Hürde ist nicht die Kryptografie, sondern das Verteilen und Erneuern des Schlüsselmaterials.
Nein. Sie authentifiziert die kritischen Funktionscodes, also die zustandsändernden: Operate, Direct-Operate, Kalt- und Warmstart, Konfigurationsänderungen. Routineabfragen und Telemetrie werden standardmäßig nicht authentifiziert. Das ist ein bewusster technischer Kompromiss, denn jede Abfrage zu authentifizieren würde Bandbreite auf Strecken kosten, die keine haben, es heißt aber, dass SAv5 den größten Teil der Kommunikation unauthentifiziert lässt.
Indem der Schutz davor gesetzt wird. Die Station kommt in eine segmentierte Enklave, sodass sie nicht mehr direkt erreichbar ist, und die Sitzung wird auf einem protokollkundigen Proxy terminiert, der Identität und Richtlinie anwendet, bevor er die Verbindung wieder aufbaut. Schlüssel und Zertifikate liegen auf dem Proxy statt auf einem entfernten Gerät, das sie nie hätte halten können, und das Gerät behält Konfiguration, Firmware und IP.
