users lounge Cover

users lounge

Der Podcast für mehr IT-Sicherheit

Since 09/2023 72 Episoden

#29 ITC - Technologische und branchenspezifische Compliance

Maßgeschneiderte Lösungen für individuelle Anforderungen der IT-Compliance

25.10.2024 56 min

Zusammenfassung & Show Notes

Wie gelingt IT-Compliance in dynamischen Branchen? Wir sprechen über technologische und branchenspezifische Anforderungen, wobei Regelwerke, Normen und Dokumentation das Fundament bilden und Automatisierung, Monitoring und klare Update-Richtlinien für Sicherheit sorgen.

IT-Compliance verlangt von uns nicht nur ein solides Fundament aus Regeln, Normen und Dokumentation, sondern auch die Fähigkeit, technologische und branchenspezifische Anforderungen gezielt zu berücksichtigen. Jede Branche bringt eigene Herausforderungen mit sich – deshalb setzen wir auf flexible, anpassungsfähige Lösungen, die sich in unseren Arbeitsalltag integrieren lassen.

Wir überprüfen regelmäßig unsere Prozesse und Compliance-Maßnahmen, um auf Veränderungen wie Unternehmenswachstum oder neue Technologien vorbereitet zu sein. Dabei ist es uns wichtig, dass Compliance nicht nur eingehalten, sondern auch messbar wird.

Automatisierung und die kontinuierliche Überwachung unserer Systeme helfen uns, zuverlässig zu agieren und frühzeitig zu reagieren. Klare Richtlinien – etwa für Software-Updates – sorgen dafür, dass unsere Compliance-Strategie nicht nur heute greift, sondern auch zukunftssicher bleibt.

Takeaways

Compliance ist ein Framework für Unternehmen.
Ohne Regelungen gibt es Wildwuchs.
Dokumentation ist der Schlüssel zur Compliance.
Schreibt es auf, kümmert euch um die Compliance.
Stand der Technik ist nicht das Neueste.
Branchenspezifische Regelungen sind entscheidend.
Technologie muss flexibel sein.
Compliance schützt vor großen Problemen.
Regelungen müssen begründet werden. Regelmäßige Überprüfung von Prozessen ist entscheidend.
Compliance muss jährlich überprüft werden.
Neue Technologien müssen in bestehende Systeme integriert werden.
Wachstum erfordert klare IT-Richtlinien.
Messbarkeit ist der Schlüssel zur Compliance.
Automatisierung kann Compliance unterstützen.
Audits sind wichtig für die Systemüberwachung.
Richtlinien für Software-Updates sind unerlässlich.
Zukunftsorientierte Compliance-Strategien sind notwendig.
Mitarbeiter müssen über Compliance-Richtlinien geschult werden.

Transkript

René

00:00:40

Moin Michael.

Michael

00:00:42

Genau, ich bin der Michael Kornmann und wir beide unterhalten uns heute über das Thema IT Compliance. Das ist ja eine Serie, wo wir uns die ganze Zeit schon mit beschäftigen und heute geht es eher so um technologische und branchenspezifische Compliance. Das heißt, wir gucken uns das Compliance-Thema an und gehen nochmal so auf ein paar Spezialitäten und Besonderheiten von verschiedenen Branchen ein und schnacken ein wenig darüber. Genauso tun wir das René.

René

00:01:07

So sieht es aus.

Michael

00:01:09

Super.

René

00:01:10

Ja, wir haben es ja bisher immer sehr allgemein gehalten, also sprich, dass wir gar nicht erst auf bestimmte Branchen geguckt haben. Das machen wir heute doch mal, weil auch da gibt es ja einige Dinge, die sich zu allgemeinen Compliance-Regeln oder Richtlinien dann doch unterscheiden. Und nehmen wir mal technologische Compliance grundsätzlich einmal. Ja, logischerweise, was ist es grundsätzlich? Das haben wir die letzten Male immer mal wieder schon angeschnitten. Was sind unsere Vorgaben? Also es gibt zum Beispiel, man könnte sich als Compliance nehmen, Cloud-first. Das ist so eins der Dinge. Manche Unternehmen setzen das für sich fest, dass sie sagen, okay, wir möchten keine Hardware mehr im Haus haben oder möglichst wenig und lagern dann alles in die Cloud aus. Das wäre zum Beispiel eine dieser Vorgaben, die man in diesen Richtlinien festlegen kann. Auch was den architektonischen Aufbau des Netzwerks oder der Infrastruktur betrifft, das lässt sich damit natürlich auch festschreiben. Dürftest du wahrscheinlich in deinem von dir betreuten Unternehmen auch kennen?

Michael

00:02:26

Ja, an sich ist es, ich breche es mal so ein bisschen rüber. Du gibst dir quasi über die Compliance-Richtlinien ein Framework, wo du dich orientieren willst in deinem Unternehmen, was du tun willst, was du lassen willst, Richtlinien. Und auf Basis dessen erstellst du dann im Prinzip technische und organisatorische Maßnahmen, um eben die IT-Sicherheit und die Compliance eben sicherzustellen und da einfach einen sauberen Schnitt in deinem Unternehmen drin zu haben. Und dafür braucht es Anforderungen. Ich kann schon mal ein bisschen teasern, auch für die nächsten Folgen schon. Du musst schon wissen in deinem Unternehmen, erlaube ich KI, erlaube ich KI nicht? Ja, was darf ich erlauben? Benutze ich eine Cloud, will ich eine Cloud, will ich eine Cloud ganz vermeiden? Auch die Philosophien fahren nach unterschiedlichen Firmen und das musst du halt oder solltest du halt alles in entsprechenden Informationen so aufbereitet haben und so festgelegt haben, dass du weißt, worüber du sprichst und eine Basis hast, wie du die IT-Sicherheit im Unternehmen aufbaust. Ja, ohne geht es nicht. Ohne geht es nicht, ja. Der Klassiker ist ja, ich bringe mal das KI-Thema, weil es bei mir im Moment ziemlich akut ist und ich in der Betreuung gerade intensiv mitarbeite. Du musst halt Dinge im Unternehmen regeln und wenn du es nicht regelst, hast du Wildwuchs. Es ist wie immer und überall und du musst im Unternehmen Regelungen schaffen, um zu sagen, wir erlauben KI, wir erlauben folgende Software-Dienste beziehungsweise folgende Cloud-Dienste. Wir wollen jetzt, dass wir zum Beispiel OpenAI benutzen dürfen oder wir wollen Copilot arbeiten oder wir wollen nur das eine, wir erlauben beide. Also du musst klare Regeln haben. Wenn du diese klaren Regeln nicht im Unternehmen eingeführt hast und es nicht irgendwo niedergeschrieben hast, es war jetzt da stets, ja, dann hast du im Unternehmen einfach einen Wildwuchs, den du nicht mehr beherrschen kannst. Ich meine, das zieht sich ja durch diese Themen, wie wir sie alle besprechen, durch. Ich meine, du kennst das auch, oder? Was nicht geregelt ist, ist freiwillig.

René

00:04:29

Ja, Dokumentation ist natürlich immer ein Punkt und Dokumentation im weitesten Sinne. Richtlinien sind natürlich da nochmal, ja, das ist halt etwas, wo man sich dann für die Zukunft immer komplett daran orientieren kann. Einmal festgeschrieben und dann kann man, ich meine, natürlich, sowas lebt auch mit der Zeit, aber sowas hat man dann halt und kann sich dann immer wieder darauf beziehen. Das ist, denke ich, sehr, sehr wichtig.

Michael

00:04:56

