⚖️ Offene Konsultationen, eigene Einreichungen zur E VDE-AR-N 4100:2024-10, TAB Entw

[Torxgewinde]

Falls ihr auch noch eigene Einreichungen zur E VDE-AR-N 4100:2024-10 machen wollt, noch ist Zeit!

Unter dem Link https://www.vde.com/de/fnn/dokumente/alle-vde-anwendungsregeln kann man noch bis 27.11.2024 Änderungsvorschläge für die neuen TABs abgeben. Alternativ kann man dies auch unter https://www.vde.com/de/fnn/themen/tar/uebersicht/anfragen-tar

Ich habe konkret die Schnittstelle zwischen SMGW und unseren "steuerbaren Endverbrauchern" die ich im Kapitel 9 explizit als Klartext mit Integritätssicherung definieren würde. Ich möchte protokollieren und auch sicherstellen können, dass über den Datenbus nicht mehr als Verbrauchersteuerung passiert.

Mal gucken wie das Forum Netztechnik und Netzbetrieb sich dazu äußert...

Hier die konkrete Einreichung:

Zeilen-NummerAb (z.B. 17)	Zu Abschnitt Nr. (z.B. 3.1)	Absatz, Bild, Tabelle (z.B. Bild 2)	Art des Einwandes (grundsätzlich / techn. / redaktionell)	Einwand / Begründung	Vorgeschlagene Änderung
2485	9	-	techn.	Explizit festlegen, dass die Schnittstelle eine Protokollierung und Filterung NICHT behindern darf	Da eine bidirektionale Schnittstelle zur steuerbaren Verbrauchseinrichtung besteht, müssen Grundprinzipien der IT-Sicherheit gelten: a) unabhängige Protokollierbarkeit der Daten und b) die Möglichkeit zur Datenfilterung. Klartextübertragung mit gesicherter Datenintegrität ist üblich.

[JoWiemann]

Hm,

bei den TAB bist Du mit Deinem Anliegen im falschen Bereich. Die TAB beschreiben die Bedingungen die für einen Netzanschluss gelten. Dass was Du möchtest muss in den TR des BSI verankert werden.

Grüße Jörg

[Torxgewinde]

@Jowiemann: Darf ich daraus also Schlussfolgern, dass der Ansatz selbst von dir nicht kritisiert wird? Die Kritik zielt darauf ab wo es definiert wird?

Der Entwurf zieht im Kapitel 9 "Steuerung und Datenübertragung, Kommunikationseinrichtungen" die Punkte zusammen, was man so akzeptabel findet. Ich kann mir auch vorstellen, dass es im FNN Lastenheft Steuerbox am besten untergebracht ist.

Im Entwurf steht momentan:

