CRA in der Automatisierungstechnik: Suche Fachliteratur / Beiträge

[Rappenberger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Mahlzeit zusammen, ich suche Fachliteratur (Buchempfehlungen) oder auch gerne Online, um mich in das Thema
CRA und Cyber Security einzuarbeiten. Ich möchte lernen, wie ich die Kommunikation in der Feldebene (Profinet) und auch in der Vertikalen Kommunikation
(TCP/IP auf IP oder IPSec Basis) sowie Kommunikationstreiber (OPC/UA, Zenon, etc.) sicher mache.

Viele Grüße

 

[gerribaldi]

Naja, einfach mal nach CRA und/oder Cyber Security googeln - da findest Du bestimmt was ;-)

Aber was genau ist denn dein anliegen? Weil das Thema Cyber Security ist ja doch sehr komplex und auch ein konzeptionelles Thema.

Erste Anhaltspunkte wären z.B. VLANs, Segmentierung und Firewalls an Netzübergängen. Des Weiteren Nutzung von sicheren Verbindungen zwischen SPS und HMI/Prozessleitsystem. Auch wäre eine Möglichkeit, die Netze zwischen Profinet und restlichen Netz physisch zu trennen.

Vielleicht kannst Du aber auch mal kurz skizzieren, was denn der aktuelle Status ist und wo du den gerne hin willst?

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

Bei Profinet ist es recht einfach ... Da hilft nur Trennung.
Beim Rest (HMI, Programmierschnittstellen, Leitsysteme) ist mittlerweile Verschlüsselung angesagt
Oft in Kombination mit Zertifikaten. Und solche Dinge unterstützt mittlerweile auch jede CPU und jedes HMI.
Im Linux-Umfeld findet man dazu viele Anleitungen und Tutorials. Ich persönlich finde da einfache Raspberrys gut zum spielen.

 

[ducati]

Bei Profinet ist es recht einfach ... Da hilft nur Trennung.

könnte man Profinet-IO in ein VPN packen? Oder geht dann die Hälfte nicht mehr?

 

[Lars Weiß]

Also, die Norm, der der ganze Spaß zugrunde liegt, ist die IEC 62443.

 

[Lars Weiß]

Zuviel Werbung?
-> Hier kostenlos registrieren

könnte man Profinet-IO in ein VPN packen? Oder geht dann die Hälfte nicht mehr?

Ein VPN ist da nicht so unbedingt das Mittel zur Wahl.

Bei PROFINET gibt’s drei Security Classes, die aufeinander aufbauen:

Security Class 1
Im Prinzip „klassisch OT“:
Keine Verschlüsselung auf Protokollebene. Man geht davon aus, dass das Netz geschützt ist (VLAN, Firewall, physische Trennung etc.). Das ist in vielen Bestandsanlagen noch der Normalfall.

Security Class 2
Hier kommt Geräteschutz dazu:
Authentifizierung, Schutz vor unbefugter Parametrierung, signierte Firmware, Rollen-/Userkonzepte usw.
Aber: Die eigentliche RT-Kommunikation ist noch nicht vollständig verschlüsselt.

Security Class 3
Das ist die aktuelle Ausbaustufe (ab PROFINET v2.4):
TLS-basierte Absicherung, Zertifikate, Integritätsschutz und Verschlüsselung der Kommunikation.
Quasi „PROFINET mit echter Security auf Protokollebene“.

Wichtig:
Die Security Classes ersetzen keine Netzwerksegmentierung oder ein Zonenmodell nach IEC 62443 – das kommt on top.

 

[Blockmove]

könnte man Profinet-IO in ein VPN packen? Oder geht dann die Hälfte nicht mehr?

Kann man.
Bei Profinet hast du aber die Zugänglichkeit als Hauptproblem. Da gab es von den IT-Security-Typen schon die tollsten Ideen.
Die Spezifikation für Verschlüsselung von PN gibt es. Macht es halt in Zukunft nicht einfacher.

 

[DeaD_EyE]

könnte man Profinet-IO in ein VPN packen? Oder geht dann die Hälfte nicht mehr?

Dann muss der VPN aber Layer 2 unterstützen. Sonst kommt man nur auf die CPUs, wenn sie schon eine IP haben. PN-DCP ist Layer 2.
Hab da was gefunden, aber ist nicht wirklich im Unternehmensfeld einsetzbar: https://gist.github.com/zOrg1331/a2a7ffb3cfe3b3b821d45d6af00cb8f6