Genau, es leitet einfach viele, viele Dinge im Unternehmen ab, wenn du irgendwann mal so Grundsatzentscheidungen niedergeschrieben hast und die musst du niederschreiben. Das bringt dir nichts, wenn du sagst, in der Geschäftsleitung oder bei irgendeinem Meeting sowas mal beschließt und sagst zum Chef, hier, pass auf, wir machen das, und der Chef sagt, oh, wir machen es so und so oder die IT legt das fest und ein Vierteljahr später sagst du, ja, wir haben doch mal ein Meeting gehabt, da hatten wir doch gesagt, ich glaube, wir wollten keine KI im Unternehmen einsetzen. Und dann sagt jeder, ja, wo steht denn das? Kann ich mich nicht mehr daran erinnern, etc. Das sind so diese Klassiker, die du einfach immer hast und deswegen schreib es nieder, schreib dir die Anforderungen nieder, dokumentier es, lass dir es von den Verantwortlichen unterschreiben, dann hast du eine Basis, auf die du aufbauen kannst und mit die der ITler und der, der sich um die IT kümmert, dann halt auch sicher im Unternehmen arbeiten kann.

René

00:05:53

Ja, also gerade auch der ITler, wie, sagen wir mal, wenn jetzt ein neuer ITler mit in das Unternehmen kommt, der muss ja irgendwas an der Hand haben, damit er überhaupt weiß, wonach er sich orientiert. Wenn er gar nichts an der Hand hat, ja, dann sucht er nachher Techniken raus, die nachher gar nicht vom Unternehmen gewünscht sind, die man, die vielleicht auch gar nicht umsetzbar sind, weil sie nicht vereinbar mit dem sind, was bisher irgendwie verfolgt wurde. Also dafür ist es natürlich auch Gold wert und sehr, sehr wichtig. Ja. Und da gibt es halt ganz viele Möglichkeiten, also was auch Technologien angeht. Gerade habe ich ja gesagt, okay, Cloud First ist eins der Dinge. Es gibt natürlich auch so Dinge, IoT, KI, wie du schon gesagt hast. Also es ist die Technik einfach dahinter, wofür man dann eben entsprechend die Compliance aufsetzt. Blockchain wäre vielleicht auch noch so ein Ding.

Michael

00:06:43

Ja. Oder halt eben so ganz basic, runder gebrochene Dinge. Also du bist mit Blockchain ziemlich technisch unterwegs, alles cool, aber das Basics bei uns im Unternehmen wird kein HomePod und keine Alexa eingesetzt. Also sprachgesteuerte IoT-Systeme, also sprachgesteuerte Smartsysteme werden in unserem Haus nicht eingesetzt. Das sind so Dinge, die lege ich grundlegend fest. Das muss auch irgendwo mal festgelegt werden, weil ein permanent mitlaufendes Mikrofon wollen, glaube ich, die wenigsten Unternehmen in ihrem Unternehmen laufen haben. Erst recht, wenn sie in einem Büro oder in einem Mietingraum oder sowas drinstehen. Das muss an irgendeiner Stelle mal irgendwie festgelegt werden. Sonst hast du nachher fünf Alexas in der Bude sitzen und der Chef geht durch die Hütte und der Mitarbeiter sagt, keiner verboten, der steht hier seit einem halben Jahr. Dann hast du den Spaß. Dann musst du dich kümmern. Und deswegen finde ich es immer super einfach, auch wenn es wirklich für manche nervig ist, schreibt es auf, kümmert euch um so ein paar Dinge, guckt euch an, was passieren kann oder was ihr für Sachen habt und schreibt es euch in Compliance-Richtlinien und in irgendwelchen Dingen schreibt es euch auf.

René

00:07:57

Das war ja jetzt noch recht oberflächlich, ist aber natürlich auch sehr richtig. Aber was mir gerade direkt als Gedanke noch zusätzlich kam, wenn du jetzt sagst, okay, wir müssen, nehmen wir mal an, wir würden jetzt Homepods, Alexas, wie auch immer, alles untersagen, dann ist ja dann auch die Frage, was mache ich denn im Homeoffice? Sage ich dann auch, okay, das darf keiner haben, weil wenn er jetzt in Meetings, also wenn die Person in einem Meeting ist mit den Kollegen, da geht es um Geschäftszahlen, keine Ahnung was, muss ja genauso aufpassen.

Michael

00:08:34

Ja, aber das musst du regeln. Richtlinien für die Untersuchung vom Homeoffice. Da kannst du so Dinge einfach festschreiben und da kannst du sowas machen. Das geht auch. Ich meine, da kommen wir von Hippies auf Dippies, da kommen wir echt in die Tausend rein. Firmenhandy, erlaube ich Google Drive Synchronisation, iCloud Synchronisation, also all diese Sachen. Wie richte ich ein Firmenhandy ein? Welcher Account kommt drauf? Wer richtet ein Account ein? Das sind alles technologische Compliance oder technologische Richtlinien, die ich mir geben muss und Spielregeln und ein Framework, was ich mir geben muss, damit das einfach immer gleich ist und immer sichergestellt ist, dass es richtig gemacht ist. Also richtig im Sinne von, so möchte es die Firma haben, so hat das die Firma, das Unternehmen es mal beschlossen. Ob es nachher DSGVO-konform oder was die wollen, Schritt zwei, kommen wir später zu. Aber erstmal geht es da drum, dass der ITler oder die Person auch immer, die irgendetwas einrichtet oder irgendwas anschafft oder whatever, weiß, es handelt im Sinne des Unternehmens. So will es der Chef. Und dafür sind halt eben die Compliance und gerade im technologischen Bereich mega wichtig.

René

00:09:42

Ja und, also du hast gerade gesagt, so will es der Chef. Wichtig ist natürlich, dass in den Compliance auch ein bisschen dargelegt wird, warum das Ganze so ist. Also bevor wir jetzt wirklich sagen, komm, setzt euch dahin, schreibt einfach auf, was ihr gerne wollt und dann machen wir es in Zukunft so. Also da gehört natürlich auch eine gewisse Begründung dazu. Es muss auch einfach technisch begründet sein, warum man das so macht. Nicht bis ins letzte Detail, das muss an anderer Stelle auch geschehen, aber in der Compliance sollte grundsätzlich das auch wiedergegeben werden, weil diese sollten wir ja später auch den Mitarbeitern und so an die Hand geben, nachlesbar machen und da macht es Sinn, dass da auch eine Erklärung drin ist.

Michael

00:10:22

Hier René, ich bin da voll bei dir, ganz klar. Wenn du Entscheidungen triffst, musst du es an irgendeiner Stelle, also am besten in dieser Stelle, in einer gewissen Art und Weise so begründen und so darlegen, dass, wenn das wieder zur Diskussion steht, du genau weißt, warum du damals diese Entscheidung getroffen hast. Wir setzen in unserem Unternehmen kein WhatsApp ein, weil WhatsApp ein hohes Datenschutzrisiko ist, weil wir eine Übermittlung oder keinen Zugriff von Amerika auf die Daten ausschließen können. Punkt. Wenn in einem halben Jahr oder in einem Jahr die Diskussion wieder losgeht, dann kannst du dir deine Compliance-Richtlinie schnappen und dann kannst du sagen, das ist entschieden aus den und den Gründen. Haben sich die Gründe geändert? Ja, nein. Haben sich die Gründe nicht geändert? Oh Wunder, dann wird das wohl noch Gültigkeit haben und wir rütteln da nicht dran. Deswegen muss es, wie du schon gesagt hast, es muss begründet sein, dass du argumentieren kannst und nach einem halben Jahr weißt oder nach Zeit X weißt, warum habe ich die Entscheidung getroffen? Ganz klar.

René

00:11:27

Ja, und darüber hinaus gibt es dann natürlich auch nochmal Anforderungen und Standards. Du hast es gerade schon kurz angeschnitten. Da gibt es ja gewisse Frameworks, da gibt es auch gewisse Vorgaben, die einfach rechtlich schon da sind, wie zum Beispiel die ISO-Norm 27001 oder 27076. Da gibt es ja schon einige Sachen, an denen man sich auch orientieren kann zusätzlich zu seinen eigenen. Das haben wir aber ja schon die letzten Male gesagt. Man sollte immer von dem eigenen erstmal ausgehen und das dann mit der rechtlichen Schiene in Einklang bringen.

Michael

00:12:06

