DNP3 absichern, ohne die Unterstationen anzufassen. SAv5 authentifiziert Befehle, verschlüsselt sie aber nicht.
Secure Authentication v5 (SAv5), genormt in IEEE 1815, belegt, wer einen Befehl gesendet hat. Den Inhalt verbirgt es nicht. Dieser Leitfaden zeigt, was SAv5 schützt, warum es kaum ein Versorger einsetzt und wie Sie mit dem lesbaren Datenverkehr umgehen.
Zuletzt aktualisiert:
Was ist DNP3-Sicherheit, und was bringt SAv5?
DNP3-Sicherheit meint zwei verschiedene Dinge, die leicht verwechselt werden. Secure Authentication v5 (SAv5), definiert in IEEE 1815, ergänzt eine Challenge-Response-Authentifizierung. Damit prüft eine Unterstation, ob ein kritischer Befehl wirklich von ihrem Master kommt. Das deckt Authentifizierung und Integrität ab. Vertraulichkeit deckt es nicht ab: Auch mit SAv5 bleibt der Datenverkehr im Netz lesbar. Verschlüsselung ist eine eigene Entscheidung und entsteht, wenn DNP3 über TLS läuft.
DNP3 kam in den 1990er-Jahren für Strom- und Wasserversorger auf und kann mehr als Modbus: Daten mit Zeitstempel, Ereignisprotokollierung, unaufgeforderte Antworten und Betrieb über lange, gestörte Leitungen. Deshalb ist es in der Fernüberwachung noch überall zu finden. Es bietet einem Angreifer aber auch mehr Angriffsfläche, 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-Mechanismus innerhalb von DNP3 selbst. Wenn ein Master eine kritische Anfrage sendet, stellt die Unterstation eine Challenge. Der Master antwortet mit einem Message Authentication Code, berechnet über die Anfrage mit einem gemeinsamen Sitzungsschlüssel. Die Unterstation 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üsseln Sie DNP3?
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.
Zertifikate bringen das Schlüsselproblem zurück
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.
Das Problem von den Unterstationen 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.
Identifiziert SAv5 den Techniker oder nur den Master?
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.
Die Checkliste zur DNP3-Härtung.
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 oben setzt voraus, dass Sie das Endgerät ändern und Schlüssel dorthin bringen können. In einem verteilten Versorgungsnetz trifft das oft nicht zu. Das Gerät ist älter als SAv5, der Hersteller unterstützt die Änderung nicht, oder der Standort liegt zwei Stunden von jedem entfernt, der sie vornehmen könnte. Die Alternative ist, den Schutz vor die Unterstation 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.
Verschlüsselung, ohne das Protokoll zu ändern
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.
DNP3 absichern, ohne jeden Standort anzufahren.
Manche Unterstationen können SAv5 nicht ausführen, und Schlüsselrotation im ganzen Versorgungsgebiet ist oft unrealistisch. Wir zeigen Ihnen, wie die Kontrolle des Kanals in Ihrem Netzwerk 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.
Häufige 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 bietet Authentifizierung, Integrität und Replay-Schutz für kritische Funktionscodes. Vertraulichkeit bietet es nicht, die Nutzdaten bleiben im Netz lesbar. Verschlüsselung für DNP3 entsteht durch den Betrieb über TLS, eine eigene Maßnahme mit eigenen Zertifikaten und eigenem Schlüsselmanagement. Verbuchen Sie SAv5 nicht gegen eine Anforderung zur Verschlüsselung bei der Übertragung, denn es erfüllt sie nicht.
Es ist der Sicherheitsmechanismus aus IEEE 1815, der Norm, die DNP3 spezifiziert. Sendet ein Master eine kritische Anfrage, etwa einen Schaltbefehl oder einen Neustart, stellt die Unterstation eine Challenge. Der Master muss mit einem Message Authentication Code antworten, der mit einem gemeinsamen Sitzungsschlüssel berechnet wird. Die Unterstation handelt nur, wenn dieser Nachweis gültig ist. Das stoppt gefälschte und wiedereingespielte Befehle.
Das Schlüsselmanagement. SAv5 braucht Update- und Sitzungsschlüssel auf jeder Unterstation. Bei einem Versorger sind diese Stationen über ein Versorgungsgebiet verteilt, an langsamen, unterbrochenen oder beiden Arten von Leitungen. Außerdem müssen beide Enden einer Verbindung es unterstützen, was in einem über zwei Jahrzehnte gekauften Bestand selten ist. Schwierig ist vor allem das Verteilen und Rotieren des Schlüsselmaterials, weniger die Kryptografie.
Nein. Es authentifiziert kritische Funktionscodes, also die, die einen Zustand ändern: Operate, Direct-Operate, Kalt- und Warmstart, Konfigurationsänderungen. Routineabfragen und Telemetrie sind standardmäßig nicht authentifiziert. Das ist ein bewusster Kompromiss, denn jede Abfrage zu authentifizieren kostet Bandbreite, die diese Leitungen nicht haben. Es bedeutet aber, dass auch mit SAv5 der Großteil der Kommunikation nicht authentifiziert ist.
Setzen Sie den Schutz davor. Holen Sie die Unterstation in eine segmentierte Enklave, damit sie nicht direkt erreichbar ist. Beenden Sie die Sitzung an einem protokollkundigen Proxy, der Identität und Richtlinie prüft, bevor er die Verbindung neu aufbaut. Schlüssel und Zertifikate liegen auf dem Proxy, nicht auf einem entfernten Gerät, das sie nie hätte halten können. Das Gerät behält Konfiguration, Firmware und IP-Adresse.
