Anfang 2020 wurde die IT der Stadtverwaltung Potsdam durch einen Cyberangriff über eine Citrix-Schwachstelle lahm gelegt und im Dezember 2022 gab es zumindest wieder einen Sicherheitsalarm. Der andere "Cybervorfall" betraf die IT des Landkreises Anhalt-Bitterfeld, wo 2021 eine Ransomware zuschlug. Danach war die IT des Landkreises für Monate offline und der Landrat musste die "IT-Notstand" erklären. Zu beiden Fällen sind mir die Tage "Nachlesen" untergekommen, die ich kurz im Blog für interessierte Leser und Leserinnen vorstellen bzw. anreißen möchte.
Anzeige
Cyberangriffe auf die Stadt Potsdam
Im Januar 2020 hatte ich über die sogenannte Shitrix-Schwachstelle in den Citrix Netscaler ADCs berichtet, über die eine Reihe Firmen angegriffen wurden.
Zum Hintergrund: Im Citrix ADC (Application Delivery Controller, früher Netscaler) wurde am 17. Dezember 2019 die Schwachstelle CVE-2019-19781 bekannt, für die es keinen Patch gab. Ich hatte zeitnah am 24. Dezember im Beitrag Schwachstelle in Citrix Produkten gefährdet Firmen-Netzwerke darüber berichtet. Von Citrix wurde ein Workaround veröffentlicht, mit dem Administratoren ihre Citrix-Appliances gegen die Ausnutzung der Schwachstelle abdichten mussten.
Das Shitrix-Desaster
Da das alles kurz vor Weihnachten passierte, haben viele Administratoren das wohl nicht mehr mitbekommen. Hier im Blog hatte ich das in einem Sicherheits-Sammelbeitrag Sicherheitsinformationen (3.1.2020) direkt zum Start des neuen Jahres nochmals hochgeholt. Als in der 2. Januar-Woche des Jahres 2020 Proof of Concept (PoC) Exploits vorlagen, um die Schwachstelle auszunutzen – und Honeypots bereits angegriffen wurden – war es für einige Leute bereits zu spät. Ich hatte zwar erneut vor der Schwachstelle gewarnt (siehe Exploit für Citrix ADC/Netscaler-Schwachstelle CVE-2019-19781). Aber mir waren Hinweise untergekommen, dass bereits Systeme durch ungepatchte Netscaler ADCs kompromittiert worden waren. Mitte Januar wurden allein in Deutschland über 2.000 weiterhin angreifbare Netscaler ADCs, erreichbar per Internet, betrieben.
Die Stadtverwaltung Potsdam erwischte es Anfang Januar 2020, als Unbekannte in das Netzwerk und die IT eindringen konnte. Nach den mir vorliegenden Informationen erfolgte der Angriff über ungepatchte Citrix-Schwachstellen (ich hatte die Informationen im Blog-Beitrag Potsdam offline–Ungereimtheiten erzwingen Server-Shutdown nachgetragen und auch im Beitrag Cyberangriffe: Gedia & Potsdam Opfer des Shitrix-Desasters (Citrix Netscaler-Bug)? erwähnt). Im Dezember 2022 gab es dann erneut einen Vorfall, bei dem die IT der Stadtverwaltung Potsdam offline ging (siehe Linkliste am Artikelende).
Aufarbeitung: Interna dieses Vorfalls
Durch Zufall bin ich auf diesen Beitrag der Kollegen von Golem gestoßen, der den Umstand, dass die Stadt Potsdam zwei Mal den IT-Notstand ausrufen und alles vom Internet trennen musste, aufgreift. Geschildert wird der Sachverhalt aus Sicht von Thomas Morgenstern-Jehia, der am 22. Januar 2022 den 100. Arbeitstag als Fachbereichsleiter E-Government bei der Landeshauptstadt Potsdam hatte.
Anzeige
Morgenstern-Jehia ist studierter Bauingenieur, der nach der sogenannten Wende eher zufällig zur EDV kam und sein Wissen selbst und über Weiterbildungen erwarb. Eigentlich war er zertifizierter SAP-Berater. Im Jahr 2019 wechselte er dann zur Stadt Potsdam in die Position des Fachbereichsleiters mit Verantwortung für die IT.
Der Golem-Beitrag skizziert die Situation in der IT der Stadt Potsdam nach dem Cybervorfall im Januar 2022, in der der Fachbereichsleiter mit einer unterbesetzten IT die Probleme lösen und Behelfslösungen finden musste. Zahlungsinformationen wurden per "schnell gekauftem" USB-Stick zur örtlichen Sparkasse transportiert, um die Überweisungen tätigen zu können. Beim Vorfall im Dezember 2022 kam es dagegen auf Grund einer Warnung der Geheimdienste zur vorsorglichen Abschaltung der IT. Bei etwas Zeit ist die kursorische Auflistung der Entwicklung ganz lesenswert, auch wenn keine technischen Details zu den ausgenutzten Schwachstellen genannt werden.
Cyberangriff auf Anhalt-Bitterfeld
Der zweite Cybervorfall, der im Nachgang aufbereitet wurde, gilt dem Landkreis Anhalt-Bitterfeld, dessen Landkreisverwaltung 2021 Opfer eines Ransomware-Angriffs wurde. Vermutet wurde ursprünglich ein Angriff über PrintNightmare, was aber wohl wieder verworfen wurde). Die IT-Systeme des Landratsamts Anhalt-Bitterfeld wurden am 6. Juli 2021 durch den Ransomware-Angriff außer Gefecht gesetzt. Ein Trojaner hatte alle Speichermedien verschlüsselt, so dass die Systeme nicht mehr arbeitsfähig waren. Ich hatte im Blog-Beitrag Ransomware bei Landkreisverwaltung von Anhalt-Bitterfeld berichtet.
Die Verwaltung des Landkreises war über viele Monate wegen fehlender IT und Daten nicht mehr arbeitsfähig. Ich hatte im Beitrag Notstand nach Ransomware bei Landkreisverwaltung von Anhalt-Bitterfeld darauf hingewiesen, dass der Landrat den Notstand erklärte, auch, um Unterstützung von außerhalb zu erhalten.
Kürzlich wurde ich von Mitarbeitern des MDR kontaktiert, weil in der Redaktion der Cybervorfall von Anhalt-Bitterfeld im Nachgang als Podcast aufbereitet wird. Marcel Roth (Podcast „Digital Leben", Lehrbeauftragter Heinrich-Heine-Universität Düsseldorf) schlüsselt den Fall des Landkreises, der mit der Nachricht "You are fucked. Do not touch anything" auf den Systemen begann, in einem Podcast auf.
Hacker, die 500.000 Dollar vom Opfer erpressen wollten und deren Spuren nach Russland führten, haben mit diesem Cyberangriff einen ganzen Landkreis lahmgelegt. Der Podcast versucht nachzuzeichnen, wie kopf- und ahnungslos die Verwaltung versucht hat, das Problem zu lösen, welche Auswirkungen das konkret für die betroffenen Bürgerinnen und Bürger hatte, wer die mutmaßlichen Täter sind und vor allem stellt der Podcast die Frage: Kann so etwas jederzeit wieder und überall in Deutschland passieren?
Der sechsteilige Storytelling-Podcast YOU ARE FUCKED über ein wahres Cyber-Verbrechen startete am 6. Juli in der ARD-Audiothek. Inzwischen sind bereits die ersten drei Folgen (jeweils knapp unter einer Stunde) online abrufbar. Persönlich tue ich mich schwer mit Podcasts, weil die Informationen nicht auf die Schnelle durch Querlesen erfasst werden können.
Ich habe aber mal stichprobenartig in die Podcasts reingehört – wer gerne ein Bild erhält, wie das Ganze von Betroffenen erlebt wurde, kommt auf seine Kosten. "Unvorstellbar, alles neu zu machen", das ist die Aussage, eines Mitarbeiters. Ob man die Aufbereitung mit der Musikunterlegung mag, ist eher eine persönliche Geschichte.
Was nett ist: In den Podcast-Folgen erhält man Einblicke, wie die Mitarbeiter des Landkreises in der IT durch den Angriff und in der Folgezeit betroffen waren. Wie sagt Fefe "wer schöne Verschwörungstheorien hat, her damit". Im Podcast erfährt man, wie Leute ihren Urlaub absagen mussten oder mit ihren Ehefrauen beim Essen beeinträchtigt wurden. Der geneigte Hörer bekommt auch eine Beschreibung eines Beamten mit "Halbglatze" – wie sagte Joschka Fischer "wenn es der Wahrheitsfindung dient" – wer gerne Hörkrimis konsumiert, wird auf seine Kosten kommen. Spannend fand ich dann doch die Informationen, die in Teil 2 eingestreut wurden – einmal zur ausgenutzten Schwachstelle (Print Nightmare, hat sich aber später als falsch herausgestellt) – aber auch zur Rolle des BSI (mit begrenzten Ressourcen), zu externen IT-Firmen, die dann "mal weg waren".
Was bleibt unter dem Strich? Die Podcast-Folgen zeichnen die Irrungen und Wirrungen der Verwaltung und der agierenden Beteiligten nach – sozusagen ein Stück aus dem Leben. Wie ich schon schrieb, wer gerne Hörkrimis konsumiert, wird auf seine Kosten kommen. Persönlich habe ich das Problem, dass mir solche Formate nicht liegen – ich benötigt die Information sehr kompakt, technisch auf den Punkt gebracht, um schnell über die relevanten Fakten informiert zu sein. Damit bin ich als Blogger, der über Sicherheit schreibt, definitiv nicht der Zielkreis. Aber vielleicht gibt es in der Leserschaft Leute, die Interesse an den Hintergründen – und Zeit zum Anhören des Podcasts – haben – vielleicht Stoff für laue Sommerabende, wenn es noch nicht zu kalt zum draußen Sitzen und Sterne schauen ist.
Ergänzung: Golem hat hier die Geschichte ebenfalls aufbereitet.
Ähnliche Artikel:
Cyberangriffe: Gedia & Potsdam Opfer des Shitrix-Desasters (Citrix Netscaler-Bug)?
Vermuteter Cyberangriff auf Stadt Potsdam, Stadtwerke auch offline (29./30. Dez. 2022)
Cyber-Desaster: TU-Freiberg down; Stadtverwaltung Potsdam wieder offline, Polizei BW offline und mehr
Ransomware bei Landkreisverwaltung von Anhalt-Bitterfeld
Notstand nach Ransomware bei Landkreisverwaltung von Anhalt-Bitterfeld
Anzeige
Ich hatte versucht den ARD Podcast zum Bundestags Hack zu höhren aber das war so dramatisiert, künstlich spannend gemacht und in die Länge gezogen das ich schnell aufgegeben habe. Nichts gegen echte Höhrkrimis aber das ist eher so aus der Abteilung "True Crime" wie man heute so schön sagt.
Ich habe mir die 3 Folgen nur ausschnittsweise angehört und kann dem ganzen nicht real folgen.
Ich kann mir einfach nicht vorstellen, dass jeder Benutzer in dem Netzwerk auf Domain-Admin war – Ich denke mit Sicherheit nicht.
Wenn alle Daten dort verschlüsselt wurden ist ja gar nichts mehr da. Also bei der KFZ Stelle kein Auto mehr bekannt. Backups waren anscheinend kaputt und dennoch konnte man danach irgendwie ??? weiter arbeiten.
62 GB wurden angeblich abgezogen – Denke einmal die müssen doch viel grössere Datenbanken gehabt haben in allen Ressorts.
Irgendwie passt das alles nicht zusammen.
Zum Nachdenken sollte es dennoch jeden IT Veranwortlichen zwingen und einen Worst Case aufstellen. Was Wäre Wenn. Ich denke da sind viele Unternehmen sehr im Rückstand.
Was ist wenn meine Bank keinerlei Daten mehr von meinen Konten hat. Die können ja nicht irgendwie bei 0 anfangen.
Danke für die Auffrischung.
Über diese Fälle reden wir auf Arbeit recht häufig, weil insbesondere Potsdam unter "könnte dir jederzeit selbst passieren" fällt.
Das letzte Mal war es Thema, als ein neues System für Mobildienste in Betrieb ging und dabei wieder auffiel, was eigentlich so grundsätzlich falsch läuft in der typischen IT-Organisation.
Vielleicht auch als Tipp an andere, um da früher gegen zu steuern.
Es geht ein Auftrag raus, ein System auf unserer Infrastruktur einzurichten und vereinbarter Übergabepunkt ist die Abnahme der Vollfunktion. Minimale Rechte und Zugriffe sind nicht vereinbart. Eigentlich nichts, außer "muss laufen".
Wie eigentlich immer in solchen Fällen wird dann alles aufgerissen, für die Installation benötigt man unspezifizierten, vollen Internetzugriff. Es werden Windows-Rollen benutzt, teils System und man bekommt freundliche Hinweise, dass man das ändern sollte. Der Versuch, das gleich einzusteuern scheitert, soll erstmal fertig gemacht werden.
Dann ist es "fertig" und Ende. Vertrag erfüllt.
Alles offen, eskalierte Rechte für ein angreifbares System und jetzt ist es Deine Aufgabe, das gerade zu biegen.
Dummerweise läuft man damit gegen alle Hindernisse an, die möglich sind.
Ohne Genehmigung darfst du nur Änderungen durchführen, die keinen negativen Impact haben. Dass das nicht trivial ist, zeigt die Arbeit der Firma, die sich aufgrund schlechter Verträge um dieses Problem rumgedrückt hat.
Eine Genehmigung kriegst du dann oft auch nur für "wenn es die Funktion nicht beeinträchtigt".
Dafür brauchst du dann viel Zeit, die du nicht hast. Und wenn eine Härtung doch versteckte Probleme verursacht, bekommst du schnell Stress oder richtig Ärger.
Je nach Ausprägung kann das auch richtig ungemütlich werden, wenn dann irgendwas klemmt. Ich habe da schon mal das Wort "Sabotage" zu hören bekommen, was dann freundlich ins StGB (303b) führt. Und mir wurde dann schon mal von "ganz oben" verboten, ein System überhaupt anzufassen. Völlig gaga, wenn man das Netz administriert.
Wer also irgendwie in Behörden, in verkrusteten Entscheiderstrukturen landet, sollte hier immer rechtzeitig alles tun, damit schon die Verträge ordentlich gemacht werden. Ersatzweise sich vorher alle nötigen Absicherungsmaßnahmen, samt etwaiger Nebenwirkungen, freigeben lassen. Am besten in einer Pilotphase.
Das mag alles nach basics klingen. Aber als Unerfahrener rennt man da schnell in unerwartete und dann wirklich aufreibende Probleme, insbesondere halt in Behörden.
Und je nach Entscheiderstruktur wird man auch als Erfahrener damit konfrontiert, dass der Auftrag dann plötzlich auf dem Tisch liegt und man quasi überrollt wird. Hier ist möglichst frühes Gegensteuern dann Gold wert.
Läuft das Zeug erstmal umd die Leute arbeiten damit (was verdammt schnell gehen kann, hatte da mal einen Zeitraum von 10 Minuten), dann rennt man gegen verschlossene Türen und arbeitet auf eigenes Risiko.
Das könnte einen dazu verleiten, komplexe Absicherungsprobleme dann lieber nicht anzufassen.
Dann wäre man selbst rechtlich safe, aber halt die Organisation gefährdet. Die sich aber für unangreifbar hält und es letztlich auch ist. Und dich dann halt trotzdem den Wölfen zum Fraß vorwirft, wenn was passiert.
Wenn man nicht rechtzeitig Traktion bei der Absicherung bekommt, dann ist halt schnell "machen" genauso falsch, wie "nicht machen".
Und nein, gefeuert werden wegen "machen" ist nicht nur theoretisch. Dieses Jahr ein Fall in meiner Umgebung und der ist für den Bereich "verbrannt". Gab danach halt Streit und das war sein zweiter "Fehler".
Über "nicht machen" muss man hoffentlich nicht weiter reden.
Ihre Erfahrung bei der Implementierung neuer Software/Systeme teile ich, allerdings werden sie sich den Kopf einrennen.
"Herr B., wir sind keine Bank!" war die regelmässige Antwort auf Einwände. Zudem 'Zwänge' wie dass es nur 1+ Anbieter gab und Die dann schlicht sagten "wir verkaufen nur zur Bedingung X*".
Um selbst (Mitarbeiter) leistungsfähig zu bleiben muss man das an sich abprallen lassen: Die Einwände nachweisbar/schriftlich machen (inkl. Zugangsbestätigung bzw. Antwort) und dann einfach laufen lassen. Es ist Aufgabe des (IT-)Managements, da die richtigen Prioritäten zu setzen – nicht der Stellvertreter und schon gar nicht der gemeinen Mitarbeiter.
* z.B. root-Zugriff für ihre Software oder Nutzung des dba-Passwortes auf den Clients
Man rennt sich da auch den Kopf ein.
Und alles reporten und dokumentieren ist ja eh Berufspflicht.
Aus Erfahrung kann ich aber sagen, dass z.B. die Vereinbarung, dass von der ausführenden Firma "Security Guidelines des Herstellers" zu beachten sind, sich auch noch ganz kurz vor Vertragsschluss unterbringen lässt. Da will sich keiner quer stellen.
Ebenso erfolgreich ist oft, einen Pilot- oder Probebetrieb mit Chef rauszuhandeln. Zwar mit manchmal nur wenig Zeit, aber hier kann jeder Zeitraum helfen.
Hat man so einen Fall, wo alles in Sack und Tüten ist und man völlig überrant wurde, dann hilft natürlich wirklich nur noch Eigenschutz und Gefährdungsanalyse. Die ja eigentlich vorher stattfinden sollte und gerne auch nicht die eigene Aufgabe ist. Hier kann es also immer an allen Ecken und Enden knallen. Auch als Zuständigkeitsgerangel und das selbst dann, wenn "zuständig" nichts tut.
Aber jeder Fall, wo man vorher noch den Fuß rein kriegt, schont die Nerven.
Ist schon traurig, dass man sowas schreiben muss. Aber ich beziehe das hier mal explizit auf verkrustete Entscheiderstrukturen, meist hornalte ITIL-Prozesse in Aktion, bei denen dann "von oben" agil was reingedrückt wird, obwohl die Serviceorganisation komplett konträr organisiert ist.
In vielen Behörden nennt man das "Tagesgeschäft", insofern dort Augen auf.
Zur Ehrenrettung von Behörden: es gibt auch viele, wo das sauber läuft. Umd nahezu alle wollen es besser machen und investieren viel in gute Prozesse.
Leider dann gerne über Berater, ohne allzu viel Kontakt mit der Betriebsbasis und unter Annahme eines eigenen Handelns, das bestenfalls als "idealisiert" beschrieben werden kann. Wenn es dann mal einen richtigen Vorfall gab, kommt da entweder Realismus auf oder die Idealisierung der Prozesse und Handelnden wird pathologisch.
Genau wie die Betrachtung des Verhaltens des Managements zum Schadenszeitpunkt. Auch idealisiert. Während alles an der Front mit Mikroskopen nach kleinsten Fehlern durchsucht wird.
Nebenmanager XY in einer Mitteilung nicht einbezogen? Also alles deine Schuld. Klar hätte der das sofort von Abteilungsleiter B erfahren müssen, aber irgendwas ist ja immer.
Das auch als Anmerkung dazu, sich da aufs Management zu verlassen. Dann darf man aber auch nicht den kleinsten Fehler machen. Und wenn man – je nach Persönlichkeitsstruktur von meist politischem ChefChef – dennoch eines Fehlers bezichtigt wird, sollte man genau wissen, wann man den Mund hält und wann nicht.
Sollte jeder schauen, wo seine Kernkompetenzen liegen und möglichst viel auf diesem Feld regeln.
Aber ja. So lange es nicht richtig laut knallt und der Stuhl vom ChefChef wackelt, kann man sich meist entspannt mit "ist nicht meine Aufgabe" da raus ziehen. Und natürlich auch dann, wenn eine echte Verantwortungskette existiert.
In vielen Behörden wird dann aber ganz nach unten gezeigt, wie es auch die Bürger tun. Entscheider machen da oft keine Fehler.
Alles Problem dessen, der das praktisch betreut hat.
Und dagegen kommt man dann kaum an.
danke für deinen beitrag
Danke für den Artikel. Grundsätzlich läuft man bei solchen Projekten immer gegen die Wand. Was hier Andy und Bernd B. geschrieben haben, kann ich voll unterschreiben.
Ich bin schon über 20 Jahre im IT-Service und die letzten 10 Jahre als Ein-Mann-Systemhaus tätig, als Gewerbe. Es fehlen oft Richtlinien, oder der rote Faden, welcher Projekt übergreifend als Richtung dienen sollte. Dazu kommen auch zu viele, welche da mitmischen wollen, aber von der Materie keinen blassen Schimmer haben. Oder noch besser, die dir deinen Job erklären wollen. Vom Budgetgerangel ganz zu schweigen.
Da lehne ich lieber den Auftrag ab, als mich wochenlang damit herum zu ärgern. Dann soll der Quark lieber jemand anderes machen.
Ach, ich tanze gerade das 30igste Jahr in der IT rum.
Und mir versuchen immer noch Leute meinen Job zu erklären. Das ist aber normal, einfach weglächeln oder – wenns schlimm wird – auch mal auflaufen lassen.
In den letzten Jahren sind andere Dinge neu als besonders negativ hervorgetreten. Zwei ganz besonders.
Erstens eine zunehmende Naivität, oder sowas wie "glauben statt wissen wollen".
Da hört man dann von Führungskräften, dass die "schon wissen, wie man das richtig macht" und ist deshalb der Meinung, keine Vorschriften machen zu müssen. Das kompliziere alles nur.
Oder irgendwo steht "Software ist DSGVO konform" und dann ist halt alles gut. Auch wenn die betreffende Person sehr genau wissen sollte, dass diese Aussage so Marketingunsinn sein muss, weil ja in Bezug auf die DSGVO eine Software alleine gar nichts ist.
Vielleicht so eine Art Schutzreaktion vor dem ganzen, komplizierten Scheiß, den man nicht will. Den man also einfach weg glaubt.
Und das zweite ist eine Verschiebung der Verantwortungsdiffusion auch nach unten in der Kette.
War es früher normal, dass in der Führung Verantwortung für die IT gerne ignoriert wurde, aus oft verständlichen Gründen wie tausend andere Verantwortungsgebiete, auch welche mit Menschenlebenverantwortung, so wandert das seit Jahren die Kette runter.
Das mittlere Management erodierte schon vor 10 Jahren in diesen Belangen vor sich hin.
Heute sind wir an der Stelle, wo auch ganz unten oft die eigene Verantwortung nicht mehr gesehen wird.
Da steht in der Aufgabenbeschreibung, dass man verantwortlich ist, z.B. für das Ausrollen von Software und die Absicherung der Systeme. Weil das aber aufreibend ist in den typisch dysfunktionalen Hierarchien, argumentieren sich die Leute dann aus der Verantwortung. Weil sie diese z.B. woanders hingeschoben hätten und dann sei es gut.
Das war früher noch anders.
Der Fisch stinkt zwar immer noch vom Kopf her, aber auch ganz unten in der Kette läuft es zunehmend aus dem Ruder.
Ich habe manchmal echt Lust, ganz laut "arbeiten ist kein Ponyhof" zu rufen.
Gibt immer gute Ausreden, warum z.B. die korrekte Funktion nicht kontrolliert wurde. Aber dafür gibt es keine. Fehler erkennen und besser machen. Und nicht eine lange Liste von Gründen vorschieben, warum da irgendwer anders dran schuld ist. "Das ist nicht mein Problem" wird irgendwie zur Seuche.
Alles zu anstrengend vermutlich.
Und das berichten mir auch Kollegen von woanders, Partnerinnen, eigentlich jeder.
Das ist alles noch zu handlen. Aber, bei mir macht sich das Gefühl breit, dass irgendwas grundsätzlich schief läuft.
Ich mache jetzt schon Verantwortungsübungen, so mit Auswertungen und Manöverkritik.
Haben einige noch nie erlebt. Ihre Arbeit mal verteidigen müssen, völliges Neuland.
Und das sind nicht mal die Azubis, sondern ausgedehnte Leute.
Ach. Von einer Vetragsfirma habe ich mal einen Techniker weg geschickt, weil der so tat, als wären die Probleme bei seiner Arbeit bei uns nicht seine Probleme. Die hatten vorher gefragt, ob sie den mal schicken könnten und nicht unsere normalen Leute. Waren dann richtig dankbar, dass sie mal eine ordentliche Rückmeldung bekommen haben und damit mit ihm arbeiten können.
Ich weiß echt nicht, wie die Leute bis dahin durchgekommen sind.
Vielen lieben Dank für deinen Kommentar. Das kann ich vollumfänglich unterschreiben, du spricht mit aus der Seele. Manche denken eben auch, so wie die zu Hause herumpfuschen, können die es auch in der Firma machen. Aber nicht mit mir.
Vielen fehlt eben auch das Verständnis dafür und oft auch die elementarsten Basiskenntnisse, aber die große Fresse haben.
"Ich weiß echt nicht, wie die Leute bis dahin durchgekommen sind." Das frage ich mich auch oft.
Als uraltes Schlachtross, der am 1. Oktober 1993 (also vor 30 Jahren) aus dem IT-Management in einer großen Chemiefirma ausgestiegen ist, um seinen eigenen heißen Scheiß zu machen, ist mir aber noch erinnerlich, dass im Upper-Management die Verantwortlichkeiten – speziell in der Produktion – ganz klar an die unteren Führungsebenen delegiert wurden.
Damals gab es die großen und kleinen Chemieunfälle (Seveso, Bhopal). Haftbar wären die Vorstände gewesen – ergo wurde das Ganze nach unten delegiert und dokumentiert. Am Ende waren die Betriebsleiter in der juristischen Verantwortung. Unterhalb dieser Ebene mussten die Mitarbeiter nur sicher gehen, nicht gegen Betriebsanweisungen zu verstoßen, um nicht Fahrlässigkeit vorgeworfen zu bekommen.
Die Betriebsleiter haben dann sehr darauf geachtet, die Umwelt- und Sicherheitsauflagen einzuhalten – und die Betriebsingenieure (Verfahrenstechnik, Umwelttechnik, Mess-und-Regeltechnik, Sicherheitstechnik) haben da Hand-in-Hand gearbeitet.
Das scheint inzwischen in der IT gänzlich vergessen worden zu sein – mein Eindruck.
Spoiler: Es sieht so aus, als ob meine (damals von Vielen unverstandene) Entscheidung, den eigenen heißen Scheiß zu machen, nicht ganz verkehrt war. Auch wenn ich natürlich für alles wirtschaftlich, technisch und juristisch die Knochen hinhalten musste – die Kohle kam auch nicht vom Arbeitgeber.