Ja, also das ist, wenn du solche Anforderungen hast, hast solche Normanforderungen, die du erfüllen willst und willst das tun, dann hast du halt ein Framework, dem du dich unterwirfst, was nochmal einen Rahmen widerspiegelt und dir nochmal einen Trigger gibt für gewisse Anforderungen oder gewisse Dinge, die du zu überprüfen sollst oder die du zu überprüfen hast. Und da sind natürlich zertifizierbare Normen immer sehr wichtig. Die 27076 ist nicht zertifizierbar. Das ist übrigens nur dieser Cyber-Risiko-Check, nur dass wir da mal kurz formal bleiben. 27001 wäre zertifizierbar bzw. IT-Grundschutz wäre noch eine Sache, wo ich Nachrichten richten kann. Das sind so Dinge in Informationssicherheit, wonach ich gehen kann. Und wenn ich sage als Unternehmen, ich brauche das oder ich möchte das, dann habe ich natürlich das Framework, was mir den Rahmen gibt, in dem ich spielen darf, bewegen darf und wo ich meine Compliance eben entsprechend beschreiben darf und muss und was ich tun darf.

René

00:13:02

Ja, also die 27076, nur nicht, damit wir uns da falsch verstehen. Ja, ich weiß, das ist nicht zertifizierbar, ist aber für mich immer so diese Grundlage wirklich für den Grundschutz. Das ist ja immer die Frage, woran man sich gerade auch wirklich orientiert. Also, wenn jetzt ein Unternehmen für sich sagen sollte, okay, wir möchten den Grundschutz einführen, also wir möchten wirklich diesen mindestens erreichen, dann ist dieser Cyber-Risiko-Check wahrscheinlich eine gute Grundlage, ist aber natürlich nicht zertifizierbar. Du hast absolut recht.

Michael

00:13:33

Ja, es ist ein super guter Anfang. Es ist ein super guter Anfang, womit ich meinen Einstieg kriege in die Informationssicherheit oder das erste Gefühl dafür kriege. Und ich habe jetzt, dass bei zwei Unternehmen, die jetzt anfangen mit NIST 2, da ist das auch ein super guter Startpilot. Auch nur ganz kurz einen Ausflug am Rand, dann kann ich das so als Startpilot gut nehmen und kann sagen, pass auf, damit steigen wir mal ein. Und dann gucken wir mal, wie es weitergeht und wie die Reise beginnt, aber so als Ist-Aufnahme und dafür ist die 27076 sehr gut. Aber nicht das Thema, ist glaube ich der nächste oder übernächste Podcast, da steigen wir in die NIST 2 Thematik noch mal ein bisschen tiefer ein. Ja, und abgesehen davon, auch NIST 2, ganz kurz ein Thema bleiben. Auch das ist eine rechtliche Anforderung, die ich habe. Das KI-Gesetz, also alles, was jetzt kommt und was so als Gesetz auf dem Markt ist, was als gültigen Gesetz unterwegs ist, wo ich mich als Unternehmen unterwerfen darf und worüber ich mich kümmern kann. Alles das sind natürlich Dinge, die ich in meine Compliance-Mitte einschließen muss. Inklusive DSGVO, ja auch das. Es hilft mir jetzt nichts, irgendwelche Compliance zu machen, die weit weg sind von den gesetzlichen Anforderungen. Bleiben wir beim Beispiel Datenschutz-Grundverordnung. Da muss ich schon auch mit drauf eingehen und die muss ich auch schon in meiner ganzen Sache berücksichtigen.

René

00:14:55

Absolut. Ja, nur ganz kurz. Schön, dass du es gerade schon geteasert hast. NIST 2 wird so mal außer der Reihe zwischendurch kommen. Wir hatten ja vorher gesagt, ja, IT-Compliance, vielleicht bis Weihnachten. Wer weiß, wie lange. Wir werden zwischendurch nochmal ein neues Thema einschieben und das wird halt eben die NIST 2 sein. Aber wir können noch nicht sagen, ob es nächste oder übernächste Folge sein wird. Aber es wird kommen. Na super. Genau. Dann haben wir Compliance-Strategien. Du hast es gerade ja schon gesagt. Das wären halt so Sicherheitsmaßnahmen. Wie werden die implementiert? Wo ist der Best-Practice-Ansatz dabei? Das sind halt auch Sachen, die da einfach mit reinspielen in diese technische, also technologische Compliance. Und man einfach wirklich schaut, dass man das nach den besten, also eigentlich die besten Anwendungsmöglichkeiten dann für sich auch wirklich berücksichtigt, damit man eben auch das bestmögliche Ergebnis kriegt. Ich nehme mal ein ganz sinnfreies Beispiel. Hat jetzt damit nicht so ganz viel zu tun, aber ein Stück weit. Servereinrichtung. Also Windows Server hat auch ein Best-Practice. Wenn das nicht so umgesetzt wird, hat man nachher das Problem, dass selbst der Microsoft Support einfach nicht unterstützt, weil es wurde nicht nach Best-Practice eingerichtet. Sollte ein Unternehmen für sich auf jeden Fall immer berücksichtigen.

Michael

00:16:27

Ja und wenn wir beim Server bleiben, bei der Anschaffung der Server, der Server-Infrastruktur sollte man sich nach dem aktuellen Stand der Technik orientieren. Das ist glaube ich auch immer noch so ein Ding, dass man guckt, dass man nach dem aktuellen Stand der Technik kauft. Was übrigens nicht heißt, aktueller Stand der Technik heißt nicht, ich kaufe den letzten heißen Scheiß, sondern aktueller Stand der Technik ist immer das, was grundsolide bewährt ist. Da gibt es auch, ich glaube vom BSI-Invitepaper zu dem Thema. Also wie gesagt, Stand der Technik ist nicht das Neueste und das Hipste, sondern Stand der Technik ist das, was aktuell bewährt auf dem Markt ist und grundsolide läuft. Da muss man nicht immer dem Neuesten hinterherhetzen, sondern da ist das, was zuverlässig unterwegs ist, das Wichtige.

René

00:17:12

Ja und da muss man, also das muss, dann kommen wir genau in den anderen nächsten Bereich. Der nächste Bereich ist nämlich dann eben branchenspezifisch. Auch das, also da lässt sich das ja ganz ganz einfach dann letzten Endes mit übereinbringen, weil egal welche Software ich einsetze, egal welche Anwendung irgendwie in irgendeiner Form zum Einsatz kommt auf diesem Server, auf meiner Cloud- Struktur oder sonst wo. Es gibt auch da immer Mindestanforderungen und empfohlene Anforderungen und wenn wir das jetzt wirklich mit dem Best Practice dann, das ist ja eigentlich der Best Practice, wenn wir das berücksichtigen, sind wir auch auf der sicheren Seite. Das heißt, da muss man sich auch wirklich an den Empfehlungen vom Hersteller, von, meinetwegen auch aus der Branche selbst heraus orientieren, damit man eben da auch keine Gefahr läuft, dass es nicht läuft. Also das, daran orientieren wir uns auch. Dann, was man machen kann, ist immer noch ein bisschen nach oben gehen, aber nach unten sollte man dann eben nicht. Es gibt Gründe, warum diese Empfehlungen so ausgesprochen werden.

Michael

00:18:21

Genau und deswegen auch da ist es wichtig, dass wenn Software oder Sachen angeschafft werden sollen, dass eben die IT-Abteilung, der IT-Partner etc. pp. da mit im Boot ist und wird gefragt. Abgesehen davon, dass es immer sinnvoll ist, bei solchen Sachen den Datenschutzbeauftragten mal mit ins Boot zu holen und eben die datenschutzrechtliche Betrachtung von den Compliance und von den Richtlinien sich mal anzugucken und mal zu gucken, welcher Dienstleister ist es dann, Serverstandort, welche Daten werden verarbeitet etc. pp. Auftragsverarbeitung ja, nein, dass diese Themen sauber durch zu besprechen sind von der datenschutzrechtlichen Seite, ist natürlich bei so einer Anschaffung auch immer super gut, wenn die IT dabei ist und kann sehen, die Abteilung möchte jetzt diese Software oder die Entwicklungsabteilung möchte sich jetzt gerne dieses Software-System kaufen. Passt das denn auf unsere Server- Infrastruktur? Sind die Server dafür ausgelegt? Haben wir dafür Hardware-Ressourcen frei? Brauchen wir gegebenenfalls neue etc. pp. Auch da immer wieder bei Anschaffungen im Unternehmen, holt die Abteilungen mit ins Boot, die die Ahnung davon haben und die sich um den ganzen Kram so kümmern, dass es wirklich am Laufen bleibt.

