| Software-Engineering-Experts . | ||||
Mitgliedschaften in Fachverbänden:
|
Referenzen |
Impressum |
Datenschutz |
Kontakt
|
||||
|
🏠 | Data Engineering | V‑Modell + DevOps | Innovation | Requirements Engineering | SW‑Architektur | UML | Coding | Building+Integration | Testmetriken | Freigabe | Betrieb | Außerbetriebsetzung | Dokumentation | SPICE | ML und Künstliche Intelligenz | Safety | Security. | Projektmanagement | IT‑Recruiting und Führung | Lebenslauf | In der Presse | |
||||
Lehnen Sie sich einen Moment zurück und überlegen bitte einmal kurz, was Ihr Unternehmen wert ist.
Das ist die Metrik der erpressbaren Beute. Es lohnt also ein ziemlicher Aufwand seitens der Angreifer.
Überlegen Sie jetzt, ob die Realität bei Ihnen von einem tiefen, kulturell verankerten und täglich vielfach ganz nebenbei ohne besonderen Aufwand selbstverständlich gelebten Cybersecurity-Denken und Handeln geprägt ist -
oder es eher darum geht, Audits ohne Verlust persönlichen Ansehens irgendwie zu überstehen.
Wann haben Sie persönlich das letzte Mal die Webseite des BSI nach Nützlichem durchforstet?
Was sagen Ihnen Skript Kiddies, im Darkweb preiswert käufliche Ransomware‑KI und Social Engineering bzw. Human Hacking?
Sind Sie bereits nach ISO 27001 zertifiziert oder ziehen die ISO wenigstens als Orientierung heran?
Welche Compliance‑Policys sind bei Ihnen verschriftlicht und werden tatsächlich auch gelebt?
Erhalten die Admins den Security‑Job On Top, werden die auch nicht engagierter als Sie sein.
Das Einspielen von Patches der Hersteller ist nur so etwas wie eine Grundversorgung der Krankenversicherung:
man überlebt meist gerade so eben, aber schöne Zähne kosten ziemlich viel extra.
Das Überleben des Unternehmens kann also von der Art der gelebten Realität abhängen.
Der Fall Bosshard‑Farben AG, Schweiz, knapp 200 Mitarbeitende (Quelle: NZZ Format, 17.5.2026)
Im Grunde alles richtig gemacht: nicht nur naiver Perimeter‑Schutz, sondern auch intern sauber gehärtete Abschottungen.
Aber Human Hacking bzw. Social Engineering lieferte mit einem schwachen Passwort einer Remote‑Access‑Lösung die Eintrittsmöglichkeit (Patient Null.1).
Intern fiel es den Angreifern aufgrund der guten Härtung dennoch schwer, voranzukommen.
Das änderte sich mit der Entdeckung eines zu schwach gesicherten Bildschirms für Stapler des Hochregallagers (Patient Null.2).
Das war's. Das gesamte Dateisystem wurde verschlüsselt, die Erpressung gestartet.
Man hat dann die gesamtgesellschaftlich verantwortungsvolle Reaktion gezeigt: keine Zahlung
(ist eh' keine gute Idee: allzu oft wird das System auch nach Zahlung nicht wieder freigeschaltet, warum auch der Aufwand?
Oder drei Monate später erneut gehackt. Trojaner verbleiben dazu im System, logisch.).
Es fand sich ein letztes unverschlüsseltes Backup, das zur Basis eines Neuaufbaus wurde.
Teuer, aber immerhin überlebt.
Ich zolle der Geschäftsleitung höchsten Respekt:
vor einer so offensiven Art der Veröffentlichung im TV schrecken viele zurück -
und doch wird gerade so auch der Letzte in die Lage versetzt, Realität nachzuvollziehen und damit sein eigenes Unternehmen angemessen schützen zu wollen.
Eine Anmerkung sei mir noch erlaubt: viele Unternehmen erzeugen zwar Backups.
Aber so richtig getestet wird nicht, ob die Anwendungen danach mit allen Abhängigkeiten wieder laufen, hier gab es schon böse Überraschungen.
Das Eindringen erfolgt grundsätzlich über zwei Wege: Social Engineering/Human Hacking und technisches Scanning nach Sicherheitslücken.
Als Wirtschaftspsychologe gebe ich Seminare zum ersten Thema und als Ingenieur im Rahmen von Software Engineering unterstütze ich mit DevSecOps gegen zweiteres.
Glücklicherweise bringen viele Elemente von DevOps bereits einen Security‑by‑Design‑Aspekt mit.
Denn der Teufel kommt nicht hässlich mit Hufen, sondern gut getarnt im schicken Anzug oder in unschuldig‑weißer Kleidung daher.
Es gibt Gründe, warum sich Gurus so gerne in Weiß kleiden 🙄.
Bei Security geht es im Gegensatz zu Safety um Schutz gegen bewusst ausgeführte Angriffe.
KI ermöglicht in schnell wachsendem Maße auch sog. „Script Kiddys“ hochwertige Angriffe ohne besondere Kompetenz oder Anstrengung.
Deutlich wird die Gefahrendynamik, wenn wir überlegen, wie sich der Zeitraum von erstmaliger Veröffentlichung einer Schwachstelle samt Flicken (patch)
bis zu ersten,
genau darauf abgestimmten Malware‑Angriffen verändert hat: waren es „früher in der guten, alten Zeit“ einmal Wochen,
sind es heute nur Minuten. Tendenz: Beschleunigung durch Automatisierung und KI.
Aus diesem und anderen Gründen lässt sich gut argumentieren, dass sehr gute Entwickler erst in den Bereichen Test und Security optimal eingesetzt werden.
Dies gilt immer dann, wenn es im funktionalen Coding nicht um sog. „Bleeding‑Edge‑Entwicklungen“ geht. Also fast immer.
Angriffe werden aus unterschiedlichsten Gründen gestartet:
Softwareseitig bieten die Prinzipien des Security‑by‑Design wie „Hohe Modularität, starker Zusammenhalt, geringe Kopplung“ eine gute Basis.
Codingvorgaben sind unerlässlich: unsichere Prozeduren und unsichere Befehle sind zu entfernen bzw. erst gar nicht zu erlauben.
Einer von vielen Umsetzungen des Left‑Shift‑Prinzips, die Verlagerung von Security an den Anfang aller Prozesse.
Das Prinzip der minimalen Rechtevergabe oder auch „Least Priviledge“ ist aus Security‑Sicht immer eine gute Idee,
könnte allerdings den Transparenz‑ und Eingriffsprinzipien von DevOps diametral entgegenstehen. Hm.
Die Praxis ist natürlich komplex: Was z.B. tun, wenn ein Admin am Wochenende um Mitternacht besondere Rechte benötigt, um ein System wieder ans Laufen zu bringen?
Hier bietet sich die Idee des Brandmelders (broken glass) an:
Der Admin kann sich die Sonderrechte innerhalb gesetzter Sondergrenzen selbst zuweisen -
allerdings wird automatisch eine Meldung an hohe Führungskräfte abgesetzt, die den Warnflag als einzige neutralisieren können
(vereinfachte Darstellung, nicht für alle Kulturen passend).
Auch bereits vorhandene, sehr sauber programmierte Strukturen sind laufend abzusichern.
Die Risiken von Funktions‑ oder Modulaufrufen werden beispielsweise durch die Canary Mitigation gemildert
(hier als Beispiel gewählt, weil ich die Bezeichnung zugleich nett und passend finde).
Für bekannte Risiken existieren Listen, an denen sich sowohl das Coding‑ als auch das Cybersecurity‑Team bedienen können und sollen.
Das Software‑Engineering macht den Weg frei.
Letztlich kann es keine allgemeingültiges Optimum zwischen Security und DevOps geben -
im Unternehmen ist im Rahmen hochwertig moderierter Meetings abzustimmen, WELCHE Inhalte WIE umzusetzen sind.
Auch bloße Anwender von Software tun gut daran, ihre Systeme zu härten.
Die EU‑Gesetzgebung wie z.B. der Cyber Resilience Act CRA bieten einen von mehreren guten Startpunkten.
Das größte Risiko sitzt immer noch vor dem Monitor.
Berichte von erfolgreichen Ransomware‑Angriffen erreichen uns laufend: meist war ein Passwort unsicher, hat jemand einen unschlauen Klick ausgeführt,
hat auf einen gefälschten Anruf hin Geld überweisen,
hat freundlicherweise jemanden auf die Toilette gelassen oder eine andere Handlung ausgeführt,
die wir aus der entspannten Ferne heraus für unmöglich gehalten hätten.
Den Anfang nahm dieses Konzept des Social Engineering in der DDR bei den sog. „Romeos“.
Diese physisch nicht unbedingt hoch attraktiven Männer wurden binnen drei Monaten dazu ausgebildet, Frauen in sich verliebt zu machen.
Was bereits mit überschaubaren psychologischen Kenntnissen in Verbindung mit passendem Training überraschend gut funktioniert
(Hallo Leute: dieser Hinweis hat es in sich! Ist allerdings hier kein Thema 😉).
Im Westen angewendet, lieferten Sekretärinnen dann brav Geheimnisse.
Das Wort „Sekretärin“ hängt übrigens mit „secret“ zusammen und beschreibt eine Geheimnisträgerin.
Ein sehr bedeutender, oft unterschätzter Beruf. „Assistentin“ kann da nicht mithalten 😉.
Die moderne Variante dieser Social‑Engineering‑Anwendung heißt „Loverboy“, gleichfalls mit üblen Folgen für die Opfer.
Lassen Sie Personen mit Zugang zu Geheimnissen wie Credentials (Passworte, API‑Schlüssel u.v.m) in der Abwehr schulen!
Ein Szenario für eine bessere Zukunft:
Über die Standardkanäle Ihres Security‑Teams oder ‑Dienstleisters taucht eine Sicherheitslücke in einer Abhängigkeit von außen auf.
Da Sie in Ihrer CI/CD‑Pipeline natürlich auch automatisiert Dependency‑Scannings betreiben,
verfügen Sie über ein stets vollständiges und aktuelles
SBOM (Liste aller Module und Abhängigkeiten, die „Software Bills of Material“, einschließlich der Supply Chain).
So schauen Sie kurz nach und finden, dass dort kein log4j (oder was auch immer) zu finden ist. Oder halt doch. Sie starten binnen Minuten Maßnahmen.
Klar, technisch anspruchsvoll, je nachdem, wo Sie aktuell stehen.
Und die Transformation in Richtung tauglicher DevSecOps ist nicht einfach.
Naive Ansätze wie ein „Sie werden produktiver!“ gegenüber der Mitarbeiterschaft erzeugen zunächst Widerstand gegen das konkrete Projekt und
dann im zweiten Schritt Widerstand gegen Veränderungen an sich. Sie erzeugen, was Sie als Führungskraft später beklagen.
Transformation, Veränderungsmanagement, Change Management: alles Begriffe für Unterfangen, die ohne wirtschaftspsychologische Kompetenz hoch riskant sind.
Mit auch. Aber weniger 😉.
Laufen bei Ihnen Reinigungskräfte nach Büroschluss durch die Zimmer? Nichts einfacher, als einen USB-Stick einzustecken.
Nichts einfacher, als sich von einer Reinigungsfirma anstellen zu lassen.
Oder eine Reinigungsfirma zu kaufen. Oder zu gründen. Sicherheitsüberprüfung? Pruuuuuuuuuuuuuuust!
In unserem Vertrauen machen wir es aber auch echt an zu vielen Stellen zu einfach:
Bestechung, Erpressung, Ausnutzung von Gier, Groll, kognitivem Geiz und den ganzen anderen Schwächen:
Die größten Risiken sind nicht technischer Natur.
Achten Sie beispielsweise darauf, dass Ihr Personal am Empfang auch bei (künstlich erzeugter) Abgelenktheit niemanden unbemerkt durchschlüpfen lassen können.
Ganz einfach durch eine Zugangstür, die mit einem Taster aktiv geöffnet werden muss.
Damit neutralisieren Sie zumindest an dieser Stelle den Human‑Hacking‑Angriffsvektor „Enge Limitierung der Größe des Arbeitsbereiches im Gehirn“ deutlich.
Eine Stufe weiter wäre eine optisch ansprechende Schleuse - dann haben Sie auch gleich den Spaß, die Angreifer festgesetzt zu haben.
Einige Stichworte für Security‑Tests in bestem Denglisch:
Die aktuell passenden und vermutlich langfristig existierenden Tools sind beim Start neuer Security‑Aktivitäten in einer aktuellen Recherche zu ermitteln.
Unabhängig davon ist neben den Prinzipien von DevSecOps und anderen Strategien natürlich auch eine möglichst kontinuierlich automatisiert generierte Software Bill of Materials (SBOM) empfehlenswert.
Egal, ob Sie Software selbst entwickeln oder lediglich nutzen.
Tipp: Bauen Sie aus allem eine eigene Compliance‑Pipeline auf und sichern Sie die Durchsetzung!
Zurück zum Human Hacking und Social Engineering:
Die am häufigsten ermittelte Ursache für nachlässiges, kontraproduktives oder sabotierendes Verhalten von Mitarbeitern ist, wissenschaftlicht gut belegt, erlebte Ungerechtigkeit.
Nicht tatsächliche Ungerechtigkeit: Objektive Gerechtigkeit kann als höchst ungerecht erlebt werden.
Von diesen Menschen bemerken Sie an der Oberfläche nichts.
Diese Menschen werden leicht zu willfährigen Helfern von Angreifern. Jemand wird nicht wie erhofft befördert. Oder wird ab und zu im Satz unterbrochen.
Oder lächerlich gemacht. Oder inkompetent kritisiert. Oder inkompetent gelobt. Oder sieht sich häufig sog. Gesprächsstörern ausgesetzt.
Oder erfährt irgend etwas anderes aus der langen Liste unprofessionellen Führungsverhaltens und riskanter Unternehmenskultur.
Daraus ergibt sich ein weiterer Grund für eine gut reflektierte und mit professioneller Handlungskompetenz ausgestattete Führungskultur:
lassen Sie im Unternehmen professionelle Führungskommunikation trainieren.
Oder, falls Sie selbst Führungskraft sind oder werden wollen: investieren Sie selbst in sich, wenn es sonst keiner macht.
Kein Mensch sollte ohne abgelegten Qualifikationsnachweis Führungskraft werden. Das ist einfach zu gefährlich.
Unternehmen bieten Angriffsoberflächen, wo Geschäftsleitungen dies nicht in Ansätzen bedenken, die unknown Unknowns.
Sie ahnen es: als führungserfahrender, softwarelastiger Ingenieur und zugleich Wirtschaftspsychologe M.Sc. bin ich Fachexperte 🙄.
Ein tauglicher Neustart (Refactoring) Ihres Security‑Ansatzes startet typischerweise mit einem hochwertig moderierten Kick‑Off‑Meeting aller Stakeholder.
Ein Left‑Shift der Einflussnahme des Security‑Teams ist dabei als Ergebnis, wie so manch anderer Punkt auch, anzustreben.
Gehen wir es gemeinsam an!