Naja, wie oft kommt das vor, dass man via Remote IP-Adressen vergeben muss?

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Bei Profinet hast du aber die Zugänglichkeit als Hauptproblem.

Ist ja nur ein akademisches Beispiel...

Der Schaltschrank mit SPS und der Remote-IO müsste ja eh irgendwie geschützt sein, damit die Putzfrau nicht einfach nen Draht durchschneidet. Wenn das Netzwerkkabel von SPS zum Remote-IO im anderen Stockwerk geschützt werden müsste, naja wär halt die Idee VPN.

Aber am Ende bin ich immer noch der Meinung, dass diese ganzen Security-Beschränkungen mehr Anlagenstillstände verursachen als wirklich Hackerangriffe bei offenen Anlagen.

Also bei wirklich kritischen Anlagen sollten Leute draufschauen, die davon was verstehen und sich ein sinnvolles Konzept überlegen, bei allen anderen WC-Lüftungen sollte man den Securitykram lieber abschalten. Und natürlich grundsätzlich nicht alles vernetzen

 

[DeaD_EyE]

Aber am Ende bin ich immer noch der Meinung, dass diese ganzen Security-Beschränkungen mehr Anlagenstillstände verursachen als wirklich Hackerangriffe bei offenen Anlagen.

Im didaktischen Umfeld ist es noch schlimmer. Die sollen SPS programmieren lernen und müssen erstmal die ganze Sicherheit deaktivieren, weil sich das kein Lehrer antun will.

 

[Blockmove]

Der Schaltschrank mit SPS und der Remote-IO müsste ja eh irgendwie geschützt sein, damit die Putzfrau nicht einfach nen Draht durchschneidet. Wenn das Netzwerkkabel von SPS zum Remote-IO im anderen Stockwerk geschützt werden müsste, naja wär halt die Idee VPN.

Sowas funktioniert schon.
Das VPN sollte halt Layer 2 unterstützen damit Dinge wie Namen vergeben oder Topologie funktionieren.
Ist ja im Prinzip auch nichts anderes als Fernwartung.

Aber am Ende bin ich immer noch der Meinung, dass diese ganzen Security-Beschränkungen mehr Anlagenstillstände verursachen als wirklich Hackerangriffe bei offenen Anlagen.

Also bei wirklich kritischen Anlagen sollten Leute draufschauen, die davon was verstehen und sich ein sinnvolles Konzept überlegen, bei allen anderen WC-Lüftungen sollte man den Securitykram lieber abschalten. Und natürlich grundsätzlich nicht alles vernetzen

Ich bin da vor Jahren schon mit Siemens und auch unserer IT-Securtity im Clinch gelegen.
Die 1500er unterstützt Etliches an Security. Aber dem SPSler fehlt das KnowHow und der ITler fast kein TIA an.

Nachts um 2 steht dann der Nachtschicht-Elektriker blöd da, wenn er ne CPU tauschen will. Als erstes kommt die neue Steuerung nicht ans Firmen-Netz weil sie ne neue MAC-Adresse hat und sie deshalb der IT-Switch sie aussperrt und als nächstes funktioniert die Kommunikation zum Leitsystem nicht, weil irgendwelche Zertifikatsfehler auftreten. Nach ein paar Stunden Fehlersuche kommt dann raus, dass einfach die Uhrzeit in der Steuerung nicht gestellt ist.

 

[Lars Weiß]

Zuviel Werbung?
-> Hier kostenlos registrieren

Sowas funktioniert schon.
Das VPN sollte halt Layer 2 unterstützen damit Dinge wie Namen vergeben oder Topologie funktionieren.
Ist ja im Prinzip auch nichts anderes als Fernwartung.

Einspruch. Das ist was ganz anderes als Fernwartung. Mit einem VPN baust du einen Tunnel auf, in dem die komplette Kommunikation abgesichert ist. Wenn wir davon sprechen Profinet sicher zu machen, dann wollen wir nur das eine Protokoll, die eine Verbindung verschlüsseln.

 

[ducati]

Wenn wir davon sprechen Profinet sicher zu machen, dann wollen wir nur das eine Protokoll, die eine Verbindung verschlüsseln.

naja, das können "wir" ja nicht, sondern nur Siemens. Oder ist das in TIA V19 schon drinn? Mit welcher Hardware?

 

[ducati]