René

00:19:35

Ja, also gerade bei der branchenspezifischen Geschichte, also was den Datenschutz angeht, super wichtig, da jemanden bei der Entscheidungsfindung schon mit reinzunehmen. Ich sage mal gerade Gesundheitswesen im öffentlichen Dienst und so weiter, das sind Dinge, die sollte man nicht einfach aus dem Bauch heraus entscheiden, weil die Software schön bunt ist, sondern das muss wirklich abgeklärt werden, weil das sind sehr, sehr spezielle Dinge und wenn da Daten an die falschen Stellen geraten, läuft man da wirklich Gefahr, ein Riesenproblem zu kriegen.

Michael

00:20:08

Meistens ist es ein bisschen umständlich, in die Diskussion reinzugehen. Bleibt mal beim Datenschützer, das ist so das Beispiel, was ich nehmen kann, weil der Datenschützer halt nicht guckt, ob irgendwelche rosa Einhörner Bling Bling in der Software machen, ja, durch die Gegend hüpfen, sondern da wird sich halt eben angeguckt, welchen Zweck hat die Software, stimmt die Vertragswerk, welche Daten werden transferiert, passt das alles an sich, ist es wirklich notwendig, Datenminimierung, was will das alles haben und da kommt schon manchmal zu Diskussionen, dass eben irgendeine Abteilung oder Marketing etwas haben will, was ein schönes, schön aussieht, aber halt eben hinten von dem Aufbau her datenschutzrechtlich nicht so richtig der Burner ist und da ist es halt einfach super, wenn man es im Vorfeld bespricht, bevor man das System eingekauft und implementiert. Ich glaube, wir hatten das schon mal in einer vorherigen Folge oder ein paar Folgen davor, dass wir darüber gesprochen haben und ja, das ist auch Einhaltung von Compliance, Sicherstellung von Compliance-Richtlinien und da gehören halt eben die Fachmänner mit an den Spot. Genauso wie bei dir, ich meine, das ist ja als Dealer genau das Gleiche, da wird sich irgendwas ausgesucht, was auf den Server drauf soll und da ist der Server nicht ausgelegt für, ja.

René

00:21:21

Genau, ja und da kommt der Dealer zum Einsatz und schaut dann, was möglich ist oder was eben geändert werden sollte, damit es möglich gemacht wird. Also Möglichkeiten gibt es ja immer, ist bei dir und bei uns so, aber man muss halt wirklich mal darüber sprechen. Es kann sein, dass man mal abweichen muss, andere Software, anderes System, anderes was weiß ich was, aber am Ende des Tages kann man so auf jeden Fall immer eine gute Lösung finden. Branchenspezifisch gibt es natürlich sehr viele unterschiedliche Branchen. Einmal gibt es das, wenn man sehr ins Detail geht, ich sage mal zum Beispiel Gesundheitswesen, Finanzwesen und so weiter. Man kann es aber auch noch mal von der anderen Seite sehen. NIST 2 ist da das Thema, hatten wir gerade kurz schon angeschnitten. Da ist es halt so, dass das bezieht sich ja nicht auf eine bestimmte Branche, aber dennoch irgendwie doch, weil da geht es ja um systemkritische Unternehmen und kann man als Branche auch so sehen. Ist natürlich jetzt nicht, dass wir da fest sagen, es ist jetzt nur das Gesundheitswesen, aber auch das gehört ja irgendwie zu Branchen spezifisch dazu.

Michael

00:22:32

Es gibt eine Übersicht der Branchen, die sich damit auseinandersetzen können im Anhang des NIST-Gesetzes.

René

00:22:39

Ja siehste, aber trotzdem da gehören ja gewisse Bereiche rein. Es sei denn du möchtest natürlich jetzt vollends was anderes sagen.

Michael

00:22:50

Nein, nein, nein. Das Pulver verschießen wir beim entsprechenden Podcast. Naja, das ist wirklich so, gerade wenn wir bei NIST 2 sind. Es sind halt einfach Branchen, die drunter fallen und es gibt Branchen, die einfach nicht drunter fallen. Deswegen ist das eine branchenspezifische Kiste. Ob man darüber betroffen ist oder nicht, muss man sich angucken. Es gibt inzwischen von BSA eine Betroffenheitsprüfung, das ist auch schon mal ein kleiner Teaser, wo man sich durchklicken kann. Am Ende vom Tag ist das aber auch keine rechtssichere Auskunft und keine Informationen. Man muss sich einfach mit dem Thema auseinandersetzen, beschäftigen, mal ein Fragen der Ahnung hat, der schon mehr implementiert, mehr umgesetzt hat, also klassischer externer Beraterfragen und dann einfach entsprechend reagieren. Das ist branchenspezifisch zum Thema NIST 2 zu sagen. Medizintechnik, du hast es eben schon angesprochen. Ich glaube, das ist ein ganz heikles Thema in der Medizintechnik. In der Medizintechnik sind immer auch mehr Computer unterwegs, immer mehr IT. Es gibt, glaube ich, ganz wenig Dinge, die noch nicht vernetzt sind, autark arbeiten, wo nicht irgendwo ein Rechner oder eine IT dahinter sitzt. Ich sage jetzt mal einfach, selbst in einem Rettungswagen hast du inzwischen einen Defi drin, der Defi hängt an einem Tablet dran. Die Telemetrie hätte ich fast gesagt, die Biometriedaten von dir, sprich einfach das EKG wird vom Defi ausgelesen, geht aber nicht schnell ans Tablet und wird über das Tablet ans Krankenhaus gefunkt, sodass die Buben in der Notaufnahme schon Bescheid wissen, wer kommt, was er hat und wie das letzte EKG aussah, bevor die Patientin schon in der Notaufnahme drin liegt. Auch das alles sind Technologien und technische Ansätze, wo es entsprechend branchenspezifische Regelungen gibt, wo man sich mit auseinandersetzen muss, um einfach compliant zu solchen Sachen zu sein. Da werfe ich einfach mal die MDR, die für die Medizinprodukte gekommen ist, mit in den Raum rein, die mit verschiedenen mitgeltenen Anforderungen ganz genau definiert, wie Medizinprodukte auf den Markt zu bringen sind und was Hersteller und auch Händler für Verantwortlichkeiten haben, um diese Produkte eben im Markt zu bringen und zu vertreiben.

René

00:24:58

Es ist immer wieder schön, was alles so durch Technik gemacht wird. Ich bin ITler jetzt seit 20 Jahren, aber es ist immer wieder schön, in welchen Bereichen eigentlich Technik sehr bereichernd auch ist. Das finde ich schon eine tolle Sache.

Michael

00:25:17

Da kann ich mich immer wieder neu für begeistern. Medizin ist jetzt mein zweites Baby, wo ich mich gerne mit kümmere und wo ich auch Herstellern helfe. Ich kann mich daran erinnern, wir haben vor 20 Jahren inzwischen die ersten DEFIs gehabt, die hatten so eine PCMCIA-Schnittstelle. Da musstest du vorne mit einem Kabel, hast du für jedes Handy speziell ein Kabel gehabt, dann hattest du hinten in der Tasche so ein Nokia, ich glaube Nokia 6110 oder was, das waren die Dinge, die gingen oder so ein Siemens S25, also das ist echt Opa erzählt vom Krieg. Und mit den Dingern konntest du dann die ersten EKGs per GSM schon mal ins Krankenhaus bringen, bevor der DEFI oder bevor der Patient damals im Krankenhaus war. Und vor zwei Wochen habe ich das Jahr 2024 mal wieder live erleben dürfen, wie es aktuell funktioniert. Die hängen halt einfach den DEFI an dich dran, schreiben das EKG mit der Kiste, die haben ein Pad, ein iPad, da tragen sie alle Daten rein, transferieren das einmal live rüber ins Krankenhaus, das Krankenhaus weiß genau, wer du bist, die haben alle Daten schon, du wirst nicht mehr gefragt, wie der heißt, mit Aufnahme etc. pp., sondern das läuft einfach durch und die sehen genau die erste Diagnose vom Arzt, die EKGs, die geschrieben worden sind, das läuft so sahnig inzwischen durch. Zumindest in dem Fall, den ich jetzt geerlebt habe, ja. Ja, Top-Geschichte, so soll es auch sein. Top-Geschichte, aber das sind halt auch alles Dinge, die Zulassungsverfahren und wieder einen Bogen rüber hier zu unseren Compliance-Kisten, das sind alles Dinge, die stark reglementiert sind und dass sie sicher funktionieren und mehr helfen wie schaden und das sind halt einfach Dinge, wo sich auch Krankenhäuser, Betreiber von Rettungsdiensten etc. dran hängen müssen, Hersteller, die Schnittstellen haben, das hängt halt alles an den Compliance dran und an den branchenspezifischen Anforderungen.

