OT-Assetmanagement

T

TP-Inc

Level-3
Beiträge
1.162
Reaktionspunkte
265
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

wir beschäftigen uns immer mehr mit Cybersecurity, NIS2, CRA usw. Der erste Schritt wäre mal ein vernünftiges Asset-Management im OT-Bereich. Wir haben mal den Inspector von Siemens getestet, suchen aber natürlich auch Alternativen. Bei Google habe ich eine ganze Reihe von Software gefunden, ich will da aber nicht unbedingt alles durchprobieren.

Wichtig wäre für uns:

Asset-Discovery im Maschinennetz mit Slots, Sublots und FW
Prüfung welche Ports bei welchen Hosts offen sind
Prüfung ob Default-Credentials bei Hosts aktiviert sind
Prüfung ob bekannte CVEs zu diesen Hosts vorliegen.

Habt ihr da schon mehr Erfahrungen bzw. Tipps?
 
Ich kann mir das mit der Automatischen Prüfung der Assets momentan nicht vorstellen, da die Eigenschaften und Quellen z.B. für Geräte Firmware und dazu noch die Updates zu unterschiedlich sind. Zwar wird das mit der Fernwartung immer mehr, aber durch Netzwerksegmentierung / Bus-Segmentierung hat man auch nicht auf alles Zugriff im Feld / Schaltschrank.

Das einzigste was ich momentan für praktikabel halte ist eine Datenbank händisch zu verwalten und regelmäßig nach Updates zu suchen. Oder gibt es schon APIs von den Herstellern, Festo, Siemens, Beckhoff, Wago, Pilz usw. mit der man nach allen Geräten mit dessen Hardware-Ständen und den dazugehörigen Software / Firmware ständen suchen kann?

Updates werden meist auch händisch Durchgeführt bei einem geplanten Anlagenstillstand. Wenn die Firmware lädt, kann man nebenher auch gleich die Datenbank pflegen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also der Inspector von Siemens bekommt über die X2 die PN-Teilnehmer die an X1 hängen mitsamt aller Sublots inkl. Firmware raus. Ich denke gerade bei PN-Devices, und die machen 90% unserer Netzwerke aus, muss das relativ einfach gehen. Bei Windows-Hosts hat es nicht ganz so gut geklappt.

Händisch zu verwalten halte ich für unpraktikabel. Wir sind im Sondermaschinenbau. In jeder Anlage ist was anderes eingebaut. Wir bestellen Komponenten, und bekommen halt irgendeinen FW-Stand geliefert.
 
TP-Inc schrieb:
Also der Inspector von Siemens bekommt über die X2 die PN-Teilnehmer die an X1 hängen mitsamt aller Sublots inkl. Firmware raus. Ich denke gerade bei PN-Devices, und die machen 90% unserer Netzwerke aus, muss das relativ einfach gehen. Bei Windows-Hosts hat es nicht ganz so gut geklappt.

Händisch zu verwalten halte ich für unpraktikabel. Wir sind im Sondermaschinenbau. In jeder Anlage ist was anderes eingebaut. Wir bestellen Komponenten, und bekommen halt irgendeinen FW-Stand geliefert.
Zum Vergrößern anklicken....
Funktioniert das dann auch für die Firmware von IO-Link Teilnehmern oder nur für den IO-Link Master?

Der PnozMulti der gar nicht am Netz hängt aber auch einen Firmware-Stand hat und zu den OT-Assets gehört dank USB-Schnittstelle, oder Lichtschranken und andere Sensoren die einen Controller besitzen und gehackt werden können werden vom PN aber nicht erfasst.

Das erfassen der Assets macht man ja nur einmal und da das Update händisch passiert, kann man das auch während dem Firmware laden ändern. Händisch hat nur den Nachteil, dass man es vielleicht vergisst oder Tippfehler passieren. Aber ich sehe keine andere Möglichkeit.
 
Ich hab mal eben ins Protokoll geschaut. Nein die IO-Link Devices tauchen nicht auf, nur der Master.

Bei dem Beispiel mit dem PnozMulti gebe ich dir schon recht. Aber alles was nicht im Netz hängt, braucht erstmal physikalischen Zugang zu dem Gerät. Den zu verhindern bzw. abzusichern obliegt dem Anlagenbetreiber. Wir als Anlagenhersteller, möchten in erster Linie bei der Abnahme dokumentieren, was alles über das Netz erreichbar ist, welche Schwachstellen es da gibt, was wir dagegen getan haben, und welche Pflichten der Betreiber hat.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hat jetzt mit deiner Frage nur indirekt was zu tun, aber ist
TP-Inc schrieb:
Asset-Discovery im Maschinennetz
Zum Vergrößern anklicken....
nicht schon an sich eine Sicherheitslücke.

Wenn die Teilnehmer auf irgendwelche Broadcasts Antworten dann weiß ich schon wo ich angreifen kann.
Wenn keiner Antwortet wird es schwieriger.
 
Tschoke schrieb:
Hat jetzt mit deiner Frage nur indirekt was zu tun, aber ist

nicht schon an sich eine Sicherheitslücke.