Ich bin da vor Jahren schon mit Siemens und auch unserer IT-Securtity im Clinch gelegen.
Die 1500er unterstützt Etliches an Security. Aber dem SPSler fehlt das KnowHow und der ITler fast kein TIA an.

Naja, KnowHow ist das eine, aber die primäre Aufgabe des Automatisierers ist halt ne andere. Klar kann ich das ganze Sicherheitsgedödel auch noch mitmachen, aber dann brauch ich Projektzeit dafür und auch Leute, die was entscheiden und die ganzen "organisatorischen Maßnahmen" beim Kunden erledigen... Es scheitert doch schon daran, dass jemand nen ordentliches Konzept über IP-Adressvergabe macht und das noch über die Lebenszeit des Werkes/der Anlage gepflegt wird...

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das Thema wird ziemlich sicher auf die Instandhaltung abgewälzt.
Der IT-Support sitzt irgendwo in Indien, Chile oder Bulgarien.
Für Wartungsaufgaben an Netzwerkkomponenten gibt es ein eigenes Wartungsnetzwerk vorbei an Firewalls usw.
Das hört aber einen Hop vor der S7 auf.
Also brauchst du den Turnschuh-ITler … Der macht aber um 15 Uhr Feierabend.

 

[ducati]

Das Thema wird ziemlich sicher auf die Instandhaltung abgewälzt.

Das kanns halt nicht sein, bzw. der IT-Support auch nicht.
Am Ende, bei einem vollumfänglichen Sicherheitskonzept für die Automatisierung brauchtst Du 3 Leute mehr oder weniger Vollzeit für ein Werk. Alleine schon wenn einer krank oder im Urlaub ist... Für die ganze Passwort und Benutzerverwaltung, Zutrittsberechtigung, Netzwerkverwaltung, Softwareprojekteverwaltung usw...
Wenn Du da die Mitarbeiter nicht einplanst, landet das ganze im Kuddelmuddel und die Leute suchen sich "Umwege" um ihre Arbeit trotzdem zu machen oder auch nicht...
Ich kenn einige größere Kunden und kann Dir ziemlich genau erklären, was alles nicht funktioniert und warum

Sicherheitsstandards sind so ähnlich wie Softwarestandards... Da muss einer den Hut auf haben und Zeit dafür.

 

[Blockmove]

@ducati
Ich denke auch, dass es viel einfacher ist Beispiele für nicht funktionierende Umsetzungen zu finden als funktionierende, sauber strukturierte Organisationen.
Wenn man Glück hat, kann man im Schaltschrank irgendeine Hardware-Firewall verbauen um die sich die IT kümmert.
Und dann kommen jetzt die Forderungen nach verschlüsselten Profinet ...

Ich hab mich vor 2 Jahren mal lang mit Bihl + Wiedemann unterhalten. Sie wollten mich von ASi-5 überzeugen.
Da sind wir dann auch auf das Thema Security gekommen. Wenn du dir jetzt die Situation anschaust, musst du wirklich über sowas nachdenken.
Vielleicht gräbt noch einer Interbus-S aus.

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

tja, ASi hat halt in der Tat den Vorteil, dass man perse vom Bus nicht auf die CPU zugreifen kann. Modbus RTU wär ja auch "sicher"
Was gibts da sonst noch an Feldbus, der keinen Zugriff auf die CPU zulässt?

 

[roboticBeet]

Was gibts da sonst noch an Feldbus, der keinen Zugriff auf die CPU zulässt?

EtherCAT sollte prinzipiell auch ganz gut da stehen, da es den TCP/IP Stack überhaupt nicht implementiert und daher etwas weniger Angriffsfläche im Vergleich zu bspw. Profinet bietet

 

[Blockmove]

Die Normen sind soweit gefast, dass die Hardware und das Übertragungsprotokoll eigentlich egal sind,
Du kannst die Daten an ein Remote-IO auch per Brieftaube schicken.
Es muss sichergestellt sein, dass die Daten vom richtigen autorisiertem Partner kommen.
Dazu gehören nicht nur die Daten für den regulären Betrieb sondern auch Parametrisierung und Firmware.

Solche Dinge wie z.B. automatische Vergabe des Gerätenamens an Hand der Topologie wird sicher in Zukunft anders gelöst werden.
Im einfachsten Fall wirst du wahrscheinlich eine Taste drücken können (so wie z.B. bei ner Fritzbox) im schlimmsten Fall wirst du neue Zertifikate austauschen müssen.