René

00:27:21

Ja, ist ein perfektes Beispiel genau dafür. Ja, dann was auf jeden Fall auch ein Punkt da ist, gehen wir mal weg von branchenspezifisch oder nicht komplett weg davon, aber schnelle, verändernde technologische Möglichkeiten. Also einmal natürlich Herausforderungen, die sich immer wieder neu auftun, Schwachstellen, keine Ahnung, die irgendwie behoben werden müssen, die sollte man auch irgendwie berücksichtigen, wie man darauf reagieren kann. Bedeutet, wenn ich mich jetzt heute für eine Technologie entscheiden sollte, dann muss diese auch so flexibel sein, dass ich daran was ändern kann, weil sich die Lage einfach verändert. Wenn ich mich da sehr, sehr festschreibe, habe ich nachher ein Problem, weil entweder ziehe ich dann meine ganze Infrastruktur auseinander und sie erfüllt nichts mehr von dem, was ich mir vorgenommen habe oder ich kann halt die Sicherheitslücken nicht schließen oder mich nicht auf verändernde Marktbedingungen einfach einstellen. Das sind einfach so ein paar Dinge, die man immer mit berücksichtigen sollte. Flexibilität ist in der IT, denke ich, sowieso schon ein Riesenthema immer, aber kommt damit nochmal in einen anderen...

Michael

00:28:39

In der QM-Welt sagt man immer, man solle so ein regelmäßiges Mal so ein Prozessreview, ein Dokumentenreview machen, ob das, was da noch drinsteht, noch alles aktuell ist und ich glaube, genau das ist so ein super wichtiges Thema bei der IT, weil es echt so super schnelllebig ist. Auch, gehen wir rüber, IT-Notfallpläne etc., PP, das sind alle so Dinge und auch so Compliance, welche Software, was möchte ich, wie will ich das Unternehmen definieren. Das sind alle so Dinge, das sollte ich mir spätestens einmal im Jahr angeschaut haben und sollte mal einen Blick drüber riskieren, um zu gucken, passt das noch zu meinem Unternehmen, muss ich was anpassen, habe ich irgendwann mal irgendwas spezifiziert, was es inzwischen vielleicht gar nicht mehr gibt, weil die Technik weiter ist. Wir setzen nur Coax-Netzwerkkabel ein, für die, die sich daran erinnern. Du lachst schon und du weißt, was ich meine. Deswegen sage ich, man sollte diese Compliance regelmäßig tracken, ob sie noch wirklich das erfüllen, was sie tun sollen und noch einen Nutzen haben oder ob es inzwischen einfach ein toter Papiertiger ist, der keinem mehr weiterhilft.

René

00:29:46

Ja, genau. Es ist ja genauso, du sagst ja gerade, man sollte immer wieder reingucken, ob das noch passend ist oder ob man irgendwie was ändern muss. Es ist ja genauso, wenn ich jetzt irgendwie was Neues einführe, du hast das vorhin gesagt, KI. Wenn ich das einführe, muss ich das natürlich auch irgendwie in die Compliance wieder mit einfließen lassen. Also dann kommt man ja sowieso wieder in neue Versionen, sollte das genauso dort einbetten und sollte dann auch wieder alles, was ich vorher hatte, damit in Einklang bringen, wenn da Änderungen notwendig sind und entsprechend aktualisieren.

Michael

00:30:26

Genau, das funktioniert aber auch dann nur richtig schön, wenn ich mir vorher auch darüber Gedanken mache, welches LLM setze ich ein im Unternehmen, was für einen Zweck habe ich damit, welche Daten will ich damit bearbeiten. Also, wenn ich mir einmal richtig Gedanken mache, was ich will, dann kann ich es auch vernünftig beschreiben und dann kann ich es auch in das bestehende System rein implementieren. Wenn ich jetzt einfach nur schreibe, ab sofort darf jeder Copilot benutzen, dann habe ich es noch nicht wirklich richtig definiert und habe es noch nicht wirklich so im Unternehmen drinnen, dass ich auch weiß, was ich damit tue, den Mitarbeitern Richtlinien und Rahmenbedingungen an die Hand gebe, sondern ich muss schon beschreiben, was damit gemacht wird oder wie ich es benutzen soll. Dürfen personenbezogene Daten rein? Unternehmensdaten, dürfen die damit gefüttert werden? Oder nutze ich ein pseudonymisiertes Unternehmen, was ich mir anlege, wo ich sage an die Mitarbeiter, wenn sie damit arbeiten, sollen sie bitte mit dem pseudonymisierten Unternehmen arbeiten. Ganz heise Nummer ist, geschäftsgeheimenes Entwicklungsdaten. Darf ich einen Geschäftsbericht in Cecipedi hochladen und sagen, fass mir das mal bitte zusammen? Nein, wahrscheinlich nicht. Also das sind so Dinge. Aber da sind wir wieder am Anfang von der ganzen Nummer. Murphys Law kommt und jeder wird sich das überlegen und das genau damit machen, wo du am Anfang entweder nicht dran denkst oder denkst, ach nee, passiert eh nicht. Es wird passieren und deswegen musst du Richtlinien und Sachen an die Hand geben, dass du einfach für dich definierst, was will ich mit so einem System. Wir machen mal eine Folge zur KI-Verordnung beziehungsweise zum AI-Act. Ich glaube, das ist ein ganz gutes Ding. Da schieben wir das ja auch noch dazwischen. Was will ich mit dem Ding bezwecken? Was soll es erfüllen und was darf eben nicht damit passieren? Und wenn ich das einmal sauber definiert habe, dann kann ich es rein implementieren. Und dann macht es auch Sinn. Mit Begründung.

René

00:32:27

Dazu gehört ja auch, nehmen wir mal an, wir haben jetzt bisher immer so, das ist ein Unternehmen, was einfach so besteht, wie es ist. Also es expandiert nicht, es hat keine weiteren Standorte, die es sich einverleibt. Sollte es aber doch so sein. Ich habe jetzt ein großes Unternehmenkonzern, der sich jetzt immer wieder neue Standorte dazu holt. Dann muss es auch da Vorgaben, Richtlinien geben, die eben genau dafür da sind, den Umgang mit der neuen IT, mit der neuen Umgebung auch zu regeln. Das heißt, auch die Komplexität mit Netzwerken und so, das muss alles dort dargestellt werden. Welche Standards haben wir und wie münzen wir diese dann auf jeden anderen neuen Standort dann auch um?

Michael

00:33:16

