Klaus Mochalski
Hallo und herzlich willkommen zu einer neuen Episode von OT Security Made Simple. Ich bin Klaus Mochalski, Gründer von Rhebo. Mein Gast heute ist Klaus Kilvinger von der Opexa. Stell dich doch am besten gleich mal selbst vor für unsere Hörer.
Klaus Kilvinger
Hallo Klaus, danke für die Einladung. Ja, Klaus Kilvinger von der Firma Opexa Advisory aus München. Wir sind im Thema Informationssicherheitsmanagement aktiv und beraten unsere Kunden dabei, diese Systeme so im Unternehmen einzuführen, dass wir möglichst den meisten Nutzen stiften.
Klaus Mochalski
Wir hatten uns im Vorfeld abgestimmt, dass wir heute über die ISO 27001 sprechen wollen. Das ist ein Thema, mit dem sich jede mittlere bis größere Organisation mindestens schon einmal beschäftigt hat, viele vielleicht eine Zertifizierung gemacht haben.
Nun reden wir hier über OT Security und da war meine erste Reaktion: ISO 27001 hat doch mit OT Security überhaupt nichts zu tun. Da wird zumindest relativ selten drüber geredet. OT Security ist ein relativ neues Thema. ISO 27001 ist ja eine uralte Spezifikation.
Erzähl uns doch mal, warum hat das trotzdem was mit OT Security zu tun? Und dann für unsere Hörer, glaube ich, auch ganz wichtig, dass wir am Ende des Podcast dazu kommen, welche Aspekte hier insbesondere wichtig sind. Aber zuerst einmal zu der generellen Aussage: Die [ISO 27001] hat nichts mit OT Security zu tun.
Klaus Kilvinger
Ja, ich hole da ein bisschen aus. Also was ist denn die Grundlage der Idee? Eine Norm ist immer eine Vereinbarung zwischen Fachleuten, ein konkretes Thema zu adressieren, was für ein gewisses Segment einer Branche, einer Technologie oder Themen, eine mögliche Lösung wäre, Probleme anzugehen. Auf der Basis wurde die Grundlage der 27001 schon 1999 in England getroffen. Später ist dieses englische Normenwesen dann ins internationale Normenwesen überführt worden. Die letzte englische Version war [damals von] 2013. Du siehst, das ist schon ziemlich alt vom Grundsatz [her]. Die neueste Version ist aus dem Jahr 2022. Die hat natürlich auch vieles Aktuelles mitgenommen.
Die Grundidee der Norm der 27001 ist, ein Informationssicherheitsmanagementsystem zu haben, also das System nicht technisch zu sehen, sondern als Regelwerk zusammenhängender Regeln – wie Richtlinien, Prozesse, Mindestanforderungen, Hilfsmittel – sicherzustellen, um Sicherheit mit den drei Grundzielen Vertraulichkeit, Integrität und Verfügbarkeit im Unternehmen einführen zu können.
Die ISO 200001 sagt also erst mal gar nicht: Ist es jetzt Bürosystem? Ist es OT? Ist es Produktion? Ist es Logistik? Die Norm ist erst mal offen. Du kannst sie einsetzen, wo du willst, die ist auch nicht branchenspezifisch. Nun hast du aber natürlich das Grundthema, dass eine nicht branchenspezifische Norm jetzt in einem konkreten Umfeld die Welt retten soll.
Das heißt, sie ist so angelegt, dass sie offene Anforderungen stellt. Das ganze Dokument ist relativ kurz. Die ISO 27001, hat momentan – ich habe sie mal kurz im Hintergrund offen – insgesamt nur 27 Seiten. 27 Seiten, die neue KI-Norm, die ISO 42001 zum Vergleich hat über 50 Seiten. Also die klassische ISO 9001 [für Qualitätsmanagementsysteme] hat weniger als 20 Seiten. Du siehst, es sind verschiedene Auslegungsthemen und verschiedene Inhalte. Ich will einfach mal zwei Beispiele bringen, das ein bisschen transparent zu machen.
Klaus Mochalski
Bevor wir zu den Beispielen kommen, ganz kurz. Das heißt, die ISO 27001 ist eine durchaus überschaubare Norm. Wenn man die nicht kennt, hat man ja immer mal Angst, davon erschlagen zu werden, wenn man hört, wie aufwendig die Prozesse der Umsetzung sind. Das heißt, es ist durchaus eine Empfehlung, sich einfach mal das Dokument anzuschauen und durchzulesen. Das ist also durchaus machbar.
Und die Begriffe, die du jetzt genannt hattest, was dazu so zum Tragen kommt, insbesondere das Informationssicherheitsmanagementsystem, klingt ja jetzt für jemanden, der sich mit OT-Security beschäftigt, wiederum sehr vertraut. Und die Regulierung, die wir zum Beispiel für die kritische Infrastruktur haben, die setzt ja auch genauso ein Informationssicherheitsmanagement voraus. Und ich glaube, genau da kommt die Überlappung her.
Und jetzt wäre es, glaube ich, spannend, für unsere Zuhörer mal einfach zu zeigen, welchen Mehrwert ich für die OT Security bekomme, wenn ich die ISO 27001 in meinem Unternehmen umsetze. [...]
Klaus Kilvinger
Wir sehen die Mehrwerte in drei Themenbereiche. Der erste Themenbereich ist, wenn ich die 27001 im Unternehmen umsetze, setze ich sie idealtypisch im gesamten Unternehmen um. Das heißt also, sowohl Fachleute aus der Produktionstechnik, Fachleute aus der Netzwerktechnik, aus der industriellen Kommunikation, als auch Fachleute, die im Unternehmensnetzwerk aktiv sind, haben den Vorteil, sie unterhalten sich gemeinschaftlich über die Frage: „Wie mache ich unser Unternehmen sicher? Wie stelle ich sicher, dass morgen der Laden läuft?”
Mal salopp formuliert: Ich habe einen Kunden, der zum Beispiel das TISAX – ein Derivat aus der ISO 27001 im Automotive-Umfeld – eingeführt hat, weil er gesagt hat: „Gut, wenn bei uns das System steht. Ich habe jeden Tag 300 Lastwagen auf dem Hof, wenn es nicht weitergeht, stehen die entweder drinnen und kommen nicht mehr raus, weil wir nichts liefern können, oder die anderen kommen nicht mehr rein, weil ich sie nicht mehr entladen kann”. Das heißt also, Logistik, Produktion, Büro, Verwaltung arbeiten eng zusammen. Das ist der erste Vorteil.
Der zweite Vorteil: Wir haben eine allgemeine Anforderungsformulierung. Auf die Anforderung komme ich gleich.
Der dritte Vorteil ist: Ich kann so etwas zertifizieren. Das heißt, ich kann die Anwendung einer ISO 27001 durch einen dritten, durch einen professionellen Prüfer, der sich separat als Prüfer zertifizieren muss, bei entsprechenden Prüferorganisationen zertifizieren. Und kann das dann auch als Aushängeschild nach außen hängen, dass unser Unternehmen dieses Thema anwendet und damit auch ein hohes Maß an Sicherheit generiert.
Also das zu den drei Themenfeldern, wo ich die Profitabilität sehe. Kommen wir mal zum Beispiel zu einer Anforderung.
Klaus Mochalski
Kurze Frage dazu. Der letzte Vorteil, den du benennst, ist, man kann sich zertifizieren lassen. Das heißt, man kann sich den Stempel abholen, dass man hier seine Hausaufgaben getan hat. Wenn es jetzt um OT Security geht und ich eine Organisation bin, die in der automatisierten Fertigung arbeitet und dort natürlich OT-Anlagen betreibt: Wie viel OT Security bekomme ich denn durch die korrekte Umsetzung und Zertifizierung der ISO 27001? Habe ich da 50% meines Weges zurückgelegt oder vielleicht schon 100%. Wie ist dort deine Einschätzung?
Klaus Kilvinger
Hat erst mal nur eine allgemeine Anforderung. [...]
Die Norm hat zwei Teile im Wesentlichen. Es gibt oben einen normativen Teil, wo es um Prozesse geht, Verantwortlichkeiten, Kontext des Unternehmens. Wie werden diese unterstützt? Was muss ich operativ tun? Das ist noch relativ pragmatisch in vielen Unternehmen thematisierbar, aber es ist natürlich jetzt noch nicht fokussiert auf einen Punkt.
Im Anhang der Normen, da gibt es 93 Anforderungen. Diese 93 Anforderungen sind wiederum in vier Segmente unterteilt. Eins davon sind technologische Maßnahmen und zum Beispiel in der Anforderung 8.7 ist das Thema Schutz gegen Schadsoftware drin. Und das ist ja neutral. Habe ich in der OT oder in anderen Systemen genauso. Und die Norm sagt nur: Eine Maßnahme muss getroffen werden, und zwar, ich zitiere: “Schutz gegen Schadsoftware muss umgesetzt und durch angemessene Sensibilisierung der Benutzer unterstützt werden”.
Jetzt muss man so Normen immer Wort für Wort lesen. Das heißt, Schutz gegen Schadsoftware muss umgesetzt werden. Das heißt, ich muss einen Schutz gegen Schadsoftware entweder physisch, logisch, was auch immer machen – entweder ich habe eine Software drin oder ich habe mechanische Teile, ich habe vielleicht auch einen Stecker, den ich ziehe –, dass Schadsoftware gar nicht mehr reinkommt.
Die Norm sagt nur, ich muss etwas dazu tun. Ob die Kritikalität deines Systems dann einen erhöhten Aufwand bedeutet – weil du sagst: „Hey, das sind die Kronjuwelen. Wenn das nicht funktioniert, steht bei uns die ganze Produktion. Wir können hier nicht 100 Leute am Band stehen lassen” – das muss man dann mit den Fachleuten der OT besprechen. Dass wir sagen: „Hey, kann ich mit der Netzwerksegmentierung hier Sicherheit schaffen? Kann ich vielleicht ein System einsetzen, wo ich die Patches aktualisiere?”
Wir sehen immer wieder in Schwachstellenanalysen, dass Unternehmen ihre Patches nicht ordnungsgemäß aktualisieren. Die schieben das irgendwo auf die lange Bank: “Mache ich irgendwann”. Irgendwann wird es vergessen, Das heißt, hier gibt es auch Prozesse, die man braucht, um die Aktualisierung ständig auf dem Laufenden zu halten. Wenn ich in der Norm lese: “Schutz gegen Schadsoftware muss umgesetzt werden", ist es relativ einfach. Dann schaue ich im Unternehmen: Wie mache ich das zum Beispiel in der Büro-IT? Wie mache ich das bei den Servern, bei den Routern, bei irgendwelchen anderen Produkten, bei der Firewall? Und schaue mir dann in der OT auch an, welche Systeme gefährdet sind. Wo kann ich entsprechende Schadsoftware vermeiden oder wo kann ich sie organisatorisch vermeiden?
Es gibt ja immer die Frage: Wo kann ich es technisch vermeiden oder wo kann ich es organisatorisch unterstützen? Wenn ich einen alten Windows-96-Rechner habe, für den es keine Patches mehr gibt, muss ich mir was anderes überlegen. Den muss ich wahrscheinlich physisch trennen, weil ich sage, ich kann bei dem gar kein Risiko eingehen. Ich kann den nicht rausnehmen. Dafür gibt es keine aktualisierte Schutzsoftware mehr.
Klaus Mochalski
Das heißt, wie so viele Normen, sagt mir die Norm hier im Wesentlichen, was ich zu tun habe, aber nicht, wie ich es zu tun habe. Das heißt, ich bin nicht nur frei, sondern – das ist in den meisten Fällen vermutlich auch ein wichtiger Teil der Umsetzung – dass ich in meinen unterschiedlichen Unternehmensbereichen unterschiedliche Maßnahmen auswählen kann, die ich umsetze, die Anforderungen zu erfüllen. Die dann auch den spezifischen Gegebenheiten entsprechen, zum Beispiel meine Server oder meine Cloud-Infrastruktur zu schützen. Da sind im Hinblick auf Schadsoftware vermutlich andere Dinge zu tun, als bei meinen 20 Jahre alten nicht patchbaren Steuerungen und den alten Windows-System, die du zitiert hast.
Klaus Kilvinger
Genau. Und deswegen ist es auch so, dass ich die Norm auch in dem Fertigungsbereich anwenden kann. Wir treffen immer wieder Unternehmen, wo wir vor Ort eine Begehung machen und riesige Schränke sind mit ganz vielen Kabeln. Wo ich dann feststelle: Ja gut, wer hat denn den Verkabelungsplan hier parat? [Und als Antwort kommt:] “Das wissen wir noch nicht so genau, müssen wir noch nachziehen”. Nicht, weil die Kollegen unfähig sind. Die könnten das alles machen, aber die haben natürlich auch andere Ziele. Die müssen schauen, dass der Laden läuft. Die wollen gucken, dass die Produktion weitergeht, und Administration – die Verwaltung – versuchen sie, so minimal wie möglich zu [halten].
Alles nachvollziehbare Ziele, erst mal nichts Schlechtes. Aber was mache ich denn, wenn was schiefgeht? Wenn der Kollege, der die Verkabelung gemacht hat und dann vielleicht gerade im Urlaub ist oder im Ruhestand ist, wer weiß denn noch, wie was wo funktioniert? Das heißt, manchmal sind es einfach so lapidare Themen wie Verwaltung und Organisation, Dokumentation, die im Argen liegen, weil die Mitarbeiter sich eben mit anderen Schwerpunkten beschäftigen und sagen: „Verwaltungskram mache ich später”. Aber auch, sich gut zu organisieren und zu dokumentieren, gehört dazu. Und ebenso ein Thema wie Schadsoftware, dann zu sagen: „In der Verwaltung mache ich das, in der Fertigung mache ich das, in der Maschine mache ich das".
Wenn wir dem Prüfer dann zeigen: „Pass auf, das ist das Ziel! Das lösen wir – zack, zack, zack – mit den Themen!”, dann sagt der: „Okay, da habt ihr uns hier eben eine Antwort gegeben”. Die Norm kann ja nicht ins Detail gehen. Jedes Jahr gibt es tausend neue Protokolle, tausend neue Schadsoftware-Themen. Die Norm kann da gar nicht so schnell sein. Deswegen müssen wir uns da mit den Fachleuten in der Produktion unterhalten und sagen: „Was habt ihr für Sicherheitsmaßnahmen hier im Auge für dieses System? Was bietet der Hersteller beispielsweise an? Was kann ich selbst tun?” Und da ist die Norm sehr flexibel.
Also keine Angst vor der Norm, die tut nicht weh. Sie zwingt dich nur zu fragen: Habe ich meine Hausaufgabe gemacht? Habe ich was [gegen] Schadsoftware getan? Wenn ja, habe ich es dokumentiert? Ist es aktuell hinterlegt in einem System, wo ich das Ganze sehen kann? Haken dran.
Und dann der zweite Punkt: Angemessene Sensibilisierung der Benutzer. Das heißt, ich muss dann auch schauen: Wer bedient die Maschine? Wer steuert sie? Wer kümmert sich um die Aktualisierung? Was ist das Bedienerteam davon? Sind das alles munterer Leute, die von der Maschine aus versuchen, ins Internet zu gehen oder da irgendwo ihren Laptop dranstecken oder von anderen Leuten irgendwelche USB-Sticks dranstecken, wo sie nicht wissen, was drauf ist?
Also auch hier geht es in dem zweiten Teil [darum], diese Sensibilisierung für die Mitarbeiter mitzunehmen. Nicht, weil die jetzt alles zu Cybersicherheitsexperten werden sollen, sondern weil man einfach das kleine 1-Mal-1 absichern sollte. Dass man sagen kann: “Das tue ich nicht! Und wenn ich nicht sicher bin, wen kann ich fragen?”
Klaus Mochalski
Ja, das ist ein guter Hinweis, den du hier gibst. Die Norm scheint erst mal sehr gut passend auch für den OT Security Bereich zu sein. Wir wissen, dass viele OT-spezifische Normen auf der ISO 27001 basieren und dort in bestimmten Bereichen weiter ins Detail gehen. Gibt es denn, bezogen auf die ISO 27001, mögliche Gegenargumente von Betreibern von OT-Infrastruktur, die sagen könnten: “Die ISO 27001 ist für mein Umfeld nicht passend, weil sie Dinge fordert, die ich nicht umsetzen kann”? Du hast schon gesagt, dass in OT-Infrastrukturen häufig die Verfügbarkeit, dass die Produktion läuft, häufig das oberste Ziel ist. Dahinter treten Ziele wie Datenschutz zurück. Sorgen diese spezifischen Anforderungen dafür, dass ich in bestimmten Bereichen die ISO 27001 nicht anwenden kann?
Klaus Kilvinger
Nichtanwendbarkeit ist ein Märchen. Wir haben nämlich zwei große Stellschrauben, die wir dabei einsetzen können.
Zum einen: Du hast – Punkt 1 – immer eine risikoorientierte Vorgehensweise. Sprich, bei Systemen, die kein Risiko haben, muss ich ja nichts tun. Aber dann muss ich klar sein: Was habe ich für ein Risiko? Ist es groß, klein? Wie viele Leute sind betroffen? Welcher Standort? Welche Größe? Welche Produktion? Ich muss mir erst mal selbst Gedanken machen: Welches Risiko fahre ich hier, die Norm zu nicht anwendbar zu erklären? Und du hast die Möglichkeit, mit dem Auditor einen Scope zu besprechen, zu sagen: „Pass auf, die Norm gilt beispielsweise nur für die Produktion im Werk 1 in Fulda. Im Werk 2 in Leipzig sind wir noch nicht so weit, die kann ich noch nicht anwenden. Da werden wir uns erst hinarbeiten. Wir machen erst mal nur einen Scope für diesen Standort. Da sind wir sauber, da haben wir unsere Hausaufgaben gemacht, da haben wir moderne Maschinen, alles gut. Und den anderen Standort nehmen wir aus dem Scope heraus, die ist dann nicht mit drin”.
Das heißt, du hast Stellschrauben – einmal Risiko und zum anderen Scoping – die dir helfen, das Ganze anwendbar zu machen.
Klaus Mochalski
Okay, es ist also sehr, sehr wichtig zu verstehen, dass es keinen Grund gibt, sich der ISO 27001 im OT-Bereich zu verweigern. Und hier, noch mal positiv, Argumente zu liefern. Wir hatten schon angefangen, über den Anhang zu sprechen und die 93 Punkte, die es dort gibt. Da hattest du unter anderem über Schadsoftware gesprochen, und das ist natürlich ein Riesenthema in der OT, was auch häufig diskutiert wird. Du hast aufgezeigt, wie dort die Anforderung aus der ISO 27001 genau im OT-Bereich umgesetzt werden kann.
Was gibt es denn noch für Aspekte? [...] Wir haben jetzt eigentlich über drei Beispiele gesprochen und bei allen dreien, die du genannt hattest, habe ich sofort gesagt: Mensch, darüber reden wir in der OT ständig. Was sind denn andere gute Beispiele?
Klaus Kilvinger
Diese Anforderungen im Anhang sind erst mal offen formuliert, zum Beispiel in der Anforderung 8.8. Da geht es um die Handhabung von technischen Schwachstellen. Technische Schwachstellen gibt es überall. Jedes System hat seine eigenen Schwachstellen – alte, neue Systeme und und und. Und mit jedem Microsoft Patch-Day, den ich habe, kommen vielleicht neue Schwachstellen rein, alte werden geschlossen.
Was man natürlich auch der Softwareentwicklung ankreiden darf, wenn man sich jetzt mal über Prozesse unterhält. In der Softwareentwicklung – und das gilt für die OT genauso – ist es ja oft so, dass im Rahmen einer Softwareentwicklung auch manchmal Codeteile adressiert werden, die erst mal keine “Schadstoffe” haben oder keine potenziellen Schwachstellen, dass aber im Laufe der Entwicklung - über die Jahre hinweg – auch mal andere Codeteile mit reinkommen, andere adressiert werden, andere rausfallen. Die Systeme leben! Und deswegen ist immer die Frage: Was habe ich für einen konkreten Schwachstellenpool vor mir?
Und hier sagt die 8.8: Handhabung von Schwachstellen, ich zitiere noch mal kurz: „Es müssen Informationen über technische Schwachstellen verwendeter Informationssysteme eingeholt, die Gefährdung der Organisation durch derartige Schwachstellung muss bewertet werden und angemessene Maßnahmen [sind] zu ergreifen”. Das heißt, wenn du jetzt einen Zoo von 100 verschiedenen Maschinen [hast], die über 30 Jahre alt [sind], verschiedene Elemente der Entwicklung und der Fertigung darstellen, dann holst du dir vielleicht von der Maschine – hier die Maschine Eins – die jetzt fünf Jahre alt ist, [erstmal die Informationen ein.] Was hat der Hersteller für Hinweise? Was gibt es im Handbuch? Was gibt es vom Hersteller für Themen? Was hat der Bediener erfahren? Was hat der Programmierer erfahren? Was haben wir da geändert?
Und das ändert sich ja auch laufend. Wenn ich jetzt mal sage, eine Firma hat 100 verschiedene Softwarelösungen in verschiedenen Bereichen – vielleicht 30 in der Verwaltung, 70 im OT-Bereich – weil sie verschiedene Systeme haben. Der eine hat die italienische Schleifmaschine, der andere hat eine schweizerische Bohrmaschine und was es alles gibt, und dann wiederum der Schweizer Roboter. Jeder hat sein eigenes Umfeld, und jeder hat seine eigene Gefährdung. Das heißt, da mal grundsätzlich die Motorhaube aufzumachen und zu sagen: „Okay, was habe ich für ein Risiko bei der Maschine? Was sagt mir der Hersteller? Was sollte nicht getan werden?”
Dafür brauche ich eine strukturelle Idee! Wie verwalte ich denn so was? Wie schreibe ich denn so etwas auf? Gehe ich einmal im Monat durch und schau mir alle Hersteller an und frage: „Was gibt es Neues?” Also diese strukturelle Maßnahme ist zum einen das, was man tun sollte oder wo man sagt: „Ich stelle mir den Newslettern von dem Hersteller ein, dass er mir das Neues zuschickt. Dann muss ich nicht selber suchen”.
Also diese Sammlung von Schwachstellen ist erst mal ein ganz wichtiger Punkt. Das ist auch in der OT – genauso wie in der normalen IT auch – immer so etwas, das macht keiner gerne. Aber es muss halt gemacht werden. Oder man googelt einmal im Monat zu dem Hersteller: Was war da? Oder in den Medien: Was ist in Heise? Was ist in Produktionszeitschriften? Und so weiter.
Dann das Thema Gefährdung. Auch hier ist wieder die Frage: Was habe ich für ein Risiko? Wenn eine Gefährdung für die Maschine A groß ist, ist sie für eine Maschine B vielleicht überhaupt nicht relevant. Gut, Haken dran. Die kann ich ausschließen. Dann muss ich meine Gefährdung ermitteln und dann kann ich sagen: Da muss ich was tun und da muss ich nichts tun. Ist schon mal gut, dann habe ich schon mal 50% der Arbeit weggeschöpft. Gut, Haken dran.
Und dann Maßnahmen ergreifen, das heißt:
- potenziell neue Patches einspielen,
- vielleicht Netzwerksegmentierung aufbauen oder
- Maschine vom Netz nehmen oder
- Maschine ausschalten vielleicht auch.
Vielleicht ist das Thema so gravierend, dass ich es momentan gar nicht lösen kann, weil auch der Hersteller sagt: „Hmpf, haben wir echt keine Lösung dafür! Die Maschine ist jetzt out of production. Wir sind nur noch in der Wartungsphase. Wir müssen schauen, was wir überhaupt noch lösen”. Und dann müsst ihr euch überlegen in der OT: Finde ich einen Workaround? Finde ich irgendwo eine andere Lösung, wie ich das mit der Maschine machen kann? Also von daher sagt die Norm hier auch nicht, was du genau [tun musst]. Aber du musst dir überlegen, was ist dein Problem und wie kannst du es angehen?
Klaus Mochalski
Ja, klingt wieder sehr vertraut und wie Dinge, die man auch in der OT schon seit Jahren hört, als Best Practices sozusagen. Der einzige Aspekt, über den ich hier stolpere, ist das Einholen von Informationen, denn das kann gerade in der OT manchmal schwierig sein. Weil ich vielleicht meinen Hersteller gar nicht mehr ansprechen kann diesbezüglich. Weil es den vielleicht nicht mehr gibt. Weil die Komponente eben nicht mehr gepflegt wird. Da gibt es viele verschiedene Gründe.
Aber ich glaube, auch da kann man sich dann … [Die Norm] sagt ja nicht, was Einholen bedeutet. Dass ich den Hersteller anspreche, was ich vielleicht nicht kann. Sondern da muss ich mir dann Unterstützung holen. Vielleicht hat jemand anders diese Maschine schon mal auf Schwachstellen geprüft, und ich habe Informationen aus dritter Hand, aber das kann man eben auch wiederum lösen.
Klaus Kilvinger
Das hängt ein bisschen an der Problemstellung. Wie mache ich denn das? Beispielsweise fordert die ISO 27001, dass ich eine regelmäßige Überprüfung meines Informationssicherheitsmanagementsystems mache. “Regelmäßig” im Wording der Norm heißt jetzt nicht alle fünf Minuten nachschauen, ob sich was geändert hat. Aber mindestens einmal im Jahr sollte ich durch alle Kapitel durchgehen: Hat sich da was getan? Hat sich da was getan? Hat sich da was getan? Und dann kann ich auch in der OT sagen: Ich schaue einmal im Jahr, ob sich zu den Maschinen was getan hat. Und dann muss sich jemand hinsetzen, den Fuhrpark durchschauen.
Wenn ich das nicht tue, gehe ich das Risiko ein, dass ich erst dann nachschaue, wenn es kracht. Und dann muss ich sowieso schauen. Das heißt, diese proaktive Maßnahme soll ja dazu dienen, dass du erstens den Patch-Day nicht verpasst, der irgendwo kam. [Denn häufig heißt ja:] “Ja, den haben wir jetzt verschoben, weil in der Produktion durften wir die Maschine nicht vom Netz nehmen. Die musste jetzt 24 Tage durcharbeiten. Wenn ich es gepatcht hätte, hätte ich wieder Pause machen müssen, hätte ich es vom Netz nehmen müssen. Ich hatte die Zeit nicht in der Produktion”. Ganz normale Prozesse werden ja in der Fertigung damit potenziell torpediert, indem ich eine Maschine updaten muss.
Und das will ich natürlich vermeiden, indem ich eine strukturelle Maßnahme treffe, dass ich sage: „Okay, einmal im Jahr schauen wir uns jede Maschine an, ob irgendwas war. Bei 50% tut sich wahrscheinlich nichts, Haken dran. Aber ich weiß [dann wirklich, dass sich] da auch nichts getan hat. Dann kann ich gut schlafen. Vielleicht hat sich bei 25% etwas getan im Sinne: “Update kommt am 1. Januar 2026, wir müssen die neue Maschinenverordnung einhalten, wir müssen…” Dann weißt du schon, es kommt was, du kannst dich darauf einstellen. Und der andere Punkt ist: Ups, bei 25% der Maschinen muss ich was tun.
Und diesen Prozess in Gang zu setzen, ist auch teilweise ein Mindset, wo man einfach sagt: “Ich muss mich drum kümmern, dass der Laden immer aktuell bleibt”. Genauso wie du ein Auto zum TÜV bringst und dann auch alle zwei Jahre die neue Bremsflüssigkeit willst, damit du nicht beim Bremsen irgendwo mal eine Überraschung erlebst, die du nicht brauchst, ist es mit der Maschine. Dass du auch da deinen TÜV hast. Da kommt auch der TÜV vorbei und prüft vielleicht irgendwelche Geräte. Da kommt dann halt der Wartungstechniker vorbei.
All diese Themen sollten in ein organisatorisches Korsett gepackt werden. Ein Informationssicherheitsmanagementsystem kann dir eben helfen, das auch zu dokumentieren, damit du weißt: „Okay, ich habe für die Anforderung 8.8 zum Thema Schwachstellen die und die Maßnahmen gemacht. Das ist das Ergebnis. Haken dran”.
Klaus Mochalski
Da hört man auch heraus, dass du dich schon viele Jahre damit beschäftigst und das ist dir insbesondere der proaktive Ansatz [wichtig ist]. Das heißt, nicht nur den Stempel bekommen, nicht initial, sondern dann auch permanent und proaktiv an der weiteren Umsetzung zu arbeiten.
Zusammenfassend, was kannst du denn unseren Zuhörern, die aus der OT Security kommen, noch einmal empfehlen? Was ist der Hauptnutzen, wenn man die ISO 27001 einführt und sich zertifizieren lässt? Und wie gehe ich denn vor? Wie starte ich denn damit? Was sind die ersten Schritte?
Klaus Kilvinger
Der Hauptnutzen ist erst mal, dass man sich eine Struktur aufbaut, wie man die Sicherheit sichern kann. Vvm Wording müsste ich mir was Besseres einfallen lassen. Aber die Grundidee dahinter ist ja: Wenn ich mich nicht proaktiv damit auseinandersetze, wie ich das organisiere, wird mich irgendwann das System zwingen, wenn es kracht, mich zu organisieren. Und dann habe ich keine Zeit.
Klaus Mochalski
Und so wie ich es verstanden habe, ist es organisationsübergreifend. Das heißt, es betrifft alle Bereiche des Unternehmens. Ich kümmere mich nicht mehr nur um die IT, die OT, die Administration, sondern ich kümmere mich automatisch um alle Bereiche.
Klaus Kilvinger
Wenn ich Netzwerkschwachstellen habe, die potenziell aus der Verwaltung überschwappen in meine Organisation in der Fertigung, habe ich keinen Spaß. Umgekehrt haben die Jungs da drüber auch keinen Spaß. Das heißt also, wir sollten immer die Idee [verfolgen]: „Hey, wir wollen die gesamte Firma sicher haben, wir wollen alles verfügbar haben, wir wollen die Daten richtig haben und wir wollen sie vertraulich haben, damit nicht irgendwelche Produktionsdaten an Dritte gehen, die bauen dann die gleiche Maschine nach, wie wir sie machen”.
Klaus Mochalski
Absolut, sofort einsichtig. Und ganz kurz zum Abschluss: Erster Schritt für Neulinge?