Wenn die Teilnehmer auf irgendwelche Broadcasts Antworten dann weiß ich schon wo ich angreifen kann.
Wenn keiner Antwortet wird es schwieriger.
Zum Vergrößern anklicken....

Ja hättest du einen Vorschlag wie man das verhindern kann? Ist ein Ping-Scan "irgendein Broadcast"? Wenn man innerhalb des Maschinennetz schon alles abdreht wird wahrscheinlich auch kein Datenaustausch zwischen dem Controller und Device möglich sein.

Das man schauen soll, dass man "von außen" schon schwer in dieses Netz reinkommt ist für mich ein anderes Thema.
 
Verhindern könnte man das nur theoretisch. Die z.B. PN Teilnehmer dürften dann nicht mehr auf DCP Antworten und auch auf Ping nicht.
(Dann müsste man beim PN Namen vergeben die MAC händisch oder so angeben)
Wäre halt nicht wirklich praktikabel.
Ich bezweifle das du mit der jetzigen Technologie im Maschinennetzwerk irgendwas sicherer machen kannst.
Die Lücken finden kannst du. Aber sie schließen eher nicht.
Was machst du z.B. wenn dein Portscann bei irgendeinem PN-Sensor oder so feststellt, dass FTP, SMB, HTTP oder sonst was offen ist?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Tschoke schrieb:
Verhindern könnte man das nur theoretisch. Die z.B. PN Teilnehmer dürften dann nicht mehr auf DCP Antworten und auch auf Ping nicht.
(Dann müsste man beim PN Namen vergeben die MAC händisch oder so angeben)
Wäre halt nicht wirklich praktikabel.
Ich bezweifle das du mit der jetzigen Technologie im Maschinennetzwerk irgendwas sicherer machen kannst.
Die Lücken finden kannst du. Aber sie schließen eher nicht.
Was machst du z.B. wenn dein Portscann bei irgendeinem PN-Sensor oder so feststellt, dass FTP, SMB, HTTP oder sonst was offen ist?
Zum Vergrößern anklicken....

Dann würde ich zumindest mal wissen, dass Ports offen sind, und könnte versuchen diese Dienste abzudrehen.
Aber aktuell ist unser erster Schritt tatsächlich mal den Iststand zu erfassen, und zu dokumentieren.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Dann wirst du vermutlich mit den Informationen die Dragos, Nozomi, Rhebo, ondeso & Co liefern erst mal erschlagen werden.

Ohne einen Test des Systems würde ich da nichts kaufen. Die sind einfach zu teuer dafür.

Man findet über die Systeme auch wenig vernünftige offizielle Dokumentation. Außer Hochglanzprospekten/PDFs und stundenlange Diskussionen über Statistiken auf youtube geben die Hersteller nicht viel preis. Somit ist es natürlich schwierig zu entscheiden welches Produkte deine Anforderungen erfüllt.

Ich halte von solchen Systemen also noch nicht sehr viel. Die kommen aus der IT und wollen jetzt in die OT. Man merkt aber halt dass die noch viel lernen müssen.

Wir haben kein solches System. Aber darüber nachgedacht haben wir schon. Wenn es sich nur um ein paar dutzend Geräte gehandelt hätte wäre mein Vorschlag gewesen manuell vorzugehen und sich das Geld zu sparen.

Das manuelle bearbeiten jedes Teilnehmers wird dir die Software aber auch nicht abnehmen. Viele lücken werden eh nicht geschlossen werden können, da Support durch Hersteller eingestellt oder neue Firmware nicht mehr mit Anwendung kompatibel etc. Auch der benötigte Stillstand und die Fehlersuche nach dem aktualisieren wird oft vergessen.

Ich würde erstmal mit einer sauberen Netzwerksegmentierung anfangen. Und wenn die dann steht würde ich mich um die einzelnen Teilnehmer kümmern. Dann kannst auch klein anfangen und dir mal nur ein Subnetz vornehmen.
 
Wir selbst und auch einer unserer größten Kunden benutzen hierfür Nessus. Strukturell sind beim Kunden die Netze so aufgebaut, dass alle Teilnehmer, auch die Profinet-Geräte, von extern erreichbar sind. Die Firewalls schottten dann das Anlagennetzwerk weg, lassen aber bestimmte Dienste wie Nessus zu.
So dinge wie bekannte CVE abklappern und nach bekannten laufenden Diensten suchen (FTP, SNMP Domain public, SNMP v1, ...) sind mit Nessus möglich.

Das Thema Asset-Daten lösen wir aktuell so, dass diese von den Profinet-Controllern eingesammelt werden, und dann mittels https-API von einem zentralen System abgerufen werden können. Nachteil ist, dass man an jeder Anlage dazu was programmieren muss.
Die Ansätze draußen im Feld gehen aber alle dahin, dass bekannt sein muss welche Gerätschaften verbaut sind.
 

Similar threads

M
Suche Tips für Bewerbungen
Antworten
16
Aufrufe
14K
MB_Plc_Starter
M
Safety
Retrofit von „Altmaschinen“, was fordert die Betriebssicherheitsverordnung
Antworten
0
Aufrufe
7K
Safety
Safety
Zurück
Oben