Aber auch nur dann, provokante These, auch nur dann, wenn es in den Compliance-Richtlinien festgelegt ist. Wenn in den Compliance-Richtlinien irgendwo steht, dass die IT-Infrastruktur, die wir aufgebaut haben in unserem Unternehmen, in alle weiteren Unternehmen gespiegelt wird, inklusive Hardware etc. pp, damit wir eine sehr homogene Infrastruktur haben, ist das auch ein gangbarer Weg. Dann wird halt eben der Server und die Firewall in der ganzen Schmutz rausgeworfen und dann kommt halt das rein, was wir Stammsitz haben oder beziehungsweise in den anderen Unternehmenszweigen schon drin haben, wenn die auf Sofas stehen oder auf whatever was, dann kommt halt die Struktur da rein. Das kann auch ein gangbarer Weg sein, aber es muss halt irgendwie beschrieben werden. Es kann nicht sein, dass ich ein Unternehmen bei mir aufnehme, kaufe etc. übernehme, was auch immer und der ITler steht dann da und sagt, ja, wir haben jetzt ganz was anderes. Das kenne ich gar nicht, da weiß ich überhaupt nicht, wie ich damit umgehen soll. Wo wollen wir denn hin jetzt mit dem Unternehmen? Und dann muss klar sein, wie mal festgelegt wurde, wie die Reise hingeht. Alles raus oder assimilieren.

René

00:34:21

Ja, es ist vor allem auch wichtig, dass man bestimmte Systeme nutzt, weil da, da haben wir ja auch schon oft drüber gesprochen, aber weil da einfach die Expertise liegt. Man kann nicht erwarten, dass ein ITler, der das eine System top betreuen kann, dass er das bei dem anderen genauso kann. Das ist aber auch bei dem ganzen Team so. Das spezialisiert sich ja irgendwann auf meine Umgebung, die ich halt an meinem Hauptstandort oder für den ganzen Konzern habe. Das heißt, es muss irgendwo harmonisiert werden. Oder man würde jetzt sagen, okay, wir betreuen das Netzwerk nicht selbst, wir geben die Richtlinien vor und es wird dann durch einen Extern zum Beispiel gemacht, der uns aber Rechenschaft ablegt, dass das Ganze so umgesetzt wird. Und da kommen wir zum nächsten Punkt, die gewissen Erfolgsfaktoren, die man ja dahinter hat. Meine Compliance müssen mich ja nach vorne bringen. Das heißt, in irgendeiner Form muss das Ganze auch messbar sein. Nicht in jedem Bereich, aber in einigen sollte es doch so sein. Das heißt, wenn ich uns zum Beispiel mit einem, nehmen wir an, ich habe jetzt ein kleines Unternehmen, das bisher auf gar keine Maßnahmen geachtet hat. Wir haben IT, die läuft, wir können damit arbeiten, das war es, mehr wollen wir gar nicht. Und das nimmt sich irgendwann vor, okay, jetzt erstellen wir aber Compliance-Richtlinien und wollen damit unsere Sicherheit stärken. Dann muss ich irgendwelche Faktoren haben, die nachher aussagekräftig sind, die mir dann belegen, ja, mit unseren Maßnahmen haben wir genau das geschafft. Das heißt zum Beispiel ein Sicherheitsaudit. Ich würde permanent irgendwie prüfen, wie viele Angriffe wurden gefahren und welche Auswirkungen hatte das bisher oder keine Ahnung, was ist bisher dadurch passiert. Und dann habe ich meine Richtlinien da angepasst, habe sie dann auch die Maßnahmen entsprechend umgesetzt und kann jetzt belegen, okay, dadurch haben wir weniger Angriffe beziehungsweise wir blocken meinetwegen durch automatisierte Systeme und dadurch ist die Performance bei uns im Netzwerk höher, weil eben die Auslastung von extern gar nicht da ist. Es können ganz viele verschiedene Faktoren sein.

Michael

00:36:36

Ja, es muss halt am Ende muss es messbar sein. Ich hätte jetzt, wie du das gerade so erklärt hast und du von so einem kleinen Unternehmen gesprochen hast, was einfach nur vernünftig arbeiten will, was mit IT keine Probleme hat, was sollte das für Druck haben, Compliance einzuführen, wenn alles funktioniert? Das heißt, an irgendeiner Stelle muss ja entweder ein Bauchkrummeln sein oder es muss schon mal was passiert sein, dass der Trigger kommt, sich jetzt mit Compliance und Richtlinien oder mit einer ISO oder mit whatever was einen besseren oder einen höheren Schutzmechanismus aufzubauen.

René

00:37:07

Neue Geschäftsführung.

Michael

00:37:08

Neue Geschäftsführung.

René

00:37:10

Auch das kann. Das ist nur so ein Beispiel. Es ist ja die Frage, wo jemand seinen Fokus hat. Es gibt da welche, die sagen, okay, das ist für mich jetzt ausschlaggebend. Es gibt aber auch welche, die sagen, das ist es nicht. Da hast du absolut recht. Die, die es nicht haben, die haben dann natürlich irgendwas erlebt.

Michael

00:37:26

Genau, dann hast du aber, wenn die, nennen wir es, es hört sich schön an, die haben was erlebt. Wenn die was erlebt haben, dann wissen die ja schon ganz genau, was sie in Zukunft nicht mehr erleben wollen und können sich daraus schon mal so die ersten messbaren Ergebnisse ziehen, beziehungsweise so die ersten Tendenzen ziehen, bringt das, was ich gemacht habe, den Effekt, dass ich das Erlebnis nicht mehr habe oder habe ich was getan und ich hatte das Erlebnis erneut und damit kannst du ja schon, das ist ein ganz grober Indikator, das ist auch wirklich der erste Einstieg, aber wenn du wirklich mit so Sachen anfängst und in so Sachen einsteigst, ist das, glaube ich, auch schon mal so ein Anfang, womit man guckt. Das heißt, ich möchte keine Compliance, also ich möchte keine IT-Sicherheitsvorfälle haben. Ich möchte nicht mehr von einem Drojaner befallen werden. Ich möchte keinen Datenschutzvorfall. Ich möchte nicht, dass Mitarbeiter USB-Sticks klauen und Firmendaten entwenden und die Konkurrenz auf einmal alles sieht. Also alle solche Dinge, die ja durchaus erlebbar sein können. Das möchte man nicht mehr? Nein. Dass jemand USB-Sticks klaut? Dummes Beispiel, Running Gag. Nein, alles gut. Du weißt, was ich meine. Am Ende geht es um Diebstahl von Informationen. Und das sind Dinge, die ich messbar machen kann.

René

00:38:47

Genau. Und zur Unterstützung gibt es dann auch noch die Möglichkeit zur Automatisierung oder eben andere Möglichkeiten zur Unterstützung dieser Compliance. Nehmen wir mal an, wir hätten jetzt, es gibt ja Systeme, die können Kennwörter auslesen, Schadsoftware. Die können wirklich meine Kennwörter von meinem System auslesen und können die dann irgendwohin speichern. Genauso gibt es aber auch Systeme, die dafür ausgelegt sind, eben zum einen diese Passwörter zu schützen, natürlich. Aber es gibt auch die Möglichkeit, zum Beispiel zu sagen, ich habe gar keine Möglichkeit, ein Kennwort zu setzen, was kürzer als meine Compliance ist. 16 Zeichen, wie auch immer. Das sind ja auch so Möglichkeiten. Ich hatte es ja schon mal gesagt, wenn man es ganz niederschwellig machen will, Passwortmanager, der einfach sagt, okay, du kannst hier keine Kennwörter speichern im Manager, die kürzer als 16 Zeichen sind. Das ist natürlich keine Automatisierung, keine vollständige Behebung des Problems. Aber will der Mitarbeiter die Mitarbeiterin eben den Passwortmanager nutzen, muss diese Person auch entsprechende Kennwörter anlegen. Anders geht es einfach nicht. Das sind so niederschwellige Dinge.

Michael

00:40:01