2470 Diese Steuerung durch den Netzbetreiber erfolgt über eine Steuerungseinrichtung, die an der HAN/CLS
2471 Schnittstelle des Smart-Meter-Gateways (SMGW) angeschlossen ist oder zukünftig auch direkt aus dem
2472 SMGW. Die Steuerung/Regelung der Wirkleistung erfolgt über eine bidirektionale Datenübertragungs-
2473 schnittstelle die entweder
2474 – mindestens die im FNN Lastenheft Steuerbox [6] definierte Digitalschnittstelle entsprechend VDE-AR-E
2475 2829-6-1 unterstützt, oder
2476 – den funktionalen Anforderungen des FNN Lastenheft Steuerbox [6] (integrierte ,,Steuerbox Funktion")
2477 entspricht.
2478 ANMERKUNG 1 Der Ausgang der Steuereinrichtung ist perspektivisch als Ethernet Schnittstelle vorzusehen und über
2479 entsprechende Leitungsverbindung verpflichtend mit der steuerbaren Verbrauchseinrichtung zu verbinden.
2480 ANMERKUNG 2 Steuerbare Verbraucheinrichtungen sind in der Festlegung der BNetzA zur Durchführung der Steuerung
2481 nach §14a EnWG definiert.
2482 ANMERKUNG 3 Die Steuerung von SG-Ready-Geräten mit einem 230-V-Signal über ein Relaiskontakt ist, in einer
2483 Übergangsphase, wie in 10.7 definiert, möglich.
2484 Der Aufbau und die Anbindung von Kommunikationseinrichtungen zur Nutzung durch den MSB und VNB
2485 müssen dem MsbG entsprechen.

In den Anmerkungen werden verwandte Punkte zu der vorgeschlagenen Änderung aufgelistet. Speziell ANMERKUNG 3 geht auf datensparsame Relaiskontakte ein und das diese Option aber nur mit einer Übergangszeit geduldet wird.

In dem Lastenheft Steuerbox Funktionale und konstruktive Merkmale (<-- Leider nur zum Kauf im VDE Shop) wird nur die Schnittstelle im Kapitel 10.3 selbst beschrieben.

Hier der relevante Abschnitt aus dem FNN Lastenheft in der die Schnittstelle beschrieben wird:

Für die sichere Kommunikation der Steuerbox mittels der Digitalen Schnittstelle in einen Kunden-
netzwerk (z.B. zu einem Energiemanagementsystem) sind die nachfolgenden Anforderungen zu
erfüllen.
[STB_0426]
Die Steuerbox MUSS bei TCP/IP-basierter Kommunikation mit der steuerbaren
Einheit eine Sicherung mittels TLS 1.2 oder einer höheren TLS Version unterstützen.
Hinweis: Die Verwendung von TLS zur Anbindung von Bestandsanlagen ist aktuell nicht verpflich-
tend.

Zu der Ergänzung in der TAB ist es sinnvoll im FNN-Lastenheft Steuerbox die strenge Forderung nach TLS um die Option "transparente Schnittstelle" zu erweitern, damit man Protokollieren und Filtern kann. Diese Option verlieren Anlagenbetreiber sonst. Die neue TAB macht das FNN Lastenheft ja verpflichtend, nimmt einem aber für Neuanlagen die Option der "transparenden Schnittstelle".

Es sollte aus den denkbaren Möglichkeiten des FNN-Lastenhefts gefordert werden, dass die Schnittstelle Filtern und Protokollieren unterstützen muss und dafür unverschlüsselt sein muss. Nur weil eine Schnittstelle IP-basierend ist, sollte man nicht automatisch auch immer direkt verschlüsseln. Das Lastenheft kann gerne weitere Szenarien beschreiben. Was man davon im Schaltschrank nutzt, sagt dann die TAB.

Ich denke es ist im FNN ungefähr an der richtigen Adresse, ob die "transparente Schnittstelle" nun in der TAB und/oder in dem Lastenheft FNN Steuerbox landet ist im Grunde auch nicht so wichtig. Wichtiger ist, dass wir als Betreiber von Anlagen nicht daran gehindert werden, wenigstens sehen und ggf. filtern zu können ob auf der Schnittstelle mehr als Verbrauchersteuerung betrieben wird. Gerade Sicherheitslücken in dem SMGW und den steuerbaren Verbrauchern sind bei Betriebszeiten von Jahrzehnten doch recht wahrscheinlich. Da hilft es ungemein, wenn man die Schnittstelle mindestens unabhängig vom Endgerät oder SMGW als Betreiber protokollieren/firewallen kann.

Beste Grüße!

[Prof. Dr. Peter Henning]

Ich sehe das Ganze sehr kritisch. Insbesondere das mit dem Ethernetkabel würde in den meisten betroffenen Systemen für zusätzliche Aufwände sorgen, weil vermutlich ein CAT7-Kabel in einem separaten Leerrohr verlangt würde. Diese Vermutung basiert auf dem, was die Netzbetreiber aus dem APZ-Feld gemacht haben.

Allerdings habe ich so viele politische Baustellen und Aktivitäten, dass ich mich nicht im Stande sehe, mich um einen qualifizierten Einwand zu kümmern.

LG

pah

[Torxgewinde]

Kurzes Update: Ich habe mit mehreren Leuten vom VDE/FNN telefoniert. Am ergiebigsten war ein Telefonat mit Frau Woryna.

Ich hatte die Punkte als E-Mail zusammengefasst:

vielen Dank für das gestrige Gespräch. Im Folgenden möchte ich die wichtigsten Punkte zusammenfassen und die besprochenen Sicherheitsaspekte einbringen. Ich würde mich freuen, wenn diese Überlegungen in die Weiterentwicklung einfließen können. Rückmeldungen oder weitere Fragen sind selbstverständlich willkommen, ich bin bei dem Thema ein Quereinsteiger.

Zukünftig sollen steuerbare Einheiten wie Wallboxen, PV-Wechselrichter, Wärmepumpen und ähnliche Geräte stärker an die aktuelle Netzsituation angepasst werden. Eine gängige Methode zur Steuerung dieser Geräte erfolgt über Relais, die naturgemäß eine hohe IT-Sicherheit bieten. Der inhärente Vorteil dieser Lösung liegt darin, dass nur sehr begrenzte Informationen zwischen dem Netzbetreiber und der steuerbaren Einheit ausgetauscht werden. Der Nachteil dieser Lösung ist, dass der Netzbetreiber kein direktes Feedback von den Geräten erhält – lediglich der vernetzte Stromzähler gibt Auskunft über die Umsetzung der Vorgaben.
Zukünftige Versionen der Technischen Anschlussregeln (TAR) verlangen jedoch perspektivisch eine bidirektionale Kommunikationsschnittstelle, um eine genauere Steuerung und Rückmeldung zu ermöglichen. Diese Schnittstelle soll unter anderem auf Standards wie KNX oder EEBUS basieren und die Steuerung der Geräte ermöglichen. Dies bringt neue Herausforderungen mit sich, da eine solche Schnittstelle zusätzliche Angriffsflächen eröffnet und Sicherheitsrisiken erhöht.

Wieviele vernetzte Geräte, von vor nur 20 Jahren, würden sie heute noch in großer Menge als IT-mäßig-sicher betrachten?
Ein zentrales Sicherheitsrisiko ergibt sich aus der langen Lebensdauer vieler dieser Geräte, die oft mehrere Jahrzehnte umfasst. In dieser Zeit könnten Geräte keine regelmäßigen Sicherheitsupdates erhalten, was eine erhebliche Bedrohung darstellen kann. Hersteller haben häufig keinen Anreiz bzw. Ressourcen, ihre Geräte nach dem Verkaufszeitraum weiter zu pflegen, was dazu führen kann, dass Geräte über Jahre hinweg ohne notwendige Sicherheitsaktualisierungen betrieben werden. Das FNN-Lastenheft für Steuerboxen sieht zudem keine verpflichtenden Sicherheitsupdates vor.

Ein weiteres Risiko besteht darin, dass einige Hersteller zwar exzellente Hardware bereitstellen, jedoch keine dauerhaft zuverlässige Sicherheitsinfrastruktur und Jurisdiktion, um eine sichere Integration in Netzwerke zu gewährleisten. So unterliegen einige Hersteller nicht europäischen Jurisdiktionen, die die Geräte unter Kontrolle der Hersteller auch ggf. anderen Akteuren zugänglich machen. Ein bekanntes Beispiel hierfür sind ausßereuropäische Mobilfunkkomponenten, bei denen Bedenken hinsichtlich der Datensicherheit und möglichen Jurisdiktion des Herstellerlandes dazu führen, dass Betreiber eine Verbindung zum Internet vermeiden oder die Produkte erst gar nicht genutzt werden dürfen. Konsequenterweise lassen sich die gleichen Bedenken auch auf steuerbare Einheiten wie zB. Wechselrichter ausweiten. Persönlich bin ich zwar begeisterter Betreiber von Huawei Wechselrichtern, binde diese aber nicht an das Internet an, sondern betreibe die Geräte in einem isoliertem, lokalem Netz. Das potenzielles Sicherheitsrisiko ergibt sich durch die Möglichkeit eines absichtlich provozierten massenhaft, zeitgleichen Fehlverhaltens von dauerhaft vernetzten Geräten. Dies könnte zu weitreichenden Netzstörungen führen und den Herstellern von steuerbaren Einheiten eine unnötige Macht über kritische Infrastruktur verleihen.

Die Risiken klingen je nach Vertrauenslevel nach einem fernem oder auch nur theoretischem Szenario - die technische Möglichkeit wird nun aber allerdings geschaffen wenn die TAR perspektivisch eine immer engere Vernetzung fordert.

Um diesen Risiken entgegenzuwirken, schlage ich folgende optionale Maßnahmen vor:
Betrieb der steuerbaren Einheiten nur im lokalen Netz erlauben, ohne direkte Internetverbindung.
Einsatz von Firewalls und/oder MITM-Proxys, um die Kommunikation zu überwachen und auf legitime Steuerbefehle zu beschränken.

Da die bidirektionale Schnittstelle zwischen Steuerbox und steuerbarer Einheit zukünftig verpflichtend wird, sollten auch für diese Schnittstellen angemessene Schutzmechanismen definiert werden:

Der Einsatz von Firewalls oder MITM-Proxys könnte bereits jetzt implementiert werden, um eine vertrauenswürdige und sichere Kommunikation zu gewährleisten. Eine solche Lösung könnte sicherstellen, dass nur legitime Steuerbefehle zwischen den Systemen ausgetauscht werden. Laut dem VDE-Hinweis zur "Bundeseinheitlichen Empfehlung von VDE FNN nach dem Stand der Technik zu Tenorziffer 2a" (Kapitel 4.1.3) soll die Authentifizierung von TLS X.509-Zertifikaten bislang nicht über eine automatisierte PKI erfolgen. Es erscheint sinnvoll, darauf hinzuwirken, dass dies auch künftig nicht geändert wird. Es sollte dann nämlich ausdrücklich festgelegt werden, dass Zertifikate einer vorgeschalteten Firewall oder eines MITM-Proxys auch zulässig sind. Dies würde Betreibern ermöglichen, steuerbare Einheiten mit erhöhtem Sicherheitsbedarf durch eigene Schutzmaßnahmen abzusichern und zusätzliche Sicherheitsebenen einzuführen.

Es sollte weiterhin die Möglichkeit bestehen bleiben, die Steuerung nur über Relais auch langfristig beizubehalten, um als inhärente Sicherheitsmaßnahme eine physische, von der IT getrennte Steuerung zu ermöglichen.

Ein weiterer Vorschlag für die Gestaltung der lokalen Schnittstelle zwischen Steuerbox und steuerbarer Einheit ist die Einführung eines transparenten Datenkanals. Hierbei könnten die Daten im Klartext übertragen werden, was mit einfachen Mitteln eine Überwachung und Filterung der Kommunikation ermöglicht. Gleichzeitig könnte ein HMAC (Hashed Message Authentication Code) eingesetzt werden, um die Integrität der übertragenen Daten sicherzustellen, ohne die Authentizität der Kommunikation zu gefährden. Dieses Modell würde es ermöglichen, die Kommunikation sowohl auf ihre Sicherheit zu überprüfen als auch umfassendes Logging zu betreiben.

Ich freue mich auf Ihre Rückmeldung und darauf, diese Punkte weiter mit Ihnen zu diskutieren.

[Prof. Dr. Peter Henning]

In Deutschland versinkt inzwischen alles im Würgegriff der Bürokratie. Die hier diskutierten Maßnahmen werden die Kosten für die Installation einer Wallbox oder eine Wärmepumpe weiter nach oben treiben.

LG

pah

[JoWiemann]

Vielleicht einfach mal die Perspektive wechseln. Wir nutzen täglich irgendwelche digitalen System und kümmern uns kaum um deren Sicherheit. Ist auch kein Problem, da wir ja der Initiator sind und wenn doof, dann suchen wir uns etwas Neues.
Das iMSys ist aber ein vom Gesetzgeber vorgeschriebenes digitales Equipment, mit dem durch die erfassten Daten ein guter Einblick in die Lebensführung gewonnen werden kann. Somit wurden das BSI, Verbände und erfahrene Unternehmen beauftragt ein entsprechend hohes Sicherheitsniveaus zu definieren, dass zum einen die gewonnenen Daten schützt und zum Anderen mögliche Angriffe über iMSys auf die Infrastruktur möglichst ausschließt. Ob hier über das Ziel hinausgeschossen worden ist wird die Zukunft zeigen. Allerdings stellen wir zunehmend Angriffe auf die Infrastruktur der Energieversorgung fest. Wenn es dann zum Blackout kommt sind dann wieder alle am schreien. Übrigens hat ein Blackout Anfang der 2000sender in Kalifornien als ein Beispielszenarium gedient, dass es zu vermeiden gibt. Ein Hacker hatte sich in die Systeme des Netzbetreibers zur Steuerung der Klimageräte gehackt und diese in unsinnigen Wellen ein und ausgeschaltet, was dann zum Zusammen des gesamten Netzes geführt hat. Das hier ein Angriffspunkt für eine hybride Kriegsführung besteht haben die Angriffe auf das Netz der Ukraine und der Satelliten, die sehr viele Datenverbindungen zu Windkraftanlagen halten gezeigt. Am Anfang des Krieges waren dutzenden Anlagen von Windkraftanlagen von zwei Betreibern in Deutschland mit einer großen Einspeiseleistung über Tage nicht steuerbar.

Grüße Jörg

[Torxgewinde]

Das Einfachste wäre für kritische Betreiber, wenn es ausdrücklich erlaubt bleibt Relais zu nutzen. Da kann nicht ausversehen ein Update oder großer Datenverkehr drüber laufen. Einfach, pragmatisch und sicher.

Alternativ wäre es auch ausreichend, wenn die selbst signierten Zertifikate bei den steuerbaren Endverbrauchern dauerhaft akzeptabel bleiben. Dann können wir dort ein MITM-Proxy zwischenschalten, den Traffic umverpacken, inspizieren und ggf. filtern.
AFAIK wäre dafür nichts an den Normen zu ändern, außer dass man auch langfristig selbst signierte Zertifikate OK finden muss und nicht doch irgendwann eine PKI einführt.

[Torxgewinde]

Noch ein kurzes Update: Die BNetzA hatte dazu auch eine offene Konsultation, die ist zwar vor kurzem abgelaufen, aber ich habe auch dort den Punkt jetzt noch versucht anzubringen. Mal gucken...

Sollte dieser Aspekt jedoch unberücksichtigt bleiben, sehe ich die Notwendigkeit, steuerbare Verbraucher grundsätzlich als potenziell gefährdete Geräte in eine separate DMZ auszulagern. Die nächsten Jahre werden dann zeigen, ob die Hersteller solcher Geräte ihre Hausaufgaben im Bereich Cybersicherheit gemacht haben.

Das neue Produkthaftungsgesetz mit Softwarehaftung (ProdHaftG) könnte zumindest durch eine erweiterte Herstellerhaftung für schnellere Updates sorgen. Allerdings habe ich die Befürchtung, dass dies eher zu einer verkürzten Nutzungsdauer der Geräte führt: Entweder wird der Hersteller Abos oder Wartungsverträge für die Firmware anbieten – oder die Geräte sind schlicht nicht sicher zu betreiben.

[Prof. Dr. Peter Henning]

Aus meiner Sicht geht die staatliche Einflussnahme hier zu weit - und öffnet dem Missbrauch Tür und Tor. Ich lasse mir gerne sagen, dass ich derzeit wegen einer möglichen Netzinstabilität bitte weniger Strom verbrauchen oder einspeisen soll. Aber wofür ich die Energie nutze, muss mir überlassen bleiben.

LG

pah

[JoWiemann]

Aber wofür ich die Energie nutze, muss mir überlassen bleiben.

Dass bleibt auch Dir überlassen. Du wählst einfach das Modul 2 nach Festlegung der BNetzA. Somit bekommst Du einen eigenen Zähler für Deine §14a EnWG und §9 EEG Anlagen. Da der Zähler Phasen übergreifend Saldiert erscheint sieht der Netzbetreiber  alle Anlagen als Steuerbare Ressource hinter der viele Technische Ressourcen gebündelt werden. Wenn Du das geschickt machst, sieht der Netzbetreiber bei Dir kein Potential, da Du ja neutral bist. Er würde also im ersten Schritt nur die Ressourcen im Niederspannungsnetzabschnitt die tatsächlich für ihnen ein Potential haben.

Hinzu kommt noch, dass der Netzbetreiber erst eingreifen darf, wenn er in der Ortsnetzstation tatsächlich ein Problem nachweisen kann.

Viel spannender wird die Umsetzung §14c EnWG. Marktgestützte Beschaffung von Flexibilitätsdienstleistungen im Elektrizitätsverteilernetz.

Grüße Jörg

Ganz interessant: https://www.bdew.de/service/stellungnahmen/bdew-stellungnahme-zum-2-referentenentwurf-enwg-novelle-endkundenmaerkte-netzausbau-netzregulierung/

[Prof. Dr. Peter Henning]

Na ja, es geht ja nicht nur um mich - ich bin nicht aus Eigeninteresse politisch aktiv. Insofern steht "mir überlassen" für generelle Überlegungen.

Das bedeutet auch, dass ich mich immer für Technologieoffenheit einsetzen werde. Und z.B. eine Festlegung auf KNX nicht akzeptabel finde.

LG

pah

P.S.: Ich habe jetzt mein IMSys. SmartMeter Gateway wurde installiert ... aber wie https://forum.fhem.de/index.php?msg=1325565

[JoWiemann]

Und z.B. eine Festlegung auf KNX nicht akzeptabel finde.

Aktuell scheint sich EEBUS durchzusetzen. Bei KNX war eh nur KNX over IP in der Diskussion.

Grüße Jörg

[Torxgewinde]

Was konkretes um sich mit der aktuellen Lage zurechtzufinden, selbst wenn nichts mehr geändert wird:
In der Open-Source Lösung EVCC ist EEBUS für SteuVE eingebaut (https://docs.evcc.io/blog/2024/08/17/highlights-14a-enwg-ocpp-loadmanagement-elli#steuerbare-verbraucher). Das ist auch für uns FHEMler sehr interessant, da EVCC scheinbar die Gegenstelle zur Steuerbox anbietet und solch eine offene Lösung langfristig einfacher sicher zu betreiben ist, als die closed Firmware von den typischen Herstellern.

Entweder könnte man dann in Zukunft EVCC (zusätzlich) nutzen, oder FHEM bekommt irgendwann ein EEBUS Modul.

[JoWiemann]

Gibt es auch von anderen Anbietern. Auch aus dem Konzern, dem ich verpflichtet bin: https://www.gridx.ai/de/success-stories/e-on-energie-deutschland

Grüße Jörg