Du bist, wir drehen uns immer wieder, du bist schon wieder klassisch bei den technischen organisatorischen Maßnahmen, die Unternehmen treffen, um IT-Sicherheit sicherzustellen. Gehört hier aber auch dazu. Gehört auch dazu. Und auch das nochmal zu vervollständigen. Bevorzugt werden die technischen. Und wenn ich es technisch nicht machen kann, mache ich mir organisatorische Gedanken. Und das sind genau die Dinge. Und die Überwachung von dem ganzen Kram, auch das, ich glaube, da wolltest du auch hin. Für mich ist es immer zweigeteilt. Für mich ist es einmal, oder dreigeteilt zum Beispiel. Du hast irgendwelche Zahlen oder irgendwelche Indikatoren, woran du guckst, dass dein System leistungsfähig, wirksam etc. pp ist. Das heißt, vorher hatte ich Erlebnisse, jetzt habe ich keine mehr, so hätte ich es gerne. So ein Audit, einmal im Jahr, wenn ein Datenschützer kommt oder wenn irgendein Beratungsunternehmen kommt oder ein QMler, ein whatever, Technikaffiner kommt, der mal sich diese Sachen anguckt, die Compliance-Richtlinien als neutrale Personen überprüft, mal einen Blick riskiert und sagt, ey, passt mal auf, geht sich auf, geht sich nicht auf. Da seid ihr nicht mehr so im Prozess, wie ihr es da mal beschrieben habt. Also formal gesagt, mal ein Audit, mal eine Kontrolle, passt das, was ich mir gesagt habe. Und ich glaube, der dritte Zweig ist heutzutage auch super wichtig, das sind Systeme, die sich automatisch überwachen bzw. irgendwelche Sicherheitsmechanismen, die im Hintergrund laufen, regelmäßige Systemchecks machen, die einen Audit-Trail fahren, ey, dein System ist in Ordnung, wir haben jetzt die Angriffe abgewehrt, ich habe da wieder was gemacht. Ich glaube, da kannst du als ITler wesentlich mehr zu sagen, aber ich finde, dass so was, was automatisiert mal reinguckt in die Systeme und Gesundheits- und Health-Check liefert, inzwischen auch super wichtig ist.

René

00:41:44

Ja, also ich sage mal, gerade so ein Pen-Test, also Penetrationstest, das halt irgendwie, ja, ist es kostspielig in den allermeisten Fällen, das stimmt und das hat auch Auswirkungen auf mein Netzwerk in dem Augenblick, aber das liefert einen Blick auf ein Netzwerk, den man sonst so niemals hätte, weil da wird ja wirklich jede Schwachstelle auf Möglichkeit angegriffen, angegriffen in dem Sinne, da passiert natürlich gar nichts, aber am Ende des Tages wird halt getestet, welche Möglichkeiten ein Externer hätte, um in meine Systeme einzudringen oder eben Schwachstellen generell aufzutun und das sind halt so Dinge, die können einen super unterstützen. Und nehmen wir mal jetzt was ganz anderes, keinen Pen-Test, nehmen wir mal Schulung und Sensibilisierung von Mitarbeitern, geht ja auch in diese Richtung, also eine Awareness, das ist auch etwas. Also umso besser ich meine Mitarbeiter auch aufstelle, umso besser habe ich da auch wieder meinen Schutzfaktor aufgebaut. Es sind ganz viele Dinge, die da einfach miteinander zusammenspielen und ganz sicher auch, ja, das ist jetzt keine Automatisierung in dem Sinne, aber das ist halt etwas, das unterstützt halt mein Gesamt im Unternehmen, also was meine Sicherheit oder Sonstiges angeht. Und Automatisierung kann man natürlich in ganz vielen Dingen trotzdem nutzen. Ich sage mal so, bestes Beispiel ist ein Auto-Healing. Es gibt Systeme, zum Beispiel ein Security Audit, was halt auf den Rechnern prüft, ob die Software aktuell ist. Gibt es Versionsstände, die Sicherheitslücken haben oder sonst irgendwas. Und es gibt nun mal Software, da gibt es ganz ganz viele, die sagen, ich habe ja mein Auto-Updater und was weiß ich was. Ja, ganz so funktioniert es aber nicht, weil nicht jede Software automatisch geupdatet werden kann und vor allem auch nicht sollte in der Regel. Also klar, Windows Parts und so, da will ich gar nichts sagen, aber es gibt halt gewisse Bereiche, was weiß ich, ob das ein ILS ist von Microsoft oder ob das ein SQL Server und so weiter ist. Also da gibt es durchaus Dinge, die man nicht einfach updaten sollte, weil vielleicht der Versionsstand nicht mehr zu meiner Anwendung passt. Und da gibt es halt eben Software oder Lösungen für, die eben genau das prüfen. Die gucken sich an, okay, sind diese Systeme up-to-date. Wenn nicht, passen sie einigermaßen, also passt das noch zusammen, die beiden Systeme. Und beim Auto-Healing könnte ich zum Beispiel sagen, okay, installieren wir keine Major-Updates, also keine Versionssprünge, sondern eben nur Sicherheits- Microsoft, also nicht Microsoft-Anwendungen, also Drittanbieter. So, das sind ja durchaus Systeme, die es gibt und die sowas eben automatisiert anbieten. Also das heißt, ich habe eine vollständige Automatisierung auf, eben auch solche Sicherheitslücken, Sicherheitsdinge halt.

Michael

00:44:53

Und genau das soll in einer Compliance-Richtlinie festgehalten. Compliance-Richtlinie zum Thema Update. Update und Aktualisierung, wann immer ich sie nenne. Wir führen an folgenden Systemen, sind auf Auto-Update eingestellt, folgende Systeme sind auf nur meiner Updates eingestellt, also auf Bug-Fixes eingestellt. Wir wollen keine Major-Updates fahren bei folgenden Systemen. Händisch am Samstag um 21 Uhr ist unsere Update-Zeit, da wird der Server runtergefahren. Also alle solche Dinge muss man mal irgendwo klar beschreiben und dann hat man es auch klar, damit auch, wir sind wieder bei dem neuen IT-Ler, der reinkommt, wir sind bei vielleicht der IT-Ler mal krank, es muss irgendein externer Unternehmen etc. pp. Wo steht es denn? Heute ist Donnerstag, was ist denn heute Phase? Ja, heute ist Update-Tag, das neue macOS ist rausgekommen. Wer kriegt es denn? Wie lange warten wir denn? Welches Punkt-Release kommt denn? Oder hier das Herbst-Update von Windows, wie gehen wir damit um? Und das sind halt Dinge, die man festlegen muss.

René

00:45:54

Ja, wichtig ist dabei auch, und du hast es gerade gesagt, ein externer, falls der mal zum Zug kommen sollte oder wenn man mit einem externen Unternehmen komplett zusammenarbeitet, diese Compliance sollten an beiden Stellen liegen. Auch die externen müssen ganz klar sich an diese Regeln halten. Das heißt, die müssen auch diese Richtlinien des Unternehmens vorliegen haben, damit die sich daran orientieren können und müssen.

Michael

00:46:17

Ganz klar, also ja, falls das nicht klar rübergekommen ist, ja, jeder, der an der IT oder jeder, der im Unternehmen arbeitet, speziell die in IT im Unternehmen arbeiten, sollten Kenntnis über die Richtlinien haben, egal ob es interne oder externe sind. Die sollten auf diese Richtlinie geschult werden, auf die Einhaltung dieser Richtlinie verpflichtet etc. pp. Irgendwas muss getan werden, aber die müssen die Kiste kennen. Es macht keinen Sinn, sich im stilleren Kämmerchen für sich in der IT was zu überlegen und der externe Dienstleister, mit dem man zusammenarbeitet, den lässt man einfach außen vor und er kriegt die Infos nicht. Macht keinen Sinn.

René

00:46:53

Okay, dann würde ich sagen, gehen wir nochmal kurz auf, ja, Möglichkeiten für zukünftige, also wenn man sich jetzt, wenn man jetzt anfängt eine IT Compliance aufzubauen oder man hat jetzt eine, die man überarbeiten möchte, gibt es ja bestimmte Dinge, die man einfach berücksichtigen sollte, um sich halt für die Zukunft zu wappnen. Ich habe es vorhin ja schon gesagt, Flexibilität, Agilität, das sind halt Dinge, die man auf jeden Fall berücksichtigen muss. Also in so einer Compliance sollte nicht drinstehen, wir nutzen in Zukunft, oder wir nutzen immer Windows Server 2012, weil irgendwann ist er alt. Ist der in dem Fall jetzt schon, aber das sind so Sachen, das sollte da so nicht drinstehen, sondern dann einfach, wir nutzen Windows Server in der aktuellsten Variante oder wie auch immer in den noch unterstützten Varianten.

Michael

00:47:44

Genau, aber das sind Dinge, die festgelegt werden müssen. Ich würde das zum Beispiel regeln über, wir nutzen die Windows Version wie in unserer Windows- oder Softwareübersicht angegeben. Ich würde also eine zentrale Stelle haben, wo ich alle Softwaresysteme aufliste und da würde ich mir schon die Freiheit nehmen, entweder habe ich meinen Windows Server, der noch unterstützt wird, der noch läuft, da sind wir wieder bei Best Practice und bei aktuellen Stand der Technik. Wenn morgen ein neuer Windows Server rauskommt, würde ich nicht sofort darauf zuspringen. Deswegen noch unterstützte Systeme. Musst du dich in den Compliance irgendwie schon so festlegen, dass du sagst, wir setzen jetzt diese Serverversion ein und wenn du auf eine andere Serverversion springst, musst du halt eben an der Stelle, das Gemance Normative, musst du halt an der Assetübersicht deinen Assetbetriebssystem Windows Server eben entsprechend anpassen. Aber ja, du hast, ich bin bei dir, du solltest diese Richtlinien schon so schreiben, dass du dich nicht so extrem festnagelst und so extrem einengst, dass gar nichts mehr geht und der Laden still steht.

René

00:48:48

Zumal würdest du ja jedes Mal bei jeder kleinen Änderung und ich sehe jetzt mal das Serverbetriebssystem als kleine Änderung, weil das halt wirklich die Basis ist. Alles, was tiefgreifender ist, kommt ja danach. Man sollte halt nicht bei jeder kleinen Änderung dann wirklich nachher die komplette Compliance neu aufbauen müssen.

Michael

00:49:10

Nein, aber anpassen.

René

00:49:12

Kann man machen, ist die Frage. Ja, aber muss man das tatsächlich immer?

Michael

00:49:17

Genau, muss man das. Aber was mich jetzt interessiert, deswegen gerät ich gerade so rein, ist für dich ein Windows Server Update, also ein richtiger Versionssprung, ein kleines Update? Also ich kenne das, wenn Unternehmen sagen... Es ist kein Windows Update, das stimmt. Wenn wir jetzt Windows Server umstellen von 2012 auf was weiß ich oder irgend so ein Kram, da ist schon ein bisschen Party im Unternehmen, weil sie sagen, das machen wir nicht jeden Tag.

René

00:49:47

Also gut, auch da IT-Dienstleister...

Michael

00:49:51

Ja, die sehen es anders, da haben wir einen Unterschied.

René

00:49:55

Das ist halt täglich Arbeit, muss man fairerweise dazu sagen. Das soll aber nicht heißen, dass es jetzt absolutes Kleinkram ist. Das hängt ja immer mit den Anwendungen oder steht und fällt mit den Anwendungen, die drauf sind. Aber am Ende des Tages eine Migration auf ein neues Betriebssystem und ein komplettes Anheben der Domänebene und so, das sind halt... Ja, macht man halt. Wenn man alles außenrum klar hat, dann ist das eigentlich nicht mehr ganz so wild. Aber wie gesagt, das ist halt immer die Frage, aus welcher Perspektive. Wenn mich jetzt jemand aus der internen IT anrufen würde, der hat da irgendwie in seinem SAP, um jetzt mal eine Software zu nennen, tiefgreifende Probleme, dann bin ich natürlich auch im ersten Moment am Schwimmen, weil der ist jeden Tag damit beschäftigt, vielleicht auch genau dafür da. Und ich soll jetzt aus dem Stehgreif sagen, so ist es andersrum halt genauso.

Michael

00:50:49

Erinnert mich gerade an die Situation vor zwei oder drei Jahren, wie wir zusammen meine Domain umgestellt haben und haben den Hauptdomain auf den Hosted Exchange von Microsoft 365 gehoben. Und ich da gesessen habe und dreimal zu dir gesagt habe, soll ich den Knopf jetzt wirklich drücken? Müssen wir das jetzt wirklich machen? Und du gesagt hast, ey, komm, drück den Knopf, das mache ich jeden Tag fertig. Und da ist das halt, das ist halt genau Innenansicht, Außenansicht, das ist halt das Coole, wenn du einen an der Hand hast. Für mich wäre so ein Systemupdate, aber ich würde das gar nicht anpacken und für mich wäre es echt ein Event, nenne ich es jetzt mal so. Und du nudelst das eben aus den Armen raus, weil es eben Tagesgeschäft ist und du routiniert genug bist oder ihr routiniert genug seid. Genau. Okay, war nur so die Zwischenfrage für mich. Jetzt weiß ich, warum du ein kleines Update gesagt hast.

René

00:51:35

Ja, es ist kein normales Windows Update. Es ist schon etwas größer als das. Das muss ich dann auch sagen. Okay, gut. Genau. Also da kurz zusammengefasst, man sollte halt auf jeden Fall gucken, dass Compliance so ausgeredigt sind, dass sie wirklich in Zukunft auch noch greifen können und dass wir dann nicht jedes Mal eine komplett neue Compliance von Grund auf neu aufbauen müssen. So, ich glaube, Michael, wir kommen so ziemlich am Ende an. Deswegen würde ich jetzt gerne nochmal einmal kurz zusammenfassend sagen, die branchenspezifischen Compliance sind natürlich etwas tiefgreifender, was die Vorgaben angeht, die man da berücksichtigt. Also ob es jetzt irgendwelche Standards aus der Branche sind oder eben auch Vorgaben oder auch Zertifizierungen, die zu Rate ziehen. Es ist natürlich auf jeden Fall spezifisch auf meine Branche zu sehen, aber vom Grundaufbau ist es immer noch das Gleiche. Also ich sollte immer schauen, dass das Ganze auch immer noch mein Unternehmen widerspiegelt und das halt eben entsprechend mit dem rechtlichen Teil übereinbringt. Genau.

Michael

00:52:48

Ich habe gerade überlegt, ich glaube, ich würde es in so drei Level aufbauen. Du hast ganz übergeordnet, hast du die gesetzlichen Anforderungen, werfen wir mal DSGVO und S2 in den Raum rein. Dann hast du deine betrieblichen Anforderungen. Also erstmal musst du deine gesetzlichen Anforderungen kennen, musst dir darüber Gedanken machen, die stehen oben drüber. Dann hast du so deine betrieblichen Anforderungen, die du hast, das ist das zweite Teil. So hätte ich es gerne in meinem Unternehmen, so haben wir es beschlossen, so tun wir es. Und dann kommt als drittes, wenn du dich in irgendeiner Norm unterwirfst, also wenn du in die 27001 gehst, wenn du TSACs machst, wenn du VDS 10.000 machst, whatever machst, das ist so der dritte Bereich, wo du lesen musst, wie du deine Compliance zu gestalten hast und wie du dich zu verhalten hast. Ich glaube, diese drei Säulen hast du und über die musst du dich auskennen, den musst du spielen können und das Wichtigste ist die gesetzliche, dass du einfach weißt, in welchem gesetzlichen Rahmen bewege ich mich. Bin ich kritische Infrastruktur? Ja, nein. Bin ich Hersteller von Medizinprodukten? Habe ich irgendeine Software, die irgendein freaky KI-Tool kann? Bin ich Hersteller von Softwaresystemen? Also all diesen ganzen Kram, du musst wissen, in welchem Umfeld du dich bewegst, um zusammenzupassen. Dann, was heißt, will ich in meinem Unternehmen haben, um das sicherzustellen? Und als drittes ist normative Anforderungen, wenn ich die denn gerne hätte.

Feedback geben

Dir gefällt der Podcast und Du möchtest das mal loswerden? Du hast Tipps für neue Themen oder magst über den Inhalt bestimmter Folgen diskutieren? Dann wähle im Formular die jeweilige Episode aus und schreib uns eine Nachricht. Vielen Dank für Dein Feedback!

★★★★★

Gefällt Dir die Show?
Bewerte sie jetzt auf Apple Podcasts

2026 - René Geppert & Michael Kornmann

Hosted by LetsCast.fm
Deinen eigenen Podcast erstellen