CSOonline

IT-Security-Verantwortliche sollten die Angriffsfläche permanent analysieren und schützen. Dazu müssen sie stets im Blick haben, welche Assets über das Internet erreichbar sind. Foto: NicoElNino – shutterstock.com Von IoT-Devices über Cloud-basierte Infrastrukturen, Web-Applikationen und Firewalls bis hin zu VPN-Gateways: Die Anzahl unternehmenseigener Assets, die mit dem Internet verbunden sind, steigt exponentiell an. Sie ermöglichen beispielsweise den Zugriff auf Daten, Sensoren, Server, Onlineshops, Webseiten oder andere Anwendungen. Allerdings wächst mit jedem zusätzlichen Asset die externe Angriffsfläche – und damit das Risiko für erfolgreiche Cyberattacken. Asset Discovery reicht nicht aus Diese externe Angriffsfläche ändert sich bei vielen Unternehmen oftmals im Tagestakt, ist äußerst komplex und stellt die Security-Verantwortlichen vor erhebliche Herausforderungen. Sie müssen stets im Blick haben, welche (neuen) Assets über das Internet erreichbar sind, und sich über entdeckte Sicherheitslücken informieren. CISOs benötigen deshalb ein feines Gespür für mögliche Schwachstellen und Fehlkonfigurationen. Außerdem sollten sie über ein Team verfügen, das weiß, wie es gefundene Bedrohungen abwenden kann und welche Maßnahmen zu ergreifen sind. Aber welche Sicherheitslücke soll überhaupt zuerst geschlossen werden? Ein effektiver Schutz der unternehmenseigenen IT-Infrastruktur benötigt ein mehrstufiges Konzept für External Attack Surface Management (EASM), das auch eine Abwägung des individuellen, tatsächlichen Risikos der Schwachstellen umfasst. Dieser iterative Prozess lässt sich grob in vier aufeinander folgende Schritte einteilen. Schritt 1: Assets identifizieren und klassifizieren Nur wer alle Assets kennt, kann sich effektiv schützen und die Angriffsfläche aktiv managen. Doch die Identifizierung ist leichter gesagt als getan. Das gilt für mittelständische Unternehmen und noch viel mehr für große Konzerne mit zahlreichen Untergesellschaften. Sie tun sich oftmals schwer, alles extern Erreichbare im Blick zu behalten. Dazu trägt auch die Schatten-IT bei, in der Mitarbeitende entgegen den geltenden Compliance-Regeln ohne das Wissen und ohne die offizielle Zustimmung durch die interne IT-Abteilung zum Beispiel nicht freigegebene Software-Anwendungen installieren oder Cloud-Dienste nutzen. Um dennoch eine stichhaltige Übersicht über alle relevanten Assets zu erhalten, müssen Verantwortliche die externe Angriffsfläche regelmäßig automatisiert überprüfen. Im Idealfall werden dabei nicht nur alle relevanten Assets identifiziert, sondern auch den entsprechenden Unterorganisationen, Töchtern & Co. zugeordnet. External Attack Surface Management geht dabei weit über klassisches Asset Discovery und Vulnerability Scanning hinaus. Es nimmt auch “blinde Flecken” ins Visier – etwa vergessene Cloud Assets sowie nicht mehr genutzte oder fehlerhaft konfigurierte IT- und IoT-Infrastrukturen. Schritt 2: Risikoerkennung Um festzustellen, welche Anfälligkeiten bestehen und welches Gefährdungspotenzial sich dadurch für das eigene Unternehmen ergibt, werden diverse Testverfahren auf verschiedenen Ebenen durchgeführt. Ob die potenzielle Gefahr von bestimmten Anwendungen ausgeht, lässt sich beispielsweise mit Dynamic Application Security Testing (DAST) in Erfahrung bringen. Zudem sollte überprüft werden, ob sicherheitsrelevante Daten, beispielsweise für die Steuerung einer Produktionsanlage, eventuell bereits unbeabsichtigt über das Internet einsehbar sind. Ein weiteres Sicherheitsrisiko sind nicht autorisierte Anmeldungen. Hier kommt Credentials Testing zum Einsatz. Zudem sollten Unternehmen permanent im Auge behalten, ob ihre Assets von bereits bekannten und veröffentlichten Sicherheitslücken betroffen sind. Schritt 3: Risikobewertung Alle entdeckten Schwachstellen bergen ein gewisses Risiko, doch dieses ist nicht immer gleich hoch. Um es realistisch bewerten und klassifizieren zu können, stehen drei Metriken im Mittelpunkt. Erstens die Exploitability mit der zentralen Frage: Gibt es für die spezielle Sicherheitslücke tatsächlich bereits bekannte Angriffsvektoren, oder ist sie bisher eher theoretischer Natur und noch nicht konkret ausgenutzt worden? Zweitens die Attractiveness für Angreifer. Hier ist die Frage: Befindet sich die Sicherheitslücke auf einem Asset oder Zielsystem, das für eine Attacke interessant ist? Eine zentrale Datenbank ist hier beispielsweise wesentlich lohnenswerter als ein Asset einer Unterorganisation, das keinen Zugriff auf andere Systeme erlaubt. Die dritte Metrik ist die Discoverability, die umschreibt, wie schnell und einfach ein Asset einem Unternehmen als potenziellem Ziel zugeordnet werden kann. Befindet es sich beispielsweise direkt auf der Website oder ist es als weitgehend unbekanntes Risiko bei einer Tochterorganisation “versteckt”? Schritt 4: Priorisierung und Remediation Um das externe Cyberrisiko der von außen erreichbaren Angriffsfläche effektiv klein zu halten, ist der wichtigste Faktor eine möglichst kurze Reaktionszeit für tatsächlich kritische Risiken. Das gilt für das Erkennen, aber natürlich auch für das rechtzeitige Schließen relevanter Schwachstellen. Doch was tun, wenn das Dashboard mehr Probleme zeigt, als Personal zu Verfügung steht, um sie zu beheben? Dann müssen die Schwachstellen sinnvoll priorisiert werden, um das Gesamtrisiko für erfolgreiche Angriffe so schnell und so stark wie möglich zu minimieren. So ist beispielsweise der direkte ungeschützte Zugriff von außen auf eine Kundendatenbank ohne Authentisierung in der Regel sicherlich deutlich kritischer als eine bisher nur theoretisch ausnutzbare Schwachstelle auf einer IP-Kamera. Es geht für das Security Operations Team also nicht in erster Linie darum, schnell möglichst viele Lücken zu schließen, sondern die relevantesten. Und oft bergen lediglich circa zehn Lücken den größten Teil – und zwar bis zu 90 Prozent – des gesamten externen Cyberrisikos eines Unternehmens in der aktuellen Woche. Ist die Remediation abgeschlossen, sollte die Wirksamkeit der Maßnahmen, bestenfalls automatisiert, von außen revalidiert werden. Ein Fallbeispiel: Fatales Change Management Die Vorteile des EASM-Konzepts lassen sich an einem Fallbeispiel illustrieren: Um Anfragen nach dem “Recht auf Vergessen” effizient bearbeiten zu können, muss ein E-Commerce-Händler umfangreiche Code-Änderungen umsetzen. Aufgrund des hohen Programmieraufwands bekommt das interne Team Unterstützung von externen Entwicklern. Damit die Bereitstellung der Infrastruktur für die externen Kolleginnen und Kollegen möglichst unkompliziert und gleichzeitig Compliance-konform ablaufen kann, richtet der Vertragspartner einen Jenkins-Server ein. Einige Tage später wird eine Firewall-Änderungsanforderung in dem Subnetz verarbeitet, in dem der Jenkins-Server bereitgestellt wurde. Was der zuständige Entwickler allerdings nicht realisiert: Diese Änderung macht den Jenkins-Server über das Internet zugänglich. Da er jedoch nicht durch die Unternehmens-IT verwaltet wird, gibt es auch keine Sicherheitsüberwachung. Der Server ist also nicht gehärtet und das Standardkennwort wurde nicht geändert. Ein Angreifer entdeckt den weitgehend ungeschützten Server, schafft es, sich anzumelden und über ein Groovy-Skript die Shell in der Jenkins-Skriptkonsole auszuführen. Anschließend verschafft er sich Root-Rechte und findet private SSH-Schlüssel für die Bereitstellung von Assets sowie API-Schlüssel für Quellcode-Repositories. Diese verwendet er für den Zugriff auf die Code-Repositories und stößt so auf AWS-API-Schlüssel. Mit diesem kompromittiert er mehrere Terabyte an Daten, die in S3-Buckets gespeichert sind, darunter auch personenbezogene Informationen (PII) von Kunden. Was als Projekt zur Umsetzung von Datenschutzvorschriften begann, führt am Ende zu einer Offenlegung genau der Daten, die ursprünglich besser geschützt werden sollten. Um einen solchen erfolgreichen Angriff in Zukunft zu verhindern, denken die Verantwortlichen darüber nach, die bisher jährlichen Penetrationstests ab sofort in jedem Quartal durchzuführen. Dieser gut gemeinte, letztlich aber leider wenig zielführende Vorschlag zeigt das häufigste Problem in Bezug auf EASM, nämlich mangelndes Risikobewusstsein. Wer die externe Angriffsfläche effektiv schützen und das externe Cyberrisiko minimieren möchte, muss öffentlich sichtbare Cloud Assets und Anwendungen eines Unternehmens inklusive aller Unterorganisationen kontinuierlich – und aus Effizienz- und Kostengründen möglichst automatisiert – prüfen und überwachen. Dann fällt die oben beschriebene Konfigurationsänderung und das implementierte Standardpasswort für den von außen zugänglichen Jenkins-Server direkt auf und in den internen Systemen wird automatisch eine entsprechende Risikomeldung ausgelöst. Eine gute EASM-Lösung liefert darüber hinaus auch wichtige Informationen zu effektiven Präventionsmaßnahmen, um ähnliche Vorfälle künftig zu verhindern. Denn unter Umständen kennt der zuständige Sicherheitsanalyst Jenkins nicht, fordert deshalb “nur” ein neues Passwort an und betrachtet den Vorgang und das Risiko damit als erledigt. Erst wenn er darüber informiert wird, dass Jenkins-Server niemals über das Internet erreichbar sein sollten, und es sich grundsätzlich empfiehlt, die Standard-Anmeldedaten zu ändern, lässt sich das externe Cyberrisiko verringern. Zudem kann das System den Analysten warnen, dass Angreifer möglicherweise bereits eingebrochen sind und eine gründlichere Untersuchung angebracht wäre. Darüber hinaus lassen sich mit der kontinuierlichen Überwachung durch EASM die getroffenen Maßnahmen validieren – als wirksam oder eben nicht. Sicherer mit stetigem und zentralem EASM Das ist nur ein Beispiel, das zeigt: Für einen effektiven Schutz der aus dem Internet erreichbaren Angriffsfläche reichen Einzelmaßnahmen wie halbjährlich durchgeführte Penetrationstest oder Vulnerability-Scans nicht aus. Auch der Einsatz eines “Flickenteppichs” aus Punktlösungen und -prozessen wiegt IT-Verantwortliche oft in falscher Sicherheit, denn nach offiziellen Vorgaben ist alles in Ordnung – aber nur, weil kritische Assets und Sicherheitslücken durchs Raster fallen können. Ein effektives EASM geht über reine Compliance-Standards hinaus und minimiert das externe Cyberrisiko auf Basis zweier Aspekte. Der erste ist Kontinuität: Es muss regelmäßig sichergestellt werden, dass alle externen Assets korrekt erfasst und hinsichtlich ihres Risikostatus auf dem neuesten Stand sind. Der zweite ist Einheitlichkeit: Wer bei einzelnen Teilschritten wie Erkennung und Klassifizierung bis hin zur Risikobewertung, -priorisierung und Remediation mit Insellösungen “nachbessert”, optimiert damit nicht zwangsläufig auch den Gesamtprozess. Eine effektive Verringerung des externen Cyberrisikos kann über eine zentrale Plattformlösung für EASM erfolgen, die alle vier Phasen abdeckt. Sie identifiziert und analysiert – beispielsweise in einem wöchentlichen Turnus – automatisch alle relevanten Assets und minimiert so die Wahrscheinlichkeit, dass wichtige Risiken übersehen werden. Anschließend gibt sie IT-Verantwortlichen konkrete Handlungsempfehlungen, indem sie kontinuierlich aufzeigt, welche die für das Unternehmen derzeit jeweils wichtigsten Sicherheitslücken sind, die umgehend geschlossen werden müssen. Damit das effektiv und binnen kürzester Zeit geschehen kann, sollte sich die EASM-Lösung zudem über entsprechende Schnittstellen in bestehende Prozesse und Systeme integrieren lassen. Das ermöglicht eine nahtlose Weitergabe aller relevanten Informationen und sorgt dafür, dass die kritischen Risiken schneller intern verstanden und Remediation-Maßnahmen zeitnah getroffen werden können. Am Ende kommt es jedoch auch immer auf die Verantwortlichen im Unternehmen an. Denn eine technische Lösung kann zwar eine schnelle MTTD (Medium Time To Detection) garantieren und relevante Informationen bereitstellen, die letztlich relevante MTTR (Medium Time To Remediation) hängt allerdings von der Reaktionsschnelligkeit der zuständigen Abteilungen ab. Wenn Technologie und Mensch “Hand in Hand” arbeiten, sind die oben genannten vier Schritte für Unternehmen ein probater Weg, um das externe Cyberrisiko zu minimieren. (jm) View the full article

dotshock | shutterstock.com Angenommen, Ihr Unternehmen wird von Cyberkriminellen angegriffen, kommt dabei aber mit einem blauen Auge davon, weil die Attacke zwar spät, aber noch rechtzeitig entdeckt und abgewehrt werden konnte – ohne größeren Business Impact. Jetzt einfach wie bisher weiterzumachen und die Sache zu vergessen, wäre allerdings kontraproduktiv. Schließlich haben die Angreifer einen Weg gefunden, Ihre Systeme zu kompromittieren und dabei Abwehrmaßnahmen zu umgehen. Deshalb ist an dieser Stelle ein Post-Incident Review essenziell: Ein strukturierter Prozess, in dessen Rahmen das Unternehmen analysiert, was gut gelaufen ist, was nicht, und wie die Performance in Zukunft verbessert werden kann. Das klingt erst einmal simpel – allerdings gilt es einige wichtige Dinge zu beachten, um eine robuste Post-Incident-Review-Strategie zu entwickeln. Welche das sind, haben wir im Gespräch mit verschiedenen Sicherheitsexperten herausgearbeitet. 1. Zeitnah handeln Nicht nur wenn es um die Analyse geht, ist Timing bei Security Incidents von entscheidender Bedeutung. Lassen Sie erst einmal Wochen oder Monate ins Land ziehen, bevor Sie ein Post-Incident Review anberaumen, steigt das Risiko, dass wichtige Elemente in Vergessenheit geraten – und Sicherheitsentscheider und ihre Teams sich kein vollständiges Bild von dem Angriff mehr machen können. David Taylor, Managing Director bei der IT-Beratung Protiviti, rät deshalb dazu, möglichst zeitnah tätig zu werden: “Ein Review kurz nach einem Incident gewährleistet, dass alle Details noch frisch in den Köpfen sind und vermittelt zudem ein Gefühl von Dringlichkeit”. Zudem könnten die Review-Beteiligten auf diese Weise auch eine akkurate Timeline der Ereignisse erarbeiten, so der Chefberater. Wie diese Timeline ausgestaltet werden sollte, weiß Heather Clauson Haughian, Mitbegründerin und geschäftsführende Partnerin der auf Datenschutz spezialisierten Anwaltskanzlei CM Law: “Zunächst gilt es, festzuhalten, was genau passiert ist – von den ersten Anzeichen eines Problems bis hin zu seiner Bewältigung.” Das unterstütze alle Beteiligten dabei, nachzuvollziehen, an welchen Stellen es zu Verzögerungen oder Fehlern gekommen ist – und an welchen nicht. “Es geht im Grunde darum, den Vorfall in eine verständliche ‚Story‘ zu gießen und daraus entsprechende Lehren zu ziehen”, erklärt die Rechtsexpertin. 2. Ursachenanalyse fahren Pflichtbestandteil eines Post-Incident Reviews ist zudem eine Ursachenanalyse (auch Root Cause Analysis) – zumindest wenn Ihnen daran gelegen ist, künftige Incidents zu verhindern. Dieser Überzeugung ist auch Michael Brown, Field CISO beim IT-Dienstleister Presidio: “Die Grundursache eines Vorfalls zu identifizieren, ist essenziell. Die Teams müssen herausfinden, ob es sich dabei um eine technische Schwachstelle, menschliches Versagen oder Prozess- beziehungsweise Technologielücken handelt. Nur so lässt sich sicherstellen, dass nicht nur Symptome behandelt werden.” 3. Lücken identifizieren Ein Post-Incident Review sollte darüber hinaus auch beinhalten, die Performance des Sicherheitsteams mit Blick auf etablierte Prozesse (etwa den Incident-Response-Plan) zu evaluieren. Das ist laut Protiviti-Manager Taylor unerlässlich, um die Team-Fähigkeiten sukzessive zu verbessern: “Es kann wertvolle Informationen für innovative Optimierungen liefern, Schulungslücken identifizieren und Ineffizienzen in der Reaktionsphase beseitigen.” Presidio geht diesbezüglich mit gutem Beispiel voran, wie Field CISO Brown verrät: “Im Rahmen unserer Post-Incident Reviews bewerten wir die Leistung unseres Incident-Response-Teams in unterschiedlichen Bereichen – etwa Detection, Reaktionszeit, Kommunikation, Koordination oder Prozesstreue.” 4. Business Impact analysieren Die Auswirkungen eines Sicherheitsvorfalls vollumfänglich zu durchdringen, ist eine vielschichtige Angelegenheit, die sowohl quantitative als auch qualitative Analysen umfassen sollte. Ersteres sollte laut Sicherheitsentscheider Brown beispielsweise Aspekte wie finanzielle Einbußen, verlorene Marktanteile oder Kundenaufträge beinhalten. Zweiteres sich hingegen mit Fragen befassen wie: Wurde die Business Continuity nachhaltig beeinträchtigt? Wurden die zuständigen Behörden rechtzeitig informiert? Sind Reputationsschäden entstanden? 5. Kontext erfassen Ein weiterer Schlüsselfaktor für Post-Incident-Analysen ist außerdem der Kontext des Sicherheitsvorfalls. Ihn zu erfassen, ist entscheidend, wenn es darum geht, eine Timeline für den Incident aufzusetzen, aus der alle Beteiligten lernen können. “Allzu oft wird bei Nachbesprechungen der Kontext, in dem Entscheidungen getroffen wurden, übersprungen”, kritisiert Security-Forscher Eireann Leverett und ergänzt: “Dokumentieren Sie den Vorfall so, wie er sich entwickelt hat – nicht nur das Ergebnis. Incidents entwickeln sich im Zeitverlauf – und das Team, das diesen bearbeitet, kann selten vorab auf sämtliche Fakten zugreifen.” Jede neue Entdeckung – etwa mit Blick auf das Einfallstor für den Angriff, seinen Scope oder die von den Angreifern verwendeten Tools, könnten die Untersuchungsziele des Teams verändern, so Leverett: “Was als Containment-Vorhaben beginnt, kann schnell zum umfänglichen Recovery-Projekt ausarten. Nur wenn Sie tracken, wann und warum Veränderungen stattgefunden haben, ist später auch nachvollziehbar, welche Maßnahmen ergriffen wurden.” 6. Abteilungsübergreifend kollaborieren Ein Post-Incident Review zu leiten, ist Sache des CISO – oder anderer Security- oder IT-Führungskräfte. Allerdings ist es empfehlenswert, auch Personen aus anderen Abteilungen einzubinden, die potenziell Insights beitragen können. So empfiehlt etwa Sicherheitsexperte Leverett, das Post-Incident-Team um Kollegen aus den Bereichen Governance, Recht und Risikomanagement zu erweitern: “Diese können die Grundursache des Incidents möglicherweise mit allgemeinen, breiter angelegten Richtlinienlücken in Verbindung bringen.” Sinnvoll ist nach Meinung von Leverett außerdem, die Finanz- und Personalabteilung einzubinden, sowie – je nach Art und Schwere des Vorfalls – auch Vorstandsmitglieder. Letzteres signalisiere eine strategische Priorisierung und unterstütze dabei, technische Erkenntnisse mit Risiko-Diskussionen auf Governance-Ebene zu verknüpfen, ist der Experte überzeugt. “Wichtig ist dabei, dass alle Beteiligten gleichberechtigt zu Wort kommen – unabhängig von ihrer Position oder Rolle”, ergänzt Protiviti-Mann Taylor. Das trage nicht nur dazu bei, Security-Vorfälle besser zu durchdringen, sondern etabliere auch ein kooperatives Umfeld. 7. Schuldzuweisungen vermeiden Im Rahmen eines Post-Incident Reviews “Fingerpointing” zu betreiben, ist mit hoher Wahrscheinlichkeit nicht produktiv. Deshalb empfiehlt auch IT-Anwältin Haughian, den Fokus darauf zu legen, zu lernen und zu optimieren: “Schuldzuweisungen bringen Sie nicht weiter. Es gilt, den tatsächlichen Ablauf der Ereignisse aufzudecken, Entscheidungsprozesse zu verstehen und alle Faktoren zu identifizieren, die zu Fehlern beigetragen haben. Dieser Ansatz kann dabei helfen, künftige strategische Entscheidungen in Zusammenhang mit Tools, Schulungen und Richtlinien zu treffen.” Auch Leverett hält nichts von einer Kultur der Schuldzuweisung: “Es geht nicht darum, ob ein bestimmtes Individuum die richtige Entscheidung getroffen hat oder nicht. Vielmehr gilt es Fragen zu klären wie: ‚War das Team unter den gegebenen Umständen in der Lage, gute Entscheidungen zu treffen?‘ Oder: ‚Hätten eine bessere Dokumentation, andere Tools oder mehr Budget für schnellere und bessere Ergebnisse gesorgt?‘” 8. Aktiv werden Sämtliche Erkenntnisse, die im Rahmen eines Post-Incident Reviews gewonnen werden, sind relativ nutzlos, wenn im Nachgang nichts passiert. Soll heißen: Den Erkenntnissen müssen konkrete Maßnahmen folgen. Um das bestmöglich umzusetzen, empfiehlt Rechtsexpertin Haughian, schriftlich genau festzuhalten, an welchen Stellen optimiert werden muss, wann das geschehen soll und wer dafür verantwortlich zeichnet: “Diese Verbesserungen können etwa Softwareaktualisierungen, Richtlinienänderungen oder neue Schulungsinitiativen sein. Unabhängig davon macht diese Nachbereitung ein Post-Incident Review erst wirklich nützlich. Bleibt sie aus, entfallen damit auch umsetzbare Empfehlungen – und das Ganze ist nicht mehr als eine akademische Übung”, hält die Datenschutzexpertin fest. (fm) Sie wollen weitere interessante Beiträge rund um das Thema IT-Sicherheit lesen? Unser kostenloser Newsletter liefert Ihnen alles, was Sicherheitsentscheider und -experten wissen sollten, direkt in Ihre Inbox. View the full article

dotshock | shutterstock.com Angenommen, Ihr Unternehmen wird von Cyberkriminellen angegriffen, kommt dabei aber mit einem blauen Auge davon, weil die Attacke zwar spät, aber noch rechtzeitig entdeckt und abgewehrt werden konnte – ohne größeren Business Impact. Jetzt einfach wie bisher weiterzumachen und die Sache zu vergessen, wäre allerdings kontraproduktiv. Schließlich haben die Angreifer einen Weg gefunden, Ihre Systeme zu kompromittieren und dabei Abwehrmaßnahmen zu umgehen. Deshalb ist an dieser Stelle ein Post-Incident Review essenziell: Ein strukturierter Prozess, in dessen Rahmen das Unternehmen analysiert, was gut gelaufen ist, was nicht, und wie die Performance in Zukunft verbessert werden kann. Das klingt erst einmal simpel – allerdings gilt es einige wichtige Dinge zu beachten, um eine robuste Post-Incident-Review-Strategie zu entwickeln. Welche das sind, haben wir im Gespräch mit verschiedenen Sicherheitsexperten herausgearbeitet. 1. Zeitnah handeln Nicht nur wenn es um die Analyse geht, ist Timing bei Security Incidents von entscheidender Bedeutung. Lassen Sie erst einmal Wochen oder Monate ins Land ziehen, bevor Sie ein Post-Incident Review anberaumen, steigt das Risiko, dass wichtige Elemente in Vergessenheit geraten – und Sicherheitsentscheider und ihre Teams sich kein vollständiges Bild von dem Angriff mehr machen können. David Taylor, Managing Director bei der IT-Beratung Protiviti, rät deshalb dazu, möglichst zeitnah tätig zu werden: “Ein Review kurz nach einem Incident gewährleistet, dass alle Details noch frisch in den Köpfen sind und vermittelt zudem ein Gefühl von Dringlichkeit”. Zudem könnten die Review-Beteiligten auf diese Weise auch eine akkurate Timeline der Ereignisse erarbeiten, so der Chefberater. Wie diese Timeline ausgestaltet werden sollte, weiß Heather Clauson Haughian, Mitbegründerin und geschäftsführende Partnerin der auf Datenschutz spezialisierten Anwaltskanzlei CM Law: “Zunächst gilt es, festzuhalten, was genau passiert ist – von den ersten Anzeichen eines Problems bis hin zu seiner Bewältigung.” Das unterstütze alle Beteiligten dabei, nachzuvollziehen, an welchen Stellen es zu Verzögerungen oder Fehlern gekommen ist – und an welchen nicht. “Es geht im Grunde darum, den Vorfall in eine verständliche ‚Story‘ zu gießen und daraus entsprechende Lehren zu ziehen”, erklärt die Rechtsexpertin. 2. Ursachenanalyse fahren Pflichtbestandteil eines Post-Incident Reviews ist zudem eine Ursachenanalyse (auch Root Cause Analysis) – zumindest wenn Ihnen daran gelegen ist, künftige Incidents zu verhindern. Dieser Überzeugung ist auch Michael Brown, Field CISO beim IT-Dienstleister Presidio: “Die Grundursache eines Vorfalls zu identifizieren, ist essenziell. Die Teams müssen herausfinden, ob es sich dabei um eine technische Schwachstelle, menschliches Versagen oder Prozess- beziehungsweise Technologielücken handelt. Nur so lässt sich sicherstellen, dass nicht nur Symptome behandelt werden.” 3. Lücken identifizieren Ein Post-Incident Review sollte darüber hinaus auch beinhalten, die Performance des Sicherheitsteams mit Blick auf etablierte Prozesse (etwa den Incident-Response-Plan) zu evaluieren. Das ist laut Protiviti-Manager Taylor unerlässlich, um die Team-Fähigkeiten sukzessive zu verbessern: “Es kann wertvolle Informationen für innovative Optimierungen liefern, Schulungslücken identifizieren und Ineffizienzen in der Reaktionsphase beseitigen.” Presidio geht diesbezüglich mit gutem Beispiel voran, wie Field CISO Brown verrät: “Im Rahmen unserer Post-Incident Reviews bewerten wir die Leistung unseres Incident-Response-Teams in unterschiedlichen Bereichen – etwa Detection, Reaktionszeit, Kommunikation, Koordination oder Prozesstreue.” 4. Business Impact analysieren Die Auswirkungen eines Sicherheitsvorfalls vollumfänglich zu durchdringen, ist eine vielschichtige Angelegenheit, die sowohl quantitative als auch qualitative Analysen umfassen sollte. Ersteres sollte laut Sicherheitsentscheider Brown beispielsweise Aspekte wie finanzielle Einbußen, verlorene Marktanteile oder Kundenaufträge beinhalten. Zweiteres sich hingegen mit Fragen befassen wie: Wurde die Business Continuity nachhaltig beeinträchtigt? Wurden die zuständigen Behörden rechtzeitig informiert? Sind Reputationsschäden entstanden? 5. Kontext erfassen Ein weiterer Schlüsselfaktor für Post-Incident-Analysen ist außerdem der Kontext des Sicherheitsvorfalls. Ihn zu erfassen, ist entscheidend, wenn es darum geht, eine Timeline für den Incident aufzusetzen, aus der alle Beteiligten lernen können. “Allzu oft wird bei Nachbesprechungen der Kontext, in dem Entscheidungen getroffen wurden, übersprungen”, kritisiert Security-Forscher Eireann Leverett und ergänzt: “Dokumentieren Sie den Vorfall so, wie er sich entwickelt hat – nicht nur das Ergebnis. Incidents entwickeln sich im Zeitverlauf – und das Team, das diesen bearbeitet, kann selten vorab auf sämtliche Fakten zugreifen.” Jede neue Entdeckung – etwa mit Blick auf das Einfallstor für den Angriff, seinen Scope oder die von den Angreifern verwendeten Tools, könnten die Untersuchungsziele des Teams verändern, so Leverett: “Was als Containment-Vorhaben beginnt, kann schnell zum umfänglichen Recovery-Projekt ausarten. Nur wenn Sie tracken, wann und warum Veränderungen stattgefunden haben, ist später auch nachvollziehbar, welche Maßnahmen ergriffen wurden.” 6. Abteilungsübergreifend kollaborieren Ein Post-Incident Review zu leiten, ist Sache des CISO – oder anderer Security- oder IT-Führungskräfte. Allerdings ist es empfehlenswert, auch Personen aus anderen Abteilungen einzubinden, die potenziell Insights beitragen können. So empfiehlt etwa Sicherheitsexperte Leverett, das Post-Incident-Team um Kollegen aus den Bereichen Governance, Recht und Risikomanagement zu erweitern: “Diese können die Grundursache des Incidents möglicherweise mit allgemeinen, breiter angelegten Richtlinienlücken in Verbindung bringen.” Sinnvoll ist nach Meinung von Leverett außerdem, die Finanz- und Personalabteilung einzubinden, sowie – je nach Art und Schwere des Vorfalls – auch Vorstandsmitglieder. Letzteres signalisiere eine strategische Priorisierung und unterstütze dabei, technische Erkenntnisse mit Risiko-Diskussionen auf Governance-Ebene zu verknüpfen, ist der Experte überzeugt. “Wichtig ist dabei, dass alle Beteiligten gleichberechtigt zu Wort kommen – unabhängig von ihrer Position oder Rolle”, ergänzt Protiviti-Mann Taylor. Das trage nicht nur dazu bei, Security-Vorfälle besser zu durchdringen, sondern etabliere auch ein kooperatives Umfeld. 7. Schuldzuweisungen vermeiden Im Rahmen eines Post-Incident Reviews “Fingerpointing” zu betreiben, ist mit hoher Wahrscheinlichkeit nicht produktiv. Deshalb empfiehlt auch IT-Anwältin Haughian, den Fokus darauf zu legen, zu lernen und zu optimieren: “Schuldzuweisungen bringen Sie nicht weiter. Es gilt, den tatsächlichen Ablauf der Ereignisse aufzudecken, Entscheidungsprozesse zu verstehen und alle Faktoren zu identifizieren, die zu Fehlern beigetragen haben. Dieser Ansatz kann dabei helfen, künftige strategische Entscheidungen in Zusammenhang mit Tools, Schulungen und Richtlinien zu treffen.” Auch Leverett hält nichts von einer Kultur der Schuldzuweisung: “Es geht nicht darum, ob ein bestimmtes Individuum die richtige Entscheidung getroffen hat oder nicht. Vielmehr gilt es Fragen zu klären wie: ‚War das Team unter den gegebenen Umständen in der Lage, gute Entscheidungen zu treffen?‘ Oder: ‚Hätten eine bessere Dokumentation, andere Tools oder mehr Budget für schnellere und bessere Ergebnisse gesorgt?‘” 8. Aktiv werden Sämtliche Erkenntnisse, die im Rahmen eines Post-Incident Reviews gewonnen werden, sind relativ nutzlos, wenn im Nachgang nichts passiert. Soll heißen: Den Erkenntnissen müssen konkrete Maßnahmen folgen. Um das bestmöglich umzusetzen, empfiehlt Rechtsexpertin Haughian, schriftlich genau festzuhalten, an welchen Stellen optimiert werden muss, wann das geschehen soll und wer dafür verantwortlich zeichnet: “Diese Verbesserungen können etwa Softwareaktualisierungen, Richtlinienänderungen oder neue Schulungsinitiativen sein. Unabhängig davon macht diese Nachbereitung ein Post-Incident Review erst wirklich nützlich. Bleibt sie aus, entfallen damit auch umsetzbare Empfehlungen – und das Ganze ist nicht mehr als eine akademische Übung”, hält die Datenschutzexpertin fest. (fm) Sie wollen weitere interessante Beiträge rund um das Thema IT-Sicherheit lesen? Unser kostenloser Newsletter liefert Ihnen alles, was Sicherheitsentscheider und -experten wissen sollten, direkt in Ihre Inbox. View the full article

Facing ever-mounting cyberthreats, enterprises are increasingly turning to cyber insurance to address the potentially severe financial damage a successful attack can inflict. Unfortunately, cyber insurance presents its own risks, particularly for cybersecurity leaders who tend to pay more attention to evolving threats than insurance fine print. Sharon Polsky, president of the Privacy and Access Council of Canada, an organization dedicated to the development of access-to-information, information privacy, and the data protection profession, notes that several common cyber insurance omissions and loopholes can lead to a sense of complacency that can limit or even nullify a policy’s perceived benefits. Is your enterprise risking its financial foundation with a cyber insurance policy that contains potentially devastating trap doors? Check your policy — and your assumptions about it — for these six common cyber insurance “gotchas.” 1. Assuming cyber insurance covers all risks In reality, many insurance policies offer narrow definitions, hidden exclusions, or strict conditions that can leave organizations exposed after a breach. “It’s not like an auto liability policy, where every policy provides the same coverage,” says William J. Lindsay III, founder of insurance broker Tri Pack Insurance Services. “With cyber liability, the terms and conditions will differ from one insurance policy to another.” Before committing to a specific insurer, Lindsay recommends consulting an attorney with experience in cyber insurance contracts. “A policy is a legal document with complex definitions,” he notes. “An attorney can flag ambiguous terms, hidden carve-outs, or obligations that could create disputes at claim time,” Lindsay says. “Once the policy is purchased, and a loss occurs, no changes can be made to fill the coverage gap.” 2. Misinterpreting the fine print about coverage, interruptions, or threats It’s hardly surprising, but important to remember, that the language contained in cybersecurity policies generally favors the insurer, not the insured. “Businesses often misinterpret the language from their perspective and overlook the risks that the very language of the policy creates,” Polsky warns. “For example, business interruption coverage that’s limited to interruptions caused by ‘system failures’ might exclude cyber incidents, such as ransomware.” Meanwhile, “threats coverage” might only refer to threats known at the time the policy was issued, leaving new threat types that arrive during the coverage term uninsured. “Problematically, terminology used in insurance policies — such as threats — are often not defined, leaving the insured enterprise to anticipate that their own interpretation of the term is what is meant,” Polsky explains. “Unfortunately, the presence or absence of a comma, or a definition, is the stuff of litigation.” 3. Overlooking hidden caps on specific loss types You may believe your policy will cover all cyberattack losses, yet a look at the fine print may revealed that it’s riddled with exclusions and warranties that can’t be realistically met, particularly in areas such as social engineering, ransomware, and business interruption. A policy with hidden caps creates a false sense of security, says Max Coupland, CEO of Insuranceopedia, a service that enables users to compare insurance quotes. You budget for full cyber coverage, then a claim is denied or dramatically reduced because the loss fell into a sub-limit — a limitation placed on a policy that reduces the amount of coverage available for a specific type of loss, he explains. To prevent hidden caps, Coupland advises running a table-top exercise with both your broker and security team. “For each scenario ask, ‘Do we have coverage?’ At what limit? Are there any exclusions that could be triggered?’” Then convert the final document into a one-page coverage checklist before committing to the policy. 4. Not aligning your security strategy with the policy’s fine print If your security isn’t up to the policy’s standards — and that includes things like multi-factor authentication, regular backups, and endpoint detection — your claim can be denied outright, warns Matt Mayo, president and CEO of managed service provider Diamond IT. Many enterprises believe they’re fully secure, yet when they file a claim the insurer points to the fine print about security measures you didn’t know were required, Mayo says. “Now you’re stuck with cleanup costs, legal fees, and potential lawsuits — all without support from your insurance provider.” The best way to avoid this trap is to align your cybersecurity posture precisely with the requirements spelled out in the policy. “This means reviewing your coverage before an incident happens,” Mayo says. Also consider using a knowledgeable consultant who can help implement and document the required controls. 5. Falling into the retroactive date trap The retroactive date clause can be the biggest cyber insurance trap, warns Paul Pioselli, founder and CEO of cybersecurity services firm Solace. “This clause voids coverage for any incident that began before the policy’s start date, even if it’s discovered months later. Given that hackers can remain undetected in a network for over 200 days on average, this loophole can, in some cases, render a brand-new policy worthless,” he says. Pioselli says that whenever possible, demand full prior acts coverage. “This removes the retroactive date entirely,” he states. “If the insurer refuses, negotiate to push the date back as far as possible — ideally to your company’s founding date.” Whenever possible, Pioselli advises conducting a comprehensive cybersecurity risk assessment before shopping for a policy. “You must understand your specific vulnerabilities and potential financial impact first, then buy a policy with limits and coverages that match that reality.” 6. Misunderstanding first-party versus third-party coverage Perhaps the biggest mistake an insurance seeker can make is failing to understand the difference between first-party coverage and third-party coverage, and therefore failing to acquire a policy that includes both, says Dylan Tate, a representative of insurance marketing firm Smart Financial. First-party cyber insurance refers to coverage for the business’s direct losses and expenses after a cyberattack, such as lost revenue, public relations support, and costs related to the recovery of lost data. Meanwhile, third-party cyber insurance is liability coverage that can step in to prevent a lawsuit or handle the costs associated if a business is sued by customers affected by a data breach. It may also cover upfront payments to consumers, settlements or fines, and damages ordered by a judge. If an enterprise’s cyber insurance policy doesn’t include both first- and third-party coverage, your organization may be underinsured, potentially resulting in significant — and unnecessary — out-of-pocket costs, depending on the types of losses they experience in the event of a cybercrime, Tate explains. Many cyber insurance policies automatically include both first-party and third-party coverage, but some insurance companies only offer them separately, Tate warns. “The Hartford, for example, sells multiple cyber insurance products, some of which bundle both coverage types together and some of which include only one or the other, which may be confusing for enterprise insurance shoppers.” Asking questions is the best way to ensure a cyber insurance policy meets all of your coverage needs before purchasing it, Tate advises. Going over known cybersecurity risks and potential claim scenarios can help an enterprise gain a fuller picture of how a given cyber insurance company can support them if they suffer a cyberattack. “Although potentially tedious, it can be helpful to engage in exhaustive conversations up front to avoid unexpected out-of-pocket costs later on in the event of a claim,” he says. View the full article

Every day has the potential to be a bad day for a CSO. However, the second Tuesday of each month – Patch Tuesday – is almost guaranteed to be one of those days, though with any luck it’s merely troublesome, not catastrophic. In 2025, however, some of them gave CSOs heartburn: Microsoft issued mitigations for 1,246 CVEs, including 158 rated critical. Forty-one of them were zero days, and researchers at Tenable estimate that elevation of privilege vulnerabilities accounted for about 38.3% of all Patch Tuesday vulnerabilities in 2025, followed by remote code execution flaws at about 30%. We asked security experts which of those bugs worried them the most. Here’s how they responded. New tactics and AI change the game More vulnerabilities were spotted this year than in 2024, says Gene Moody, field CTO at patching automation provider Action1, an upward trend that’s been ongoing for the past five years. One thing, however, is different: Thanks to the use of AI by threat actors, as well as cunning new tactics, security teams have less time than ever to install patches. “Attack groups will do things like hold their first attack until the day after Patch Tuesday, because it puts Microsoft on the spot: They would have to release a massive out-of-band update or wait until the next Patch Tuesday,” he said. “So if you are waiting for 30 day or quarterly cycles to patch, you are behind the curve. You are spending weeks to potentially months unprotected, and [with] no excuse to be so.” “You have to patch what needs to be patched, not just what can be patched,” Moody added. “You don’t have 30 days to do testing, plan down time. You no longer have the luxury of saying, ‘We’re going to push all of this out at once.’ You need to say, ‘I’m going to knock out the ones that are going to kill me first,’ and if you automate this [initial batch], you have more man hours to analyze and scrutinize the rest.” Take, for example, one of the nastiest holes found this year, ToolShell (CVE-2025-53770), which is actually two chained vulnerabilities in on-premises SharePoint 2016/2019 servers. It allows an unauthenticated attacker the ability to execute remote code. It holds a 9.8 CVSS score, and exploiting it has become a favorite of initial access brokers. Scott Caveza, senior staff research engineer at Tenable, described its possible exploitation as a “nightmare scenario … that CSOs will want to avoid at all costs.” But, Moody pointed out, today most large organizations access SharePoint from the cloud. So its CVSS score is only important to those with SharePoint servers in-house. Watch those lower-scored vulnerabilities Several lower scored vulnerabilities could have caused serious damage if not quickly addressed, Moody said. These included: CVE 2025 24993, a Windows NTFS memory corruption issue affecting nearly every Windows system by default, enabled local code execution by an unauthorized attacker; CVE 2025 24990, a privilege escalation flaw in the Agere modem driver shipped with Windows allowed attackers to elevate to SYSTEM with little effort, and without an actual Agere modem being in use, turning limited access into total control; CVE 2025 62221, a use-after-free bug in the Windows cloud files mini filter driver, was actively exploited and provided a dependable path to SYSTEM once code execution was achieved. While it required initial access, Moody points out it was a very short path to total control that was easy to execute, with low skill requirements; CVE 2025 53779, the Kerberos BadSuccessor privilege escalation, threatened domain level compromise by allowing any domain authenticated account to escalate privileges by spoofing tokens within Active Directory environments. In a blog, Action1 director of vulnerability research Jack Bicer called this hole “a gift to ransomware operators … providing an express elevator to domain admin.” Caveza also drew attention to two escalation of privilege flaws, CVE-2025-24983 in the Windows kernel, and CVE-2025-29824, in the Windows common log file system driver, because both were used with the PipeMagic backdoor to spread ransomware. He also noted CVE-2025-26633, a security feature bypass vulnerability affecting the Microsoft Management Console (MMC). This was a zero day vulnerability abused by multiple threat actors to deploy malware, including the MSC EvilTwin trojan loader, and has been used with multiple malware variants, including backdoors and infostealer malware; CVE-2025-33053, a remote code execution vulnerability affecting Internet Shortcut Files. Check Point Research found this zero-day flaw to have been abused by an APT known as Stealth Falcon, which used the flaw to distribute Horus Agent malware. Look out for Preview Pane attacks Tyler Reguly, associate director for research and development at Fortra, said CSOs should think about defending against Preview Pane attacks in Windows and Office. Threat actors could have exploited these flaws to run malicious code when an employee previewed a specially crafted file or email. One example was CVE-2025-30377, which researchers at ZeroPath called “one of the most dangerous vulnerabilities discovered in Microsoft Office” when it was revealed in May. These kinds of attack “represent some of the biggest risks to organizations,” said Reguly. “Those silent exploits that run as soon as an email is viewed are a potential risk, since most people make use of the Preview Pane. While there may be bigger vulnerabilities that were more impactful that I’m sure others will call attention to, this is the class of vulnerability that I would want to call out and ensure that others are watching for.” CVSS score ‘only part of a puzzle’ Moody urged CSOs to stop thinking about CVSS as a score and start thinking of it as a means to developing a score; a CVSS score is “only part of a puzzle.” Most CSOs don’t have the foundational understanding of how vulnerabilities relate to their specific IT environment and concerns, he pointed out. “People tend to chase CVSS [thinking] ‘9.5, bad’. Well, 9.5 is a theoretical bad. It’s a worse case scenario in a lab if you manage to pull it off – but that vulnerability may not even be expressed in your environment. Or it may be in your environment but in a benign way. “By contrast, the 6.2 may be the most critical one you need to stop right now because it’s on 10,000 forward- facing web servers.” He urged CSOs to triage vulnerabilities by using the US Cybersecurity and Infrastructure Security Agency’s (CISA) Stakeholder Specific Vulnerability Classification (SSVC) framework. View the full article

Cybersecurity ist kein Nice-to-have, sondern ein Muss. Dennoch vernachlässigen immer noch zu viele Unternehmen seine Pflege. Summit Art Creations – shutterstock.com Cybersicherheits-Frameworks sind die Richtlinien, mit denen sich Unternehmen vor Cyberangriffen schützen. Ein typisches Framework beschreibt die notwendigen Schritte, um verschiedene Cybersicherheitsrisiken zu adressieren, latente Schwachstellen aufzudecken und die digitale Verteidigung des Unternehmens allgemein zu verbessern. Jede entdeckte Sicherheitslücke zeigt an, dass umgehend Maßnahmen ergriffen werden müssen, um die Cyber-Resilienz wiederherzustellen und zu stärken. Keri Pearlson, Dozentin und leitende Wissenschaftlerin an der MIT Sloan School of Management, erklärt, dass es viele Anzeichen dafür gibt, dass ein bestehendes Cybersicherheits-Framework überarbeitet werden muss. „Wenn Ihr Cybersicherheits-Framework in den letzten zwei Monaten nicht überprüft wurde, wenn Sie es nicht dynamisch aktualisiert haben oder wenn Ihr Team KI noch nicht in Ihre Cybersicherheitsstrategie integriert hat, sollten Sie Ihr Framework überprüfen und gegebenenfalls neu erstellen.“ Hier sind Warnzeichen, die darauf hindeuten, dass es Zeit für eine dringend notwendige Überarbeitung sein könnte: 1. Ein dynamischer Prozess zur Erkennung von Veränderungen Der größte Fehler, so Pearlson, sei es, nicht zu erkennen, dass der aktuelle Plan veraltet ist oder schlichtweg nicht funktioniert. Sicherheitsvorfälle kommen vor, aber das bedeutet nicht zwangsläufig, dass die Cybersicherheitsstrategie komplett neu aufgebaut werden muss. Es zeigt jedoch, dass die überdacht und neugestaltet werden muss. Eine cyber-resiliente Organisation aufzubauen, erfordere ein Umdenken, erläutert Pearlson. Der beste Ansatz ist ihrer Ansicht nach, einen dynamischen Prozess zu implementieren, der Veränderungen im Umfeld erkennt und einen Anpassungsprozess einleitet. „Der Schlüssel liegt darin, den richtigen Erfassungs- und Reaktionsmechanismus zu haben – was wahrscheinlich eine Kombination aus Technologie und menschlichen Aktivitäten ist“, sagt sie. Zusätzlich merkt die Forscherin an, dass Technologie Veränderungen erfassen sowie Anomalien identifizieren könne, und dass Menschen beurteilen könnten, ob die Veränderung ein Risiko darstellt, das Aufmerksamkeit und Investitionen erfordert. 2. Einen erfolgreichen Cyberangriff erleben – egal, wie groß oder klein Nichts verdeutliche die Schwächen eines Cybersecurity-Frameworks besser als ein Sicherheitsvorfall, erläutert Steven Bucher, CSO bei Mastercard. „Ich habe selbst erlebt, wie bereits ein kleiner Vorfall veraltete Protokolle oder Lücken in der Mitarbeiterschulung aufdecken kann“, erklärt er. „Wenn Ihr Sicherheitskonzept nicht mit den sich wandelnden Bedrohungen oder den sich ändernden Geschäftsanforderungen Schritt gehalten hat, ist es Zeit für eine Überarbeitung.“ Da sich Cyberbedrohungen ständig weiterentwickeln, hilft es laut Bucher, proaktiv zu bleiben, regelmäßige Überprüfungen durchzuführen und eine Kultur des Cybersicherheitsbewusstseins zu fördern. So ließen sich Probleme erkennen, bevor sie zu Krisen führen. „Letztendlich ist ein robustes und aktuelles Sicherheitskonzept der beste Weg, Ihr Unternehmen zu schützen und Vertrauen zu erhalten.“ 3. Kontinuierliche Überwachung wird zur Herausforderung Wenn Ihr Rahmenwerk eine kontinuierliche Überwachung nicht gewährleisten oder ein proaktives Risikomanagement nicht unterstützen kann, ist es an der Zeit, es an etablierten Standards auszurichten, wie dem NIST Cybersecurity Framework. Auch die Integration branchenspezifischer Compliance-Anforderungen sollte nach Bedarf neu aufgebaut werden, erklärt Dave Floyd, Vice President Cybersecurity Sales and Service bei Hughes Network Systems. Floyd empfiehlt, beim Wiederaufbau eines Cybersicherheitsrahmens mit dem NIST-Rahmenwerk zu beginnen und dieses um branchenspezifische Compliance-Anforderungen zu ergänzen. Ein solcher Ansatz stelle sicher, dass Best Practices und regulatorische Verpflichtungen für das Gesundheitswesen, den Finanzsektor und andere Branchen umfassend berücksichtigt werden. 4. Der formale Framework-Review erfolgt nur alle paar Jahre Wenn es in den letzten drei Jahren oder länger keine wesentlichen Änderungen an Ihrem Rahmenwerk gegeben hat, ist dies ein starkes Indiz dafür, dass es veraltet sein könnte, erklärt Sandra McLeod, CISO bei Zoom. „Die Cybersicherheitslandschaft hat sich rasant weiterentwickelt, insbesondere durch den Aufstieg generativer KI. Ihr Framework sollte diese Veränderungen widerspiegeln.“ McLeod empfiehlt daher alle zwei Jahre einen vollständigen Review, ergänzt durch eine Kurzprüfung in den Jahren dazwischen. „Dies trägt dazu bei, dass das Rahmenwerk mit den sich wandelnden Bedrohungen, geschäftlichen Veränderungen und regulatorischen Anforderungen Schritt hält.“ Idealerweise sollten Sicherheitsverantwortliche ihr Framework stets im Blick behalten. Außerdem sollten sie eine Liste mit Bereichen führen, die optimiert, vereinfacht oder präzisiert werden könnten, ergänzt die CISO. „Diese informellen Erkenntnisse sollten in die Gespräche während der kurzen Überprüfungen einfließen, um die kontinuierliche Verbesserung stets im Auge zu behalten.“ 5. Sie jagen ständig Warnmeldungen hinterher, statt vorausschauend zu planen Wenn sich Ihr Unternehmen permanent in einem reaktiven statt in einem proaktiven Zustand befindet, ist es laut Nima Baiati, Executive Director und General Manager für Commercial Software and Security Solutions bei Lenovo, an der Zeit, die Vorgehensweise zu überdenken. Steckt das Unternehmen in einem Kreislauf fest, in dem ständig Warnmeldungen und Vorfälle abgearbeitet werden und Ereignisse erst im Nachhinein gemeldet werden, anstatt Bedrohungen vorherzusagen, Daten zu analysieren und strategisch zu planen? Dann sei es Zeit für eine Veränderung, rät er. „Natürlich wird es weiterhin reaktive Situationen geben, aber wenn diese den Großteil der Kapazitäten des Tagesgeschäfts beanspruchen, ist es wahrscheinlich nur eine Frage der Zeit, bis schwerwiegendere Vorfälle auftreten.“ Baiati empfiehlt, zunächst ein fundiertes Verständnis der Risikobereitschaft und der Gesamtgeschäftsstrategie des eigenen Unternehmens zu entwickeln. „Richtig umgesetzte Sicherheit kann ein Wettbewerbsvorteil sein, da sie Betriebsunterbrechungen minimiert und das Vertrauen stärkt“, erklärt er. Finanzinstitute beispielsweise hätten eine geringe Risikobereitschaft und müssten unbedingt die Integrität ihrer Daten und ihren Ruf schützen. Ihre Geschäftsstrategie und ihre Sicherheit seien eng miteinander verknüpft. Da Mitarbeitende heutzutage mobiler denn je sind, rückt das Thema Endpoint Security stärker in den Fokus der Netzwerksicherheit und muss in das Cybersicherheitskonzept integriert werden. „Um eine starke Endpunktsicherheit zu gewährleisten, sollten Unternehmen einen umfassenden, mehrschichtigen Ansatz verfolgen, der alle Aspekte ihrer digitalen Umgebung schützt – Firmware, Hardware, Software und die Lieferkette“, so Baiati. „Evaluieren Sie sowohl geräteinterne als auch Cloud-basierte KI-Anwendungen, um eine effektive Bedrohungserkennung und -abwehr in Echtzeit sicherzustellen.“ 6. KRIs und KPIs entwickeln sich negativ „Wenn Sie den Eindruck haben, dass sich wichtige Risikoindikatoren (Key Risk Indicators – KRIs) und wichtige Leistungsindikatoren (Key Performance Indicators – KPIs) sich unerwartet verschlechtern, sollten Sie Ihr Framework möglicherweise überdenken“, sagt Sameer Ansari, Leiter des Datenschutzteams bei der Wirtschaftsprüfungs-, Risiko- und Compliance-Beratung Protiviti. Organisationen, die ihr Cybersicherheits-Framework lediglich als Checkliste benutzen, um Vorschriften einzuhalten und nicht als Instrument für fundierte Risikoentscheidungen betrachten, begeben sich in Gefahr, warnt Ansari. „Unternehmen sollten ihre wichtigsten Geschäftsziele und potenziellen Risiken berücksichtigen und das Framework unter diesem Gesichtspunkt anwenden.“ Viele Cybersicherheitsverantwortliche verstrickten sich beim Aufbau oder der Aktualisierung eines Frameworks in Benchmarking und Vergleichen mit anderen Unternehmen, anstatt sich auf die Bedürfnisse ihrer Organisation zu konzentrieren, so Ansari. Noch schlimmer sei die Annahme, Quantität schlage Qualität. „Manche Sicherheitschefs versuchen, verschiedene Frameworks zu kombinieren und schaffen so ein unübersichtliches ‚Frankenstein-Framework‘, das sich nur schwer verwalten und weiterentwickeln lässt“, warnt er. 7. Sie verfolgen einen reinen Compliance-orientierten Ansatz Ein häufiger Fehler vieler Sicherheitsverantwortlicher ist laut Daniel Tobok, CEO des Incident-Response-Unternehmens Cypfer, dass ein Framework entwickelt wird, welches primär darauf ausgelegt ist, „das Audit zu bestehen“, anstatt Geschäftsziele zu verfolgen. Ein rein Compliance-orientierter Ansatz klammere oft wichtige Beiträge von Nicht-IT-Stakeholdern aus, warnt er. Das führe typischerweise zu einem Framework, das zwar gut auf dem Papier aussieht, in der Praxis aber keinen wirksamen Schutz bietet. Idealerweise sollte sich ein Cybersicherheitsrahmen kontinuierlich weiterentwickeln, wobei den Bereichen mit dem höchsten Risiko Priorität eingeräumt wird, rät Tobok. „Ein vollständiger Neuaufbau kann jedoch notwendig sein, wenn das bestehende Framework das Unternehmen nicht mehr effektiv schützt oder wenn die Kosten für inkrementelle Korrekturen den Nutzen übersteigen.“ Ein Neuaufbau sei auch unmittelbar nach grundlegenden Veränderungen im Unternehmen angezeigt, ergänzt er, beispielsweise bei neuen Geschäftsmodellen, geänderten regulatorischen Vorgaben oder erweiterten Bedrohungslandschaft. All dies könne dazu führen, dass das bestehende Framework veraltet oder unzureichend ist. (tf) View the full article

Cybersecurity ist kein Nice-to-have, sondern ein Muss. Dennoch vernachlässigen immer noch zu viele Unternehmen seine Pflege. Summit Art Creations – shutterstock.com Cybersicherheits-Frameworks sind die Richtlinien, mit denen sich Unternehmen vor Cyberangriffen schützen. Ein typisches Framework beschreibt die notwendigen Schritte, um verschiedene Cybersicherheitsrisiken zu adressieren, latente Schwachstellen aufzudecken und die digitale Verteidigung des Unternehmens allgemein zu verbessern. Jede entdeckte Sicherheitslücke zeigt an, dass umgehend Maßnahmen ergriffen werden müssen, um die Cyber-Resilienz wiederherzustellen und zu stärken. Keri Pearlson, Dozentin und leitende Wissenschaftlerin an der MIT Sloan School of Management, erklärt, dass es viele Anzeichen dafür gibt, dass ein bestehendes Cybersicherheits-Framework überarbeitet werden muss. „Wenn Ihr Cybersicherheits-Framework in den letzten zwei Monaten nicht überprüft wurde, wenn Sie es nicht dynamisch aktualisiert haben oder wenn Ihr Team KI noch nicht in Ihre Cybersicherheitsstrategie integriert hat, sollten Sie Ihr Framework überprüfen und gegebenenfalls neu erstellen.“ Hier sind Warnzeichen, die darauf hindeuten, dass es Zeit für eine dringend notwendige Überarbeitung sein könnte: 1. Ein dynamischer Prozess zur Erkennung von Veränderungen Der größte Fehler, so Pearlson, sei es, nicht zu erkennen, dass der aktuelle Plan veraltet ist oder schlichtweg nicht funktioniert. Sicherheitsvorfälle kommen vor, aber das bedeutet nicht zwangsläufig, dass die Cybersicherheitsstrategie komplett neu aufgebaut werden muss. Es zeigt jedoch, dass die überdacht und neugestaltet werden muss. Eine cyber-resiliente Organisation aufzubauen, erfordere ein Umdenken, erläutert Pearlson. Der beste Ansatz ist ihrer Ansicht nach, einen dynamischen Prozess zu implementieren, der Veränderungen im Umfeld erkennt und einen Anpassungsprozess einleitet. „Der Schlüssel liegt darin, den richtigen Erfassungs- und Reaktionsmechanismus zu haben – was wahrscheinlich eine Kombination aus Technologie und menschlichen Aktivitäten ist“, sagt sie. Zusätzlich merkt die Forscherin an, dass Technologie Veränderungen erfassen sowie Anomalien identifizieren könne, und dass Menschen beurteilen könnten, ob die Veränderung ein Risiko darstellt, das Aufmerksamkeit und Investitionen erfordert. 2. Einen erfolgreichen Cyberangriff erleben – egal, wie groß oder klein Nichts verdeutliche die Schwächen eines Cybersecurity-Frameworks besser als ein Sicherheitsvorfall, erläutert Steven Bucher, CSO bei Mastercard. „Ich habe selbst erlebt, wie bereits ein kleiner Vorfall veraltete Protokolle oder Lücken in der Mitarbeiterschulung aufdecken kann“, erklärt er. „Wenn Ihr Sicherheitskonzept nicht mit den sich wandelnden Bedrohungen oder den sich ändernden Geschäftsanforderungen Schritt gehalten hat, ist es Zeit für eine Überarbeitung.“ Da sich Cyberbedrohungen ständig weiterentwickeln, hilft es laut Bucher, proaktiv zu bleiben, regelmäßige Überprüfungen durchzuführen und eine Kultur des Cybersicherheitsbewusstseins zu fördern. So ließen sich Probleme erkennen, bevor sie zu Krisen führen. „Letztendlich ist ein robustes und aktuelles Sicherheitskonzept der beste Weg, Ihr Unternehmen zu schützen und Vertrauen zu erhalten.“ 3. Kontinuierliche Überwachung wird zur Herausforderung Wenn Ihr Rahmenwerk eine kontinuierliche Überwachung nicht gewährleisten oder ein proaktives Risikomanagement nicht unterstützen kann, ist es an der Zeit, es an etablierten Standards auszurichten, wie dem NIST Cybersecurity Framework. Auch die Integration branchenspezifischer Compliance-Anforderungen sollte nach Bedarf neu aufgebaut werden, erklärt Dave Floyd, Vice President Cybersecurity Sales and Service bei Hughes Network Systems. Floyd empfiehlt, beim Wiederaufbau eines Cybersicherheitsrahmens mit dem NIST-Rahmenwerk zu beginnen und dieses um branchenspezifische Compliance-Anforderungen zu ergänzen. Ein solcher Ansatz stelle sicher, dass Best Practices und regulatorische Verpflichtungen für das Gesundheitswesen, den Finanzsektor und andere Branchen umfassend berücksichtigt werden. 4. Der formale Framework-Review erfolgt nur alle paar Jahre Wenn es in den letzten drei Jahren oder länger keine wesentlichen Änderungen an Ihrem Rahmenwerk gegeben hat, ist dies ein starkes Indiz dafür, dass es veraltet sein könnte, erklärt Sandra McLeod, CISO bei Zoom. „Die Cybersicherheitslandschaft hat sich rasant weiterentwickelt, insbesondere durch den Aufstieg generativer KI. Ihr Framework sollte diese Veränderungen widerspiegeln.“ McLeod empfiehlt daher alle zwei Jahre einen vollständigen Review, ergänzt durch eine Kurzprüfung in den Jahren dazwischen. „Dies trägt dazu bei, dass das Rahmenwerk mit den sich wandelnden Bedrohungen, geschäftlichen Veränderungen und regulatorischen Anforderungen Schritt hält.“ Idealerweise sollten Sicherheitsverantwortliche ihr Framework stets im Blick behalten. Außerdem sollten sie eine Liste mit Bereichen führen, die optimiert, vereinfacht oder präzisiert werden könnten, ergänzt die CISO. „Diese informellen Erkenntnisse sollten in die Gespräche während der kurzen Überprüfungen einfließen, um die kontinuierliche Verbesserung stets im Auge zu behalten.“ 5. Sie jagen ständig Warnmeldungen hinterher, statt vorausschauend zu planen Wenn sich Ihr Unternehmen permanent in einem reaktiven statt in einem proaktiven Zustand befindet, ist es laut Nima Baiati, Executive Director und General Manager für Commercial Software and Security Solutions bei Lenovo, an der Zeit, die Vorgehensweise zu überdenken. Steckt das Unternehmen in einem Kreislauf fest, in dem ständig Warnmeldungen und Vorfälle abgearbeitet werden und Ereignisse erst im Nachhinein gemeldet werden, anstatt Bedrohungen vorherzusagen, Daten zu analysieren und strategisch zu planen? Dann sei es Zeit für eine Veränderung, rät er. „Natürlich wird es weiterhin reaktive Situationen geben, aber wenn diese den Großteil der Kapazitäten des Tagesgeschäfts beanspruchen, ist es wahrscheinlich nur eine Frage der Zeit, bis schwerwiegendere Vorfälle auftreten.“ Baiati empfiehlt, zunächst ein fundiertes Verständnis der Risikobereitschaft und der Gesamtgeschäftsstrategie des eigenen Unternehmens zu entwickeln. „Richtig umgesetzte Sicherheit kann ein Wettbewerbsvorteil sein, da sie Betriebsunterbrechungen minimiert und das Vertrauen stärkt“, erklärt er. Finanzinstitute beispielsweise hätten eine geringe Risikobereitschaft und müssten unbedingt die Integrität ihrer Daten und ihren Ruf schützen. Ihre Geschäftsstrategie und ihre Sicherheit seien eng miteinander verknüpft. Da Mitarbeitende heutzutage mobiler denn je sind, rückt das Thema Endpoint Security stärker in den Fokus der Netzwerksicherheit und muss in das Cybersicherheitskonzept integriert werden. „Um eine starke Endpunktsicherheit zu gewährleisten, sollten Unternehmen einen umfassenden, mehrschichtigen Ansatz verfolgen, der alle Aspekte ihrer digitalen Umgebung schützt – Firmware, Hardware, Software und die Lieferkette“, so Baiati. „Evaluieren Sie sowohl geräteinterne als auch Cloud-basierte KI-Anwendungen, um eine effektive Bedrohungserkennung und -abwehr in Echtzeit sicherzustellen.“ 6. KRIs und KPIs entwickeln sich negativ „Wenn Sie den Eindruck haben, dass sich wichtige Risikoindikatoren (Key Risk Indicators – KRIs) und wichtige Leistungsindikatoren (Key Performance Indicators – KPIs) sich unerwartet verschlechtern, sollten Sie Ihr Framework möglicherweise überdenken“, sagt Sameer Ansari, Leiter des Datenschutzteams bei der Wirtschaftsprüfungs-, Risiko- und Compliance-Beratung Protiviti. Organisationen, die ihr Cybersicherheits-Framework lediglich als Checkliste benutzen, um Vorschriften einzuhalten und nicht als Instrument für fundierte Risikoentscheidungen betrachten, begeben sich in Gefahr, warnt Ansari. „Unternehmen sollten ihre wichtigsten Geschäftsziele und potenziellen Risiken berücksichtigen und das Framework unter diesem Gesichtspunkt anwenden.“ Viele Cybersicherheitsverantwortliche verstrickten sich beim Aufbau oder der Aktualisierung eines Frameworks in Benchmarking und Vergleichen mit anderen Unternehmen, anstatt sich auf die Bedürfnisse ihrer Organisation zu konzentrieren, so Ansari. Noch schlimmer sei die Annahme, Quantität schlage Qualität. „Manche Sicherheitschefs versuchen, verschiedene Frameworks zu kombinieren und schaffen so ein unübersichtliches ‚Frankenstein-Framework‘, das sich nur schwer verwalten und weiterentwickeln lässt“, warnt er. 7. Sie verfolgen einen reinen Compliance-orientierten Ansatz Ein häufiger Fehler vieler Sicherheitsverantwortlicher ist laut Daniel Tobok, CEO des Incident-Response-Unternehmens Cypfer, dass ein Framework entwickelt wird, welches primär darauf ausgelegt ist, „das Audit zu bestehen“, anstatt Geschäftsziele zu verfolgen. Ein rein Compliance-orientierter Ansatz klammere oft wichtige Beiträge von Nicht-IT-Stakeholdern aus, warnt er. Das führe typischerweise zu einem Framework, das zwar gut auf dem Papier aussieht, in der Praxis aber keinen wirksamen Schutz bietet. Idealerweise sollte sich ein Cybersicherheitsrahmen kontinuierlich weiterentwickeln, wobei den Bereichen mit dem höchsten Risiko Priorität eingeräumt wird, rät Tobok. „Ein vollständiger Neuaufbau kann jedoch notwendig sein, wenn das bestehende Framework das Unternehmen nicht mehr effektiv schützt oder wenn die Kosten für inkrementelle Korrekturen den Nutzen übersteigen.“ Ein Neuaufbau sei auch unmittelbar nach grundlegenden Veränderungen im Unternehmen angezeigt, ergänzt er, beispielsweise bei neuen Geschäftsmodellen, geänderten regulatorischen Vorgaben oder erweiterten Bedrohungslandschaft. All dies könne dazu führen, dass das bestehende Framework veraltet oder unzureichend ist. (tf) View the full article

The React 19 library for building application interfaces was hit with a remote code vulnerability, React2Shell, about a month ago. However, as researchers delve deeper into the bug, the larger picture gradually unravels. The vulnerability enables unauthenticated remote code execution through React Server Components, allowing attackers to execute arbitrary code on affected servers via a crafted request. In other words, a foundational web framework feature quietly became an initial access vector. What followed was a familiar but increasingly compressed sequence. Within hours of disclosure, multiple security firms confirmed active exploitation in the wild. Google’s Threat Intelligence Group (GTIG) and AWS both reported real-world abuse, collapsing the already-thin gap between vulnerability awareness and compromise. “React2Shell is another reminder of how fast exploitation timelines have become,” said Nathaniel Jones, field CISO at Darktrace. “The CVE drops, a proof-of-concept is circulating, and within hours you’re already seeing real exploitation attempts.” That speed matters because React Server Components are not a niche feature. They are embedded into default React and Next.js deployments across enterprise environments, meaning organizations inherited this risk simply by adopting mainstream tooling. Different reports add new signals While researchers agreed on the root cause, multiple individual reports have emerged, sharpening the overall picture. For instance, early analysis by cybersecurity firm Wiz demonstrated how easily an unauthenticated input can traverse the React Server Components pipeline and reach dangerous execution paths, even in clean, default deployments. Unit 42 has expanded on this by validating exploit reliability across environments and emphasizing the minimal variation attackers needed to succeed. Google and AWS have added operational context by confirming exploitation by multiple threat categories, including state-aligned actors, shortly after disclosure. That validation moved React2Shell out of the “potentially exploitable” category and into a confirmed active risk. A report from Huntress has shifted focus by documenting post-exploitation behavior. Rather than simple proof-of-concept shells, attackers were observed deploying backdoors and tunneling tools, signalling that React2Shell was already being used as a durable access vector rather than a transient opportunistic hit, the report noted. However, not all findings amplified urgency. Patrowl’s controlled testing showed that some early exposure estimates were inflated due to version-based scanning and noisy detection logic. Taken together, the research painted a clearer, more mature picture within days (not weeks) of disclosure. What the research quickly agreed on Across early reports from Wiz, Palo Alto Networks’ Unit 42, Google AWS, and others, there was a strong alignment on the core mechanics of React2Shell. Researchers independently confirmed that the flaw lives inside React’s server-side rendering pipeline and stems from unsafe deserialization in the protocol used to transmit component data between client and server. Multiple teams confirmed that exploitation does not depend on custom application logic. Applications generated using standard tools were vulnerable by default, and downstream frameworks such as Next.js inherited the issue rather than introducing it independently. That consensus reframed React2Shell from a “developer mistake” narrative into a framework-level failure with systemic reach. This was the inflection point. If secure-by-design assumptions no longer hold at the framework layer, the defensive model shifts from “find misconfigurations” to “assume exposure.” Speed-to-exploit as a defining characteristic One theme that emerged consistently across reports was how little time defenders had to react. Jones said Darktrace’s own honeypot was exploited in under two minutes after exposure, strongly suggesting attackers had automated scanning and exploitation workflows ready before public disclosure. “Threat actors already had scripts scanning for the vulnerability, checking for exposed servers, and firing exploits without any humans in the loop,” he said. Deepwatch’s Frankie Sclafani framed this behavior as structural rather than opportunistic. The rapid mobilization of multiple China-linked groups, he noted, reflected an ecosystem optimized for immediate action. In that model, speed-to-exploit is not a secondary metric but a primary measure of operational readiness. “When a critical vulnerability like React2Shell is disclosed, these actors seem to execute pre-planned strategies to establish persistence before patching occurs,” he said. This matters because it undercuts traditional patch-response assumptions. Even well-resourced enterprises rarely patch and redeploy critical systems within hours, creating an exposure window that attackers now reliably expect. What exploitation looked like in practice Almost immediately after the December 3 public disclosure of React2Shell, active exploitation was observed by multiple defenders. Within hours, automated scanners and attacker tools probed internet-facing React/Next.js services for the flaw. Threat intelligence teams confirmed that China-nexus state-aligned clusters, including Earth Lumia and Jackpot Panda, were among the early actors leveraging the defect to gain server access and deploy follow-on tooling. Beyond state-linked activity, reports from Unit42 and Huntress detailed campaigns deploying Linux backdoors, reverse proxy tunnels, cryptomining kits, and botnet implants against exposed targets. This was a sign that both espionage and financially motivated groups are capitalizing on the bug. Data from Wiz and other responders indicates that dozens of distinct intrusion efforts have been tied to React2Shell exploitation, with compromised systems ranging across sectors and regions. Despite these confirmed attacks and public exploit code circulating, many vulnerable deployments remain unpatched, keeping the window for further exploitation wide open. The lesson React2Shell leaves behind React2Shell is ultimately less about React than about the security debt accumulating inside modern abstractions. As frameworks take on more server-side responsibility, their internal trust boundaries become enterprise attack surfaces overnight. The research community mapped this vulnerability quickly and thoroughly. Attackers moved even faster. For defenders, the takeaway is not just to patch, but to reassess what “default safe” really means in an ecosystem where exploitation is automated, immediate, and indifferent to intent. React2Shell is rated critical, carrying a CVSS score of 10.0, reflecting its unauthenticated remote code execution impact and broad exposure across default React Server Components deployments. React maintainers and downstream frameworks such as Next.js have released patches, and researchers broadly agree that affected packages should be updated immediately. Beyond patching, they warn that teams should assume exploitation attempts may already be underway. Recommendations consistently emphasize validating actual exposure rather than relying on version checks alone, and actively hunting for post-exploitation behavior such as unexpected child processes, outbound tunneling traffic, or newly deployed backdoors. The message across disclosures is clear: React2Shell is not a “patch when convenient” flaw, and the window for passive response has already closed. View the full article

The year of agentic AI came with promises of massive productivity gains for businesses, but the rush to adopt new tools and services also opened new attack paths in enterprise environments. Here are some of the top security risks to the AI ecosystem that were revealed this year by security researchers, either in the wild or as researcher-demonstrated attacks. Shadow AI and vulnerable AI tools Giving free reign to employees to experiment with AI tools to automate business processes might sound like a good idea that could surface creative solutions. But it can quickly get out of control if not done under a strict policy and monitoring. A recent survey of 2,000 employees from companies in the US and UK revealed that 49% use AI tools not sanctioned by their employers and that over half do not understand how their inputs are stored and analyzed by these tools. The deployment of all AI-related tools and services on premises or in the cloud needs to involve the security team in order to catch insecure configurations or known vulnerabilities. In its 2025 State of Cloud Security report, Orca Security reported that 84% of organizations now use AI-related tools in the cloud and that 62% had at least one vulnerable AI package in their environments. A separate report from the Cloud Security Alliance reported that one third of organizations experienced a cloud data breach that involved an AI workload, with 21% of those incidents caused by vulnerabilities, 16% by misconfigured security settings, and 15% by compromised credentials or weak authentication. Even the AI tools released by major vendors regularly have vulnerabilities identified and patched in them. Examples this year include: A critical remote code execution (RCE) in open-source AI agent framework Langflow that was also exploited in the wild An RCE flaw in OpenAI’s Codex CLI Vulnerabilities in NVIDIA Triton Inference Server RCE vulnerabilities in major AI inference server frameworks, including those from Meta, Nvidia, Microsoft, and open-source projects such as vLLM and SGLang Vulnerabilities in open-source compute framework Ray AI supply chain poisoning Companies that are developing software with AI-related libraries and frameworks need to be aware that their developers might be targeted. Vetting the source of AI models and development packages is vital. This year security researchers from ReversingLabs found malware hidden in AI models hosted on Hugging Face, the largest online hosting database for open-source models and other machine learning assets. Separately, they also found trojanized packages on the Python Package Index (PyPI) posing as SDKs for interacting with AI cloud services from Aliyun AI Labs, Alibaba Cloud’s AI research arm. In both cases, the attackers exploited the Pickle object serialization format to hide their code, a Python format that is commonly used to store AI models meant to be used with PyTorch, one of the most popular machine learning libraries. AI credential theft Attackers are also adopting AI for their operations and would prefer to do so without paying and in other people’s names. The theft of credentials that can be used to access LLMs through official APIs or services such as Amazon Bedrock is now prevalent and has even received a name: LLMjacking. This year Microsoft filed a civil lawsuit against a gang that specialized in stealing LLM credentials and using them to build paid services for other cybercriminals to generate content that bypassed the usual built-in ethical safeguards. Large quantities of API calls to LLMs can rack up significant costs for the owners of stolen credentials, with researchers estimating potential costs of over $100,000 per day when querying cutting-edge models. Prompt injections AI tools also come with entirely new types of security vulnerabilities, the most common of which is known as prompt injection and stems from the fact that it is very hard to control what LLMs interpret as instructions to execute or as passive data to analyze. By design there is no distinction, as LLMs don’t interpret language and intent like humans do. This leads to scenarios where data passed to an LLM from a third-party source — for example in the form of a document, an incoming email, a web page, and so on — could contain text that the LLM will execute as a prompt. This is known as indirect prompt injection and is a major problem in the age of AI agents where LLMs are linked with third-party tools to be able to access data for context or to perform tasks. This year researchers demonstrated prompt injection attacks in AI coding assistants such as GitLab Duo, GitHub Copilot Chat; AI agent platforms like ChatGPT, Copilot Studio, Salesforce Einstein; AI-enabled browsers such as Perplexity’s Comet, Microsoft’s Copilot for Edge, and Google’s Gemini for Chrome; chatbots like Claude, ChatGPT, Gemini, Microsoft Copilot; and more. These attacks can at the very least lead to sensitive data exfiltration, but can also trick the AI agent to perform other rogue tasks using the tools at its disposal, including potentially malicious code execution. Prompt injections are a risk for all custom AI agents built by organizations that pass third-party data to an LLM and mitigating it requires a multi-layered approach as no defense is perfect. This includes forcing context separation by splitting different tasks to different LLM instances and employing the principle of least privilege for the agent or the tools it has access to, taking a human-in-the-loop approach for approving sensitive operations, filtering input for text strings that are commonly used in prompt injections, using system prompts to instruct the LLM to ignore commands from ingested data, using structured data formats, and more. Rogue and vulnerable MCP servers The Model Context Protocol (MCP) has become a standard for how LLMs interact with external data sources and applications to improve their context for reasoning. The protocol has seen rapid adoption and is a key component in developing AI agents, with tens of thousands of MCP servers now published online. An MCP server is the component that allows an application to expose its functionality to an LLM through a standardized API and an MCP client is the component through which that functionality gets accessed. Integrated development environments (IDEs) such as Microsoft’s Visual Studio Code or those based on it, like Cursor and Antigravity, natively support integration with MCP servers and command-line-interface tools such as Claude Code CLI can also access them. MCP servers can be hosted and downloaded from anywhere, for example GitHub, and they can contain malicious code. Researchers recently showed how a rogue MCP server could inject malicious code into the built-in browser from Cursor IDE. However, MCP servers don’t necessarily have to be intentionally rogue to be a security threat. Many MCP servers can have vulnerabilities and misconfigurations and can open a path to OS command injection. The communication between MCP clients and MCP servers is also not always secure and can be exposed to an attack called prompt hijacking where attackers can get access to servers by guessing session IDs. View the full article

FotoDax | shutterstock.com In der Außenperspektive sollte es für Menschen, die es zum Chief Information Security Officer gebracht haben, eigentlich kein Problem sein, die Branche zu wechseln. In der Realität stellen viele Sicherheitsentscheider allerdings regelmäßig fest, dass das Gegenteil der Fall ist: Wenn man einmal in einer bestimmten Branche tätig ist, gestaltet es sich mitunter schwierig, wieder auszusteigen. Das liegt auch daran, dass Führungskräfte und Personalvermittler oft immer noch davon ausgehen, dass die Erfahrungswerte eines CISO lediglich innerhalb seines aktuellen Sektors von Nutzen sind. Allerdings hat die IT-Evolution der letzten 15 Jahre inzwischen zu einer zunehmenden branchenübergreifenden Standardisierung von Technologien geführt. Dennoch kommen CISOs, die etwa von der Fertigungs- in die Healthcare-Branche wechseln möchten, nicht umhin zu beweisen, dass ihre Fähigkeiten von einem Sektor auf den anderen übertragbar sind. In diesem Artikel lesen Sie, wie Sie das anstellen. 1. Wechsel strategisch anbahnen Die erste Voraussetzung, die Sicherheitsentscheider erfüllen sollten, um erfolgreich die Branche zu wechseln, ist, sich die nötige Anpassungsfähigkeit anzueignen. Das weiß Timothy Youngblood aus eigener Erfahrung. Der Sicherheitsspezialist war bereits bei mehreren großen US-Unternehmen als Sicherheitsentscheider tätig. Unter anderem war er auch der allererste Global CISO bei Dell. Zuerst lernte er die Herausforderungen verschiedener Branchen allerdings als Berater bei KPMG kennen: “Für meine Karriere habe ich viele wichtige Erkenntnisse aus meiner Zeit als Consultant mitgenommen. Etwa, dass jede Branche ihre eigenen Nuancen hat, aber die grundlegenden Sicherheitsprinzipien immer die gleichen sind.” Dabei die unterschiedlichen Branchenanforderungen zu durchdringen, habe ihn auch der Austausch mit branchenspezifischen ISACs vorangebracht (die vor allem in den USA verbreitet sind), so Youngblood: “Diese Gruppen ermöglichen den Austausch zwischen dem öffentlichen und dem privaten Sektor und bieten eine hervorragende Möglichkeit, zu verstehen, wie andere Branchen das gleiche Problem lösen.” CISOs ohne Consulting-Erfahrung (oder Zugang zu ISACs), die die Branche wechseln wollen, ist hingegen zu empfehlen, strategisch strukturelle Ähnlichkeiten zu identifizieren. Sal DiFranco, Managing Partner bei der Personalberatung DHR Global, erklärt: “Halten Sie Ausschau nach Sektoren, die ähnlich strukturiert sind wie ihre aktuelle Branche. Das gewährleistet in der Regel einen einfachen Übergang – oder kann der erste Schritt sein zu einem Wechsel in eine andere, eher ferne Branche.” Laut dem Manager könnten Sicherheitsentscheider aus der Pharmabranche ohne Weiteres ins Healthcare-Feld wechseln: “Natürlich gibt es zwischen den Unternehmen in diesen Bereichen viele Unterschiede. Aus technologischer Perspektive sind sie sich dennoch ähnlich: Es handelt sich in beiden Fällen um ein stark reguliertes Umfeld mit denselben strikten Anforderungen an die Technologie.” 2. Erfolge demonstrieren CISOs, die einer neuen Branche durchstarten möchten, sollten außerdem möglichst früh demonstrieren, dass ihre bisherigen Erfolge auch für das neue Unternehmen relevant sind. DiFranco erklärt: “Wenn das, was ein Job-Kandidat geleistet hat, auch auf die Ziele des neuen Unternehmens einzahlt, ist es wesentlich wahrscheinlicher, dass dieser eine Chance bekommt, sich zu beweisen. Es geht aber nicht nur um die Ergebnisse an sich, sondern auch darum, artikulieren zu können, wie man dieselben Resultate in der neuen Branche erzielen möchte.” Exakt diesen Ansatz verfolgte auch Youngblood erfolgreich, als er von seiner Position als CISO beim US-Konsumgüterriesen Kimberly-Clark zu McDonalds wechselte, wo er sich vor allem an die operativen Strukturen gewöhnen musste. Darüber hinaus hat der Sicherheitsspezialist jedoch auch gelernt, sich an branchenspezifische Bedrohungen anzupassen – etwa als CSO von T-Mobile: “In der TK-Branche ist etwa SIM-Swapping ein bedeutendes Problem. Den meisten Außenstehenden ist nicht bewusst, dass es sich hierbei um eine kriminelle Milliardenindustrie handelt, die in manchen Fällen auch staatlich finanziert wird.” Ein tiefgreifendes Verständnis der branchenspezifischen Risikolandschaft ist auch für Michael Meline, CEO und CISO beim Security-Dienstleister Cyber Self-Defense, entscheidend. Auch Meline weiß, wovon er spricht: Seine Karriere startete er ursprünglich in der Strafverfolgung, bevor er zunächst als Security-Profi in die Finanzindustrie und anschließend ins Gesundheitswesen wechselte. “Es gibt viele ähnliche Risiken – aber im Kern geht es immer um Risikomanagement. Wenn Sie demonstrieren können, dass Sie die jeweilige Risikolandschaft durchdringen, kann Ihnen das einen erheblichen Vorteil verschaffen.” 3. Analogien herstellen Aus Karriereperspektive ist das größte Risiko für CISOs und Sicherheitsentscheider, als Spezialist für eine einzige Branche angesehen zu werden. Marc Ashworth, CISO bei der US-amerikanischen First Bank, rät an dieser Stelle, den Fokus darauf zu legen, ein übertragbares Skillset zu demonstrieren: “Machen Sie sich bei jeder Bewerbung bewusst, dass die Grundsätze branchenunabhängig immer dieselben sind.” Meline fügt hinzu: “Es geht im Kern darum, Risiken zu identifizieren und geeignete Maßnahmen ergreifen, um diese zu mindern: Dazu müssen Sicherheitsentscheider in jeder Branche mit Stakeholdern aus allen Ebenen ihrer Organisation zusammenarbeiten und einen gemeinsamen Plan entwickeln, der den jeweiligen Anforderungen entspricht:“ Oder wie DiFranco es ausdrückt: “Essenziell ist es, Relevanz zu demonstrieren und dabei Analogien zu anderen Branchen herzustellen.” (fm) Sie wollen weitere interessante Beiträge rund um das Thema IT-Sicherheit lesen? Unser kostenloser Newsletter liefert Ihnen alles, was Sicherheitsentscheider und -experten wissen sollten, direkt in Ihre Inbox. View the full article

Document database vendor MongoDB has advised customers to update immediately following the discovery of a flaw that could allow unauthenticated users to read uninitialized heap memory. Designated CVE-2025-14847, the bug, mismatched length fields in zlib compressed protocol headers, could allow an attacker to execute arbitrary code and potentially seize control of a device. The flaw affects the following MongoDB and MongoDB Server versions: MongoDB 8.2.0 through 8.2.3 MongoDB 8.0.0 through 8.0.16 MongoDB 7.0.0 through 7.0.26 MongoDB 6.0.0 through 6.0.26 MongoDB 5.0.0 through 5.0.31 MongoDB 4.4.0 through 4.4.29 All MongoDB Server v4.2 versions All MongoDB Server v4.0 versions All MongoDB Server v3.6 versions In its advisory, MongoDB “strongly suggested” that users upgrade immediately to the patched versions of the software: MongoDB 8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32, or 4.4.30. However, it said, “if you cannot upgrade immediately, disable zlib compression on the MongoDB Server by starting mongod or mongos with a networkMessageCompressors or a net.compression.compressors option that explicitly omits zlib.” MongoDB, one of the most popular NoSQL document databases for developers, says it currently has more than 62,000 customers worldwide, including 70% of the Fortune 100. This article originally appeared on InfoWorld. View the full article

As cyberattacks grow more sophisticated and AI-powered threats escalate, enterprises are under pressure to evolve beyond traditional perimeter-based network security. Many are turning to Secure Access Service Edge (SASE), a cloud-native framework that converges network and security functions to protect distributed workforces, optimize network performance, and simplify management across multiple tools. SASE platforms typically include SD-WAN, secure web gateway (SWG), firewall as a service (FWaaS), cloud access security broker (CASB), and zero-trust network access (ZTNA). They can also encompass a growing list of additional features such as browser isolation, sandboxing and data loss prevention (DLP). The overall SASE market is projected to climb from $15 billion in 2025 to $28.5 billion by 2028, according to Gartner. Deployments are split between single-vendor SASE platforms and dual-vendor approaches, the research firm says. With more enterprises adopting SASE architectures and a widening talent gap for security skills, IT professionals who can architect, deploy, and manage these converged platforms are in demand. SASE vendors are responding with certification programs aimed at validating these skills. A growing list of providers – including Cato Networks, Fortinet, Netskope, Palo Alto Networks and Zscaler – now offer credentials that help practitioners prove expertise in their platforms while keeping pace with the shift to cloud-delivered security. Here’s a snapshot of what they’re offering. Cato Networks: Cato SASE Expert Level 1 Certification Overview: This introductory course validates a fundamental understanding of the SASE framework, including the drivers, value, architecture, use cases, and key network and security functions of SASE. It also offers the knowledge required to help an organization more toward SASE adoption. Target professional: This certification is ideal for IT professionals, network administrators, and security architects. Key skills: Certified individuals demonstrate proficiency with the Cato Management Application (CMA) and possess the technical expertise to operate, configure, and troubleshoot Cato SASE Cloud. The certification covers SASE essentials, including converged network and security functions in cloud native architectures. Exam specifics: Candidates take a two-to-three exam and must receive an 85% or higher to become certified. Cost: The self-paced SASE course and exam are free. Prerequisites: Candidates should have experience in cloud, networking, and security. Cato recommends candidates watch several SASE videos and read three SASE books to prepare for the exam. Note: Cato Networks offers several levels of SASE certifications. Cisco: Cisco Certified Network Professional (CCNP) Security Overview: While not specific to SASE, the CCNP Security certification proves skills in security infrastructure, including network, cloud, and content security, endpoint protection and detection, secure network access, visibility, and enforcement. Earning the CCNP Security certification proves an IT professional has the know-how to secure and protect networks. Target professional: IT professionals with three to five years of IT experience who work with Cisco security products. This is considered an intermediate-level certification for network and security professionals. Key skills: Certification holders demonstrate knowledge of identifying common threats and vulnerabilities, understanding encryption and virtual private networks, and implementing core security technologies. Exam specifics: The Cisco Certified Specials-Security Core exam, or SCOR exam, and the concentration exams make up the CCNP Security Certification. The core SCOR exam is 120 minutes long, and the concentration exam is 90 minutes long. A passing score generally falls within the range of 800 to 850 out of 1,000 points. Cost: $400 Prerequisites: There are no formal prerequisites, but three to five years of experience is recommended for this professional-level certification. Note: Cisco offers a SASE Solution Specialization as part of its partner program. Fortinet: Fortinet Certified Solution Specialist Secure Access Service Edge (FCSS SASE) Overview: The FCSS SASE certification confirms a candidate’s ability to design, manage, monitor, and troubleshoot Fortinet SASE solutions. The curriculum covers SASE infrastructures using advanced Fortinet technologies. Target professional: Cybersecurity professionals who require the expertise needed to design, manage, support, and analyze advanced Fortinet SASE solutions and who are working with FortiSASE solutions. Network security engineers and those professionals looking to specialize in SASE technologies are also good candidates. Key skills: This certification validates skills in designing, administering, monitoring, and troubleshooting Fortinet’s SASE solutions, covering areas such as SASE architecture, user onboarding, security posture and compliance, security profiles, SD-WAN deployments, and FortiSASE analytics and reporting. Exam specifics: The FortiSASE Administrator exam (FCSS_SASE_AD-24) is a 60-minute exam consisting of 30 questions with a pass/fail scoring system. To achieve this certification, candidates are required to pass two core exams within two years. Cost: $200 Prerequisites: Fortinet recommends taking the associated Network Security Expert (NSE) courses to prepare for the certification exams. Candidates should have foundational knowledge in network security and cybersecurity before trying to gain this professional-level certification. Fortinet provides study guides through its training portal. Note: The FCSS SASE certification consists of two parts: SD-WAN and SASE. The certification uses FortiSASE 25 and FortiOS 7.4 technologies. Netskope: Netskope SASE Accreditation Overview: Netskope’s SASE Accreditation program provides foundational theory and practical knowledge of SASE architecture and implementation with on-demand, self-paced learning modules and quizzes and optional, interactive technical labs for a more hands-on experience. Target professional: The program is designed for working practitioners and architects in cybersecurity, networking, and technology, including roles in system administration, network engineering, IT operations, and software development. Key skills: The accreditation focuses on core SASE and zero-trust concepts including cloud computing, and software-defined networking (SDN), as well as cloud security components such as Cloud Access Security Broker (CASB), Secure Web Gateway (SWG), Zero Trust Network Access (ZTNA), Data Loss Prevention (DLP), and threat protection. Exam specifics: The 45-minute exam consists of 30 multiple-choice questions and requires an 80% to pass. Attendees are given two attempts to pass. Cost: Netskope offers this course and exam for free. Prerequisites: Attendees should have knowledge of security, network, and architectural principles. No coding or system administrative experience is required. Note: While sponsored by Netskope, the accreditation course and exam aim to be vendor-agnostic. Palo Alto Networks: Palo Alto Networks Certified Security Service Edge Engineer Overview: This certification validates experienced security service edge (SSE) engineers on their knowledge and skills in deployment configuration, and post-deployment management and configuration, as well as their ability to troubleshoot deployed Prisma Access environments. Target professional: The certification is designed for SSE and SASE engineers, Prisma Access Specialists, network and security engineers, professional service consultants, and technical support engineers responsible for security and optimizing network and cloud environments. Key skills: The certification validates experienced SSE engineers on their knowledge and skills in setting up and configuring Prisma Access and SSE solutions. It also verifies skills in ongoing administration and configuration management of deployed environments, as well as the ability to diagnose and resolve issues in deployed Prisma Access environments. Exam specifics: The exam consists of multiple-choice and scenario-based questions with 60 questions total, a duration of 90 minutes, and a passing score of 70%. Cost: $250 Prerequisites: There are no formal prerequisites; candidates should have solid knowledge of network security and security architecture principles and experience with SSE/SASE tools like ZTNA, CASB, and SWG. Note: This certification bridges the gap between outdated VPNs and AI-powered SASE. Versa Networks: Versa Certified Security Specialist Overview: This is Versa Networks’ entry-level SSE certification, designed to validate foundational knowledge of Security Service Edge architecture and the Versa platform. It serves as a stepping stone for network engineers looking to specialize in Versa’s SASE solutions. Target professional: Engineers who perform architect, engineering, or planning roles with Versa Security services for more than one year, with hands-on experience managing and operating Versa Secure SD-WAN Platforms. Key skills: This certification validates skills in administering Versa Security services on SD-WAN platforms, maintaining network security functions within the Versa ecosystem, and diagnosing and resolving security-related issues on Versa Secure SD-WAN platforms. Exam specifics: The exam consists of 60 multiple-choice questions that must be completed within the 90-minute timeframe, with a pass/fail result immediately available. Cost: $150 Prerequisites: Candidates must have also completed the Versa Certified SD-WAN Associate (VNX100) or Versa Certified Administrator – SD-WAN Specialist (VNX301) certification programs. Note: Versa Certifications are valid for two years. Zscaler: Zscaler Zero Trust Cyber Associate (ZTCA) Overview: ZTCA is a foundational zero-trust credentials aimed at validating knowledge around zero trust principles, architectures, and how they differ from legacy network security models. Target professional: This certification is for anyone wanting to learn the basics of zero trust and it is well-suited for candidates who are newer to zero-trust architectures or who want to formalize their foundational understanding before moving into vendor-specific roles. Key skills: This certification validates that candidates can recognize the differences between old/legacy architectures and zero-trust models and understand when a zero-trust approach offers advantages. It also teaches the core components of zero trust, such as identity, least privilege, microsegmentation, and continuous verification, and how they integrate into a holistic model. Exam specifics: The exam consists of 75 questions and runs for two hours, and candidates are allowed three attempts to pass.To earn the credential, candidates must complete the e-learning portion and pass the exam. Cost: $300 Prerequisites: Candidates must complete the five-hour e-learning course before taking the exam, and basic knowledge of networking and cybersecurity domains is required. Note: Zscaler issues a digital badge for its certifications that can be displayed on LinkedIn and other platforms. View the full article

There are few research institutions in the world with the size and scope of the European Organization for Nuclear Research, CERN. Founded in 1954 by 12 European countries, the European Laboratory for Elementary Particle Physics is located in the Swiss town of Meyrin, in the canton of Geneva, although its facilities extend along the Franco-Swiss border. Among them is the Large Hadron Collider (LHC), the world’s largest particle accelerator. International collaboration is at the core of its origin: more than 3,500 people make up its permanent staff. A small village that expands to 17,000 when adding the scientific staff of around 950 institutions from more than 80 different countries that collaborate on projects at the center. In this homegrown ecosystem, IT risk management poses a challenge. “The main problem is that we are managing a huge organization,” explains Stefan Lüders, CERN’s CISO. “We are one of the most important particle physics research institutes on the planet. We do sophisticated and interesting things, which makes us a target for attacks from different communities.” He lists several of these potential threats: script kiddies or hackers with basic knowledge, who all pose a potential security risk; ransomware or data exfiltration; sabotage of CERN’s work; espionage actions and criminal groups trying to infiltrate through computers or other devices. “This is where people come in. Because we have a very large, heterogeneous and very fluctuating research community. There are many physicists who join the organization every year. They come in and leave to do their PhD, do research at CERN and then leave,” he describes, pointing to the challenge of “taking care of this community of users. The other challenge is the flexible and fast-developing world of IT.” This includes programming — importing open-source libraries, their security, etc. — and AI. “The more sophisticated AI becomes, the greater the likelihood that those AI-driven security or attack tools will try to infiltrate the organization.” Securing CERN How do you ensure effective implementation of cybersecurity initiatives that don’t disrupt scientific work? “You can’t,” Lüders asserts. “Cybersecurity is inconvenient. Let’s face it.” Lüders equates it to locking your front door or using your PIN to get cash out of the ATM; they can be annoying, but necessary. “We try to explain to our community why security measures are needed,” he says. “And if we adapt our security measures to our environment, people adopt them. Yes, it makes the research a little more complicated, but only a little.” Lüders insists on the research work factor. “We are not a bank. We don’t have billions of dollars. We are not a military base, which means we don’t have to protect a country. We do research, which means adapting the level of security and the level of academic freedom so that the two go hand in hand. And that’s an ongoing conversation with our user community.” This ranges from scientific personnel to industrial control systems management, IT or human resources. “To meet this challenge, it is essential to talk to people. That’s why, I insist, cybersecurity is a very sociological issue: talking to people, explaining to them why we do this.” For example, not everyone willingly uses multifactor authentication because “let’s face it, they’re a pain. It’s much easier to type in a password, and who even wants to type in a password? You just want to log in. But for protection needs, today we have passwords and multifactor authentication. So you explain to people what you’re protecting. We tell them why it’s important to protect their work, as well as research results. And the vast majority understand that you need a certain level of security,” he says. “But it’s a challenge because there are so many different cultures here, different nationalities, different opinions and thoughts, and different backgrounds. That’s what we are constantly trying to adapt to.” Stefan Lüders and Tim Bell of CERN. CERN Employing proprietary technology can introduce risks, according to Tim Bell, leader of CERN’s IT governance, risk and compliance section, who is responsible for business continuity and disaster recovery. “If you’re a visitor to a university, you’ll want to bring your laptop and use it at CERN. We can’t afford to remove these electronic devices upon arrival at the facility. It would be incompatible with the nature of the organization. The implication is that we must be able to implement BYOD-type security measures.” Because at the core of everything always remains the collaborative nature of CERN. “Academic papers, open science, freedom of research, are part of our core. Cybersecurity needs to adapt to this,” Lüders notes. “We have 200,000 devices on our network that are BYOD.” How then does the adaptation of cyber protection apply? “It’s called defense in depth,” explains the CISO. “We can’t install anything on these end devices because they don’t belong to us, (…) but we have network monitoring.” In this way, even if you don’t have direct access to each device, you are warned when something is being done against the center’s policies, both at the level of cybersecurity and inappropriate uses, such as employing the technology they provide for particular interests.” These measures also extend to obsolete systems, which the organization is able to assimilate because they have a network resilient enough that even if one piece of equipment is compromised, it won’t damage any other CERN systems. The legacy technology problem extends to the equipment needed for the physics experiments being performed at the center. “These are protected by dedicated networks, which allows the network protection to kick in and protect them against any kind of abuse,” Lüders explains. On IoT connected devices not designed with cybersecurity in mind, “a problem for all industries,” Lüders is blunt: “You will never get security in IoT devices.” His solution is to connect them to restricted network segments where they are not allowed to communicate with anything else, and then define destinations to which they can communicate. General framework This is part of a larger challenge: aligning the IT and OT sides so that security continuity is established throughout the organization. A challenge that goes through centralization. “Today the OT part, the controls systems at CERN, are using IT virtualization,” explains Lüders. “The strategy is to bring IT and control people together so that the control people can use the IT services to their advantage. From the technology department, a central system is provided with different functionalities for operations, as well as for other areas of the organization, accessible through a single point of entry. “That’s the power of centralization.” This system also includes new tools such as AI tools in LLM, where they have a working group in place to find the best way to employ them. “We are facing a big discovery and, later on, we will centralize it through a central IT service. And that’s how we do it with all technologies.” Just as the subjects they research at CERN are evolving, so is their IT governance framework. This has been keeping up with industry developments, Bell explains, hand in hand with audits that allow it to operate according to best practice. “The governance part is becoming more formal. In general, everything was well organized; it was just a matter of standardizing it and developing policy frameworks around it.” Despite the establishment of these standards, the result is the opposite of rigid, explains Bell, who exemplifies this with the case of a recent cybersecurity audit in which CERN was assessed against one of the international standards, which served to improve the level of maturity. “We are adopting a fairly flexible IT governance policy, learning from the experience of others in adopting industry standards.” View the full article

Security professionals hunting PoCs and exploit code on GitHub might soon walk into a trap, as attackers redirect a known RAT toward them. Researchers have uncovered a stealthy campaign in which the Webrat Trojan, known for months to hide inside game cheats and cracked software, is now posing as proof-of-concept exploit repositories on GitHub to trick unsuspecting security researchers. The clever decoy and the unexpected target set the campaign apart from typical malware distribution attacks. Kaspersky’s security analysts spotted this evolution where attackers uploaded seemingly legitimate vulnerability exploit code, complete with structured documentation, only to lure targets into downloading a backdoor. From Game cheats to GitHub exploits Webrat isn’t new. It has a history of hiding in plain sight under familiar lures like game cheat packages (including Rust, Counter-Strike, and Roblox) and cracked software installers. But in the latest campaign, dating back to at least as far as September 2025, attackers started to change their approach by hosting repositories on GitHub that appear to offer exploit code for high-profile vulnerabilities with high CVSSv3 scores. The vulnerabilities they pushed exploits for included a critical heap-based buffer overflow in Internet Explorer (CVE-2025-59295/ CVSS 8.8), a max severity authentication bypass in a WordPress plugin (CVE-2025-10294/ CVSS 9.8), and an improper access control in Windows Remote Access Connection Manager (CVE-2025-59230/ CVSS 7.8). Apart from dumping the exploit code, the repositories included detailed sections with overviews of the vulnerability, system impact, install guides, usage steps, and even mitigation advice. The consistency of the format to a professional PoC writeup suggests the descriptions are machine-generated to avoid detection by seasoned professionals, Kaspersky researchers noted in a blog post. The malicious payload and behavior Beneath the polished README, the attackers dumped a password-protected ZIP linked in the repository. The archive password was hidden in file names, something easily missable by unsuspecting eyes. Inside, the key components include a decoy DLL, a batch file to launch the malware, and the primary executable (like rasmanesc.exe) capable of escalating privileges, disabling Windows Defender, and retrieving the real Webrat payload from hardcoded command-and-control (c2) servers. Once executed, Webrat installs a backdoor on the host system. The backdoor can exfiltrate credentials, access cryptocurrency wallets, spy through webcams and microphones, log keystrokes, and steal data from messaging apps like Telegram, Discord, and gaming platforms such as Steam. The capabilities amount to a full-blown surveillance and theft platform under the attacker’s control. Significance of the shift Researchers found the shift from tricking casual users with game cheats to targeting tech professionals with exploit code as notable as well as concerning. “They are targeting researchers who frequently rely on open sources to find and analyze code related to new vulnerabilities,” they said. However, experienced security researchers typically analyze such exploits within isolated environments like virtual machines or sandboxes, minimizing risk. Which is perhaps why the campaign is seen as deliberately tuned to target novices, including students, junior analysts, and those eager to explore PoCs without safe handling practices. “Cybersecurity professionals, especially inexperienced researchers and students, must remain vigilant when handling exploits and any potentially malicious files,” the researchers advised. “To prevent potential damage to work and personal devices containing sensitive information, we recommend analyzing these exploits and files within isolated environments like virtual machines or sandboxes.” The disclosure noted that Webrat itself hasn’t undergone any significant technical changes. Instead, attackers have reframed the risk by turning open-source curiosity into an attack surface. View the full article

NIS2 is symbolic of the core problem with European directives and regulations: They generate unnecessary red tape and too rarely have the desired effect. Whether it’s the Supply Chain Act, GDPR impact assessments, or the IT Security Act — the common theme is that companies have to produce mountains of documentation, something that neither increases actual security nor is realistically verifiable. A compliant entity is typically one that can provide comprehensive documentation of all processes and regular audits. This documentation is usually so detailed that its creation already entails an almost unreasonable effort, and manual review becomes practically impossible. Even if it were reviewed, the information would not be precise enough to demonstrate genuine security. Security should be included in the planning This leads to an absurd practice at many companies: The technical team builds functioning infrastructure, and separately, a compliance officer subsequently writes a lengthy justification as to why the solution is supposedly secure. That’s roughly equivalent to Volkswagen building a car and only afterwards someone writing 40 pages about why that car should meet safety standards. In real-world industry, of course, things work differently: Safety requirements are already integrated into the planning, minimum technological standards are defined, and quality processes automatically monitor implementation. Compliance results from technology — not from ring binders. In other areas, such as tax audits, this problem has long been recognized, and the automation of relevant processes is legally mandated (keyword: electronic cash register, audit-proof accounting software). This not only saves honest business owners enormous amounts of manual work but, above all, reduces the risk of fraud. Unfortunately, few things are implemented as consistently in Germany as the collection of our taxes. Unlike the issue of tax burden, companies should have an intrinsic interest in correctly implementing their IT security. The fine for a NIS2 violation can amount to up to €10 million or 2% of global annual revenue. The economic damage caused by successful cyberattacks is often existential and already amounts to hundreds of billions of euros per year. Even though it is not explicitly required by law, it is now possible — not least thanks to AI-supported tools — to automate security processes and their complete documentation to such an extent that security, compliance, and auditability can be combined in a single technical process. This not only saves resources but also increases actual security. An example of a SaaS application in the cloud shows what this can look like in detail. IT in transition: From text documents to declarative technology NIS2 essentially requires three things: concrete security measures; processes and guidelines for managing these measures; and robust evidence that they work in practice. Process documentation — that is, policies, responsibilities, and procedures — is not fundamentally new for most larger companies. ISO 27001-based information security management systems, HR processes, and management manuals have often been in place for years. Therefore, two levels are crucial for NIS2: the technical measures and the evidence that they are effective. This is precisely where the transformation of recent years becomes apparent. Previously, concepts, measures, and specifications for software and IT infrastructures were predominantly documented in text form. Program code was too complex, and configurations were scattered across files, ticketing systems, or in the minds of individual administrators. Documents were then written afterward — often by colleagues from other disciplines. This approach was problematic for two main reasons: It doesn’t scale in growing, distributed environments, and it doesn’t align with the goal of consistently automating technical processes. Modern systems therefore rely on methods such as test-driven or behavior-driven development and infrastructure as code (IaC), which — when consistently applied — largely replace text documentation. The technical specifications required by NIS2 can directly reference these artifacts: IaC definitions define encryption, network segments, or backup scenarios, and CI/CD pipelines deploy them to production in an audit-proof manner. Changes are thus not only described with technical precision, but also traceable chronologically via commits and deployments. Evidence for aspects that cannot be fully declared — such as the security of the software supply chain or the application code — can be mapped via security checks in the CI/CD pipeline and ongoing evaluation by SIEM and CNAPP systems. The following areas provide a particularly clear example of what this can look like in practice: Identity and access management Vulnerability management in the software supply chain and in monitoring Incident handling Reporting obligations Identity and access Management: Policies as code instead of Excel roles Identity and access management is one of the central pillars of NIS2. What’s required is not just “any” roles, but an access concept based on Need-to-Know, Least Privilege, and Separation of Duties. In practice, this can be effectively conceived in three levels: the deliberate granting of rights, a realistic lifecycle for these rights, and an architecture that prevents lateral movement as much as possible. Instead of managing permissions in Excel, admin UIs, and scattered wikis, roles and access rights are defined as “policies as code” or IaC — for example, as Terraform modules or JSON/YAML policies in a Git repository. All changes are made exclusively via merge requests and deployed through a CI/CD pipeline. This makes it clearly traceable who changed which permissions, who approved the change, and when it went live. The documentation and accountability requirements of NIS2 thus arise directly from Git history and pipeline logs, without anyone having to write additional Word documents. A role model alone does not guarantee the principle of least privilege. NIS2 requires that rights be regularly reviewed and unnecessary permissions removed. In cloud environments with hundreds of accounts, services, pods, and functions, this is virtually impossible to manage manually. This is where cloud identity entitlement management (CIEM) systems come in. They read all effective permissions from the environment, correlate them with audit logs, and show which rights are actually being used and where overprivileging exists. This is particularly crucial for non-human identities (service accounts, workloads), because this is precisely where very broad rights are often granted, which can later serve as a springboard for attackers. Some startups now even offer CIEM systems that can automatically generate IAM policies for the relevant roles using AI. Vulnerability management and software supply chain: SBOM instead of scanner PDF The second area that NIS2 and the new Implementing Regulation 2024/2690 for digital services are enshrining in law is vulnerability management in the company’s own code and supply chain. This requires regular vulnerability scans, procedures for assessment and prioritization, timely remediation of critical vulnerabilities, and regulated vulnerability handling and — where necessary — coordinated vulnerability disclosure. Cloud and SaaS providers also face additional supply chain obligations, for example, towards cloud, CI/CD, and registry service providers. In traditional vulnerability management, SCA, SAST, and DAST scanners are simply “dragged across everything.” The result is endless lists of findings, most of which are false positives or irrelevant to the specific system. This data then ends up in Excel spreadsheets or a vulnerability database, where teams try to prioritize. Especially with zero-day vulnerabilities, this leads to frantic ad-hoc analyses: Which of our components are affected? Is the vulnerability even exploitable in our architecture? What do we do until a patch is available? The modern approach is to consolidate all DevSecOps findings in a central system. Results from SCA, SAST, and DAST are combined there, enriched with context from the software bill of materials (SBOM), architecture, and exposure, and pre-filtered using AI. This drastically reduces false positives, leaving a significantly smaller set of truly relevant vulnerabilities, including an assessment of their criticality in the specific setup. These consolidated findings can be directly forwarded to ticketing systems and the SOC, where they are treated like incidents, tracked, and evaluated for NIS2 reports. This transforms a proliferating scanner output into a manageable process that reflects both legal requirements and operational realities. Monitoring, incident handling, and reporting center The third area where NIS2 quickly becomes a paper tiger is the combination of monitoring, incident response, and the new reporting requirements. The directive sets clear deadlines: early warning within 24 hours, a structured report after 72 hours, and a final report no later than one month. Many organizations are reacting by creating new templates, Excel spreadsheets, and reporting manuals — often largely detached from their existing SOC. In a critical situation, this means that the SOC tackles the incident while, simultaneously, an “NIS2 task force” tries to process information from tickets, emails, and ad-hoc chats so that it fits into a form. The result is duplicated work, loss of information, and reports that fill pages but reveal little about how well detection and response actually work. In a cloud SaaS environment, a different approach is possible: Instead of treating NIS2 reporting as a separate document project, a modern DevSecOps-based SOC is built, so that all security-relevant signals converge in one place from the outset: cloud infrastructure, CI/CD pipelines, applications, IdP, and IAM. The rules governing how this data is correlated, enriched, and transformed into incidents are defined and versioned as code. Threat detection and response logic, thresholds, and playbooks reside in the repository and are deployed via pipelines, just like application code. This allows for the automation of large portions of traditional SOC work: Raw logs are transformed into consistent, contextualized incidents without requiring manual copying and pasting of text snippets. Cloud-native application protection platforms (CNAPP) and similar platforms simultaneously handle data storage and archiving, ensuring that the evidence of monitoring activity is generated within the system rather than through separate documentation loops. Machine learning and AI components further assist in reducing false positives, clustering similar events, and highlighting unusual patterns — allowing the SOC to focus on the few incidents that truly require attention. At the process level, playbooks and reporting channels remain important — but streamlined. An incident response playbook defines incident classes, escalation paths, and communication rules, including the criteria for when an incident is considered “NIS2 significant.” A reporting process governs who consolidates the information from the SOC and business units and submits it via the BSI reporting center. The actual documentation is also generated largely automatically here: Incident tickets contain a timeline, affected services, impact, cause, and measures; a “NIS2-relevant” indicator and a reporting status link them to external reports. Key performance indicators (KPIs) such as MTTD, MTTR, or the time between detection and initial reporting can be calculated directly from SIEM and IR data — precisely the metrics that reveal whether NIS2 is a lived process or just another drawer in the document cabinet. NIS2 as an architecture test, not just a documentation exercise NIS2 forces companies to explicitly define their security measures, processes, and documentation. This is inconvenient — ​​especially for organizations that have previously operated largely on an ad-hoc basis. Whether this becomes a mere formality or a genuine security improvement, however, depends not on the legal text, but on the architecture. Anyone attempting to simply “document away” the policy using Word, PowerPoint, and Excel will generate a lot of effort and little resilience. However, if IdP and IAM, CI/CD pipelines, SBOM and vulnerability tools, SIEM, and IR platforms are configured to provide the required controls and evidence almost incidentally, NIS2 compliance is achieved as a side effect of a modern security landscape. View the full article

ServiceNow on Tuesday announced that it would buy cybersecurity vendor Armis for $7.75 billion in cash. This builds on its December purchase of identity security vendor Vezas, and the closing of its acquisition of AI vendor Moveworks. Analysts and cybersecurity practitioners mostly applauded the move, but cautioned that this could force CIOs and CISOs away from a best-of-breed strategy and into a classic suite approach, where the individual elements may be merely good enough. “This is an extension of what we have been seeing at the ERP application layer,” said Scott Bickley, an advisory fellow at the Info-Tech Research Group. “ServiceNow is basically saying ‘We don’t want to be a point solution. We want to be the platform by which you coordinate and solve all of your problems.’” Bickley noted that this trend has been ongoing for a few years, with many of the largest vendors trying to offer suites that deliver everything. “Microsoft was the initial poster child of this,” he said. “They are going to start to embed [AI and cybersecurity] capabilities into their suites and bundles, where you don’t necessarily have an opt-out solution. You will get ‘maybe good enough’ versus best of breed.” But looking at ServiceNow’s two other recent acquisitions, Vezas and Moveworks, could suggest parallel strategies. “ServiceNow has hedged their bets without saying that they are hedging their bets,” Bickley said. Pablo Stern, EVP and general manager of tech workflow products at ServiceNow, confirmed in an interview that the Armis acquisition is the largest in ServiceNow’s history. He added that the companies have been partnering “for well more than two years.” ServiceNow’s statement about the Armis deal described the two firms as creating “a unified, end-to-end security exposure and operations stack that can see, decide, and act across the entire technology footprint.” It said that it expects to fund the transaction through a combination of cash on hand and debt. The deal is expected to close in the second half of 2026, subject, as always, to regulatory approvals and closing conditions. Pressure from Agentic AI The statement quoted ServiceNow COO Amit Zavery suggesting that agentic developments are a key part of the strategy. “In the agentic AI era, intelligent trust and governance that span any cloud, any asset, any AI system, and any device are non-negotiable if companies want to scale AI for the long-term,” Zavery said in the announcement. “Together with Armis, we will deliver an industry-defining strategic cybersecurity shield for real-time, end-to-end proactive protection across all technology estates. Modern cyber risk doesn’t stay neatly confined to a single silo, and with security built into the ServiceNow AI Platform, neither will we.” The soaring popularity of autonomous agents that figure out on their own how to perform various tasks has concerned many cybersecurity executives, as the risk of security holes created by enterprise agentic trials is becoming clear. Most cybersecurity practitioners saw the move as the latest indicator that CIOs and CISOs must rethink how they do their jobs, given how AI is forcing changes in data management and data leakage. Visibility is the key “For decades, the CIO’s white whale has been a precise, real-time Configuration Management Database [CMDB]. Most are outdated the moment they are populated,” said Whisper Security CEO Kaveh Ranjbar. The Armis acquisition “is an admission that in an era of IoT, OT, and edge computing, you cannot rely on manual entry or standard agents anymore. The system of action needs to own the system of record for the unmanaged world. For CIOs, this signals that automated, continuous discovery is now the only acceptable standard for IT asset management. You can’t automate workflows on assets you don’t know exist.” The lesson, Ranjbar said, is different for the CISO. “CISOs have historically suffered from the swivel-chair problem: one screen shows the vulnerability and another screen is needed to patch it. This deal collapses that gap. It validates that visibility is the new perimeter. As OT and IT converge, the attack surface has become too complex for fragmented tools. CISOs should view this as a mandate to consolidate their visibility stacks.” Sanchit Vir Gogia, the chief analyst at Greyhound Research, agreed that this acquisition will likely accelerate IT and security structural changes. “This acquisition represents a fundamental repositioning of ServiceNow from a coordination layer into an operational authority. Buying Armis is not about expanding a security portfolio. It is about owning the upstream constraint that determines whether modern enterprises can govern complexity at all,” Gogia said. But without knowing what is connected across IT, OT, IoT, and other physical environments, “workflow automation, AI governance, and risk prioritization all collapse into theatre,” he observed, adding that the deal could remove long standing fragmentation between discovery tools, CMDBs, service mapping, ticketing, change management, and remediation. “If executed well, it could finally address one of the enterprise’s most persistent failures,” he said. Gogia added, “continuous discovery tied to business context has the potential to turn the CMDB from a negotiated artefact into a living system. That would change how incidents are resolved, how changes are governed, how audits are passed, and how accountability is assigned.” Reveals architectural debt Given that the deal is not expected to be closed until next summer, executives should temper their timeline expectations. The 2026 second half closing date “implies a prolonged transition period where integration depth, roadmap clarity, and packaging decisions will evolve. CIOs should plan for ambiguity, not assume instant unification. Early value will come from visibility, [therefore] full platform value will take time,” Gogia said. Another consultant, Yvette Schmitter, CEO of the Fusion Collective consulting firm, said the deal is sitting atop years of bad enterprise IT strategy. “This acquisition exposes more than ServiceNow’s strategy. It reveals the architectural debt hiding in every enterprise security stack that CIOs have been promising to address ‘next quarter’ for the past three years,” Schmitter said. “ServiceNow just signaled that platform plays will dominate over point solutions, and they’re willing to fund it with debt to move quickly while enterprises are still running budget committee meetings about tool sprawl.” She observed, “the valuation for Armis tells you the market assigns premium multiples to cyber-physical capabilities spanning IT, OT, and medical devices. Translation: that patchwork of legacy security tools you’ve been defending as ‘best of breed’ just became technical debt you can’t explain to the board. CIOs need to audit their current security tool sprawl and map total cost of ownership before vendors make that case for them with renewal pricing that reflects your lack of alternatives.” The question, she said, “is no longer whether to consolidate, but whether your organization controls the timing and terms of that consolidation.” Cybersecurity consultant Brian Levine, a former federal prosecutor who today serves as executive director of FormerGov, said that Armis executives were evaluating going public before they decided to accept the ServiceNow offer. “For Armis, skipping the IPO and joining ServiceNow is a signal that the market for standalone device‑security platforms is consolidating fast, and scale wins,” Levine said. “The line between workflow, risk, and security is disappearing, and ServiceNow wants to own the convergence point.” Aaron Painter, CEO of authentication vendor Nametag, added that part of the IT confusion is that product names no longer mean what they once meant. “Many of the workflows ServiceNow already automates are now security workflows, even if they’re still labeled as operations. Onboarding and offboarding, incident response, asset exceptions, vendor access, and change management all involve decisions that directly shape security outcomes,” Painter said. “Looked at alongside ServiceNow’s earlier acquisition of Veza, the strategy becomes clearer: ServiceNow is trying to connect asset visibility with identity and access intelligence, so the platform understands not just what devices exist, but who has access, why they have it, and whether that trust still makes sense over time.” This article originally appeared on CIO.com. View the full article

ServiceNow has agreed to buy cybersecurity vendor Armis for $7.75 billion in cash, it announced Tuesday. This builds on its December purchase of identity security vendor Veza, and the closing of its acquisition of AI vendor Moveworks. Analysts and cybersecurity practitioners mostly applauded the move, but cautioned that this could force CIOs and CISOs away from a best-of-breed strategy and into a classic suite approach, where the individual elements may be merely good enough. “This is an extension of what we have been seeing at the ERP application layer,” said Scott Bickley, an advisory fellow at the Info-Tech Research Group. “ServiceNow is basically saying ‘We don’t want to be a point solution. We want to be the platform by which you coordinate and solve all of your problems.’” Bickley noted that this trend has been ongoing for a few years, with many of the largest vendors trying to offer suites that deliver everything. “Microsoft was the initial poster child of this,” he said. “They are going to start to embed [AI and cybersecurity] capabilities into their suites and bundles, where you don’t necessarily have an opt-out solution. You will get ‘maybe good enough’ versus best of breed.” But looking at ServiceNow’s two other recent acquisitions, Veza and Moveworks, could suggest parallel strategies. “ServiceNow has hedged their bets without saying that they are hedging their bets,” Bickley said. Pablo Stern, EVP and general manager of tech workflow products at ServiceNow, confirmed in an interview that the Armis acquisition is the largest in ServiceNow’s history. He added that the companies have been partnering “for well more than two years.” ServiceNow’s statement about the Armis deal described the two firms as creating “a unified, end-to-end security exposure and operations stack that can see, decide, and act across the entire technology footprint.” It said that it expects to fund the transaction through a combination of cash on hand and debt. The deal is expected to close in the second half of 2026, subject, as always, to regulatory approvals and closing conditions. Pressure from Agentic AI The statement quoted ServiceNow COO Amit Zavery suggesting that agentic developments are a key part of the strategy. “In the agentic AI era, intelligent trust and governance that span any cloud, any asset, any AI system, and any device are non-negotiable if companies want to scale AI for the long-term,” Zavery said in the announcement. “Together with Armis, we will deliver an industry-defining strategic cybersecurity shield for real-time, end-to-end proactive protection across all technology estates. Modern cyber risk doesn’t stay neatly confined to a single silo, and with security built into the ServiceNow AI Platform, neither will we.” The soaring popularity of autonomous agents that figure out on their own how to perform various tasks has concerned many cybersecurity executives, as the risk of security holes created by enterprise agentic trials is becoming clear. Most cybersecurity practitioners saw the move as the latest indicator that CIOs and CISOs must rethink how they do their jobs, given how AI is forcing changes in data management and data leakage. Visibility is the key “For decades, the CIO’s white whale has been a precise, real-time Configuration Management Database [CMDB]. Most are outdated the moment they are populated,” said Whisper Security CEO Kaveh Ranjbar. The Armis acquisition “is an admission that in an era of IoT, OT, and edge computing, you cannot rely on manual entry or standard agents anymore. The system of action needs to own the system of record for the unmanaged world. For CIOs, this signals that automated, continuous discovery is now the only acceptable standard for IT asset management. You can’t automate workflows on assets you don’t know exist.” The lesson, Ranjbar said, is different for the CISO. “CISOs have historically suffered from the swivel-chair problem: one screen shows the vulnerability and another screen is needed to patch it. This deal collapses that gap. It validates that visibility is the new perimeter. As OT and IT converge, the attack surface has become too complex for fragmented tools. CISOs should view this as a mandate to consolidate their visibility stacks.” Sanchit Vir Gogia, the chief analyst at Greyhound Research, agreed that this acquisition will likely accelerate IT and security structural changes. “This acquisition represents a fundamental repositioning of ServiceNow from a coordination layer into an operational authority. Buying Armis is not about expanding a security portfolio. It is about owning the upstream constraint that determines whether modern enterprises can govern complexity at all,” Gogia said. But without knowing what is connected across IT, OT, IoT, and other physical environments, “workflow automation, AI governance, and risk prioritization all collapse into theatre,” he observed, adding that the deal could remove long standing fragmentation between discovery tools, CMDBs, service mapping, ticketing, change management, and remediation. “If executed well, it could finally address one of the enterprise’s most persistent failures,” he said. Gogia added, “continuous discovery tied to business context has the potential to turn the CMDB from a negotiated artefact into a living system. That would change how incidents are resolved, how changes are governed, how audits are passed, and how accountability is assigned.” Reveals architectural debt Given that the deal is not expected to be closed until next summer, executives should temper their timeline expectations. The 2026 second half closing date “implies a prolonged transition period where integration depth, roadmap clarity, and packaging decisions will evolve. CIOs should plan for ambiguity, not assume instant unification. Early value will come from visibility, [therefore] full platform value will take time,” Gogia said. Another consultant, Yvette Schmitter, CEO of the Fusion Collective consulting firm, said the deal is sitting atop years of bad enterprise IT strategy. “This acquisition exposes more than ServiceNow’s strategy. It reveals the architectural debt hiding in every enterprise security stack that CIOs have been promising to address ‘next quarter’ for the past three years,” Schmitter said. “ServiceNow just signaled that platform plays will dominate over point solutions, and they’re willing to fund it with debt to move quickly while enterprises are still running budget committee meetings about tool sprawl.” She observed, “the valuation for Armis tells you the market assigns premium multiples to cyber-physical capabilities spanning IT, OT, and medical devices. Translation: that patchwork of legacy security tools you’ve been defending as ‘best of breed’ just became technical debt you can’t explain to the board. CIOs need to audit their current security tool sprawl and map total cost of ownership before vendors make that case for them with renewal pricing that reflects your lack of alternatives.” The question, she said, “is no longer whether to consolidate, but whether your organization controls the timing and terms of that consolidation.” Cybersecurity consultant Brian Levine, a former federal prosecutor who today serves as executive director of FormerGov, said that Armis executives were evaluating going public before they decided to accept the ServiceNow offer. “For Armis, skipping the IPO and joining ServiceNow is a signal that the market for standalone device‑security platforms is consolidating fast, and scale wins,” Levine said. “The line between workflow, risk, and security is disappearing, and ServiceNow wants to own the convergence point.” Aaron Painter, CEO of authentication vendor Nametag, added that part of the IT confusion is that product names no longer mean what they once meant. “Many of the workflows ServiceNow already automates are now security workflows, even if they’re still labeled as operations. Onboarding and offboarding, incident response, asset exceptions, vendor access, and change management all involve decisions that directly shape security outcomes,” Painter said. “Looked at alongside ServiceNow’s earlier acquisition of Veza, the strategy becomes clearer: ServiceNow is trying to connect asset visibility with identity and access intelligence, so the platform understands not just what devices exist, but who has access, why they have it, and whether that trust still makes sense over time.” This article originally appeared on CIO.com. View the full article

A ransomware expert lauded a recent crackdown on cybercrooks in Africa that resulted in the decryption of six ransomware strains, smashing of links to malicious websites, and hundreds of arrests as major action. “This may not be the same headline as taking down LockBit, but I think it is significant,” said Jon DiMaggio, chief security strategist, Analyst1 and co-author of an upcoming book on chasing ransomware gangs. “Because law enforcement can’t arrest Russian ransomware criminals, it’s smart to focus on areas of the world where we can make a difference and get people.” He was commenting on the statement today by Interpol that in Operation Sentinel, which ran between October 27 and November 27 of this year, law enforcement agencies in 19 African countries arrested 574 suspects, decrypted six ransomware variants, took down 6,000 malicious links, cracked a business email compromise scam that almost cost a major petroleum company $7.9 million, and recovered approximately $3 million. Interpol didn’t identify the ransomware strains that were decrypted. DiMaggio suspects they were modified variants of strains available on dark web sites. Important to disrupt gangs before they expand In describing the operation, Interpol cited efforts in multiple countries. In Ghana, it said that an unnamed financial institution, which saw 100TB of its data encrypted, was one of the victims. Ghanaian authorities conducted advanced malware analysis that led to the creation of a decryption tool and the recovery of nearly 30TB of the data. Ghanaian authorities also dismantled a major cyber-fraud network operating across Ghana and Nigeria that defrauded more than 200 victims of over $400,000. Using professionally designed websites and mobile apps, the scammers mimicked well-known fast-food brands, collecting payments but never delivering orders. Ten suspects were arrested in Ghana, and over 100 digital devices seized and 30 fraudulent servers taken offline. In Benin, 43 malicious domains were taken down, and 4,318 social media accounts linked to extortion schemes and scams were shut down, leading to 106 arrests. And in Cameroon, law enforcement reacted quickly after two victims reported a scam involving an online vehicle sales platform. The phishing campaign was traced to a compromised server, and an emergency bank freeze was issued within hours. A ‘very good thing’ The fact that the same operation broke ransomware operations and a business email compromise (BEC) operation is “unique,” said DiMaggio, because most people think of Africa as the source of BEC and fraud scams. The fact that authorities are working to disrupt ransomware operations in Africa before they grow to the size of those run by gangs in other areas of the world “is a very good thing,” he said. Africa is “a few steps behind where the Russian ransomware scene is,” so targeting gangs there now before they grow bigger is important, he said. The breaking of a BEC operation could also be significant, he added, because, in aggregate, crooks around the world pull in more money from business email scams than from ransomware, DiMaggio said. Related content: RansomHouse strain upgraded Operation Sentinel is the second major anti-cybercrime operation in Africa this year. In August, Interpol announced the second stage of Operation Serengeti that saw the arrest of 1,209 people, the dismantling of over 11,400 malicious IT infrastructures, and the recovery of just over $97 million. This operation also dealt with high-impact cybercrimes including ransomware, online scams, and BEC scams. Other enforcement efforts These operations were among significant moves against threat actors globally in 2025. Operation Endgame, an ongoing international anti-botnet effort coordinated by Europol, went after threat actors subscribing to the Smokeloader pay-per-install botnet, took down some 300 servers behind the malware used to distribute ransomware, and, in November, took down or disrupted 1,025 servers including the Elysium botnet, the enabler of the Rhadamanthys infostealer and VenomRAT remote access trojan. Separately, authorities in the US, Finland, and the Netherlands teamed up to take down AVCheck, one of the largest counter-antivirus services used by criminals around the world. As well, the Five Eyes intelligence sharing group, consisting of the US, the UK, Canada, Australia, and New Zealand, accused China of supporting threat actors who are attacking critical infrastructure in a number of countries, and Microsoft got a court order allowing it to seize and block 2,300 domains behind the distribution of another infostealer, Lumma Stealer. Related content: Create a ransomware playbook that works An uphill battle Ed Dubrovsky, chief operating officer of incident response firm Cypfer, said the breaking of six ransomware strains is good news. But, he added, the cybercrime industry is more than ever focused on data theft as opposed to data encryption, and in some cases, data destruction after theft. “Law enforcement action against cybercrime is of critical importance,” he added. “Without some level of deterrence, and given the upside from a financial [perspective] and other motives, cybercrime would have been much more prevalent and impactful. “With that said, cybercrime is still a multibillion dollar market, and law enforcement suffers from limited resources and proper ongoing training. Some countries, such as the US, are far ahead of others from a sophistication and effectiveness perspective … Law enforcement is effective, partially, and in very specific areas of cybercrime, and in other areas, the effectiveness is still a work in progress.” Some threat actors have great IT expertise, he added, and are taking advantage of AI. “Therefore, I believe law enforcement is achieving great impact in reducing cybercrime while also fighting an uphill battle.” Attackers likely to expand efforts worldwide Christian Leuprecht, a Canadian university professor and expert on national security, cybercrime, and money laundering, noted Africa’s population is set to double in the next 25 years, and it has the youngest population structure of any continent. The combination of a highly innovative and increasingly sophisticated workforce in some of the most politically, economically, and socially unsustainable countries in the world will be likely to generate a host of sophisticated local threat actors vying for economic survival and prosperity, with a potentially global reach. For now, he said, they are going after local targets, likely because they’re less resilient to attack and exploitation. But as local firms harden their cyber defenses, these African-based threat actors are bound to expand their operations globally. More, better, and proactive local disruption and enforcement capacity against these threat actors is critical to prevent them from becoming global in scale, he said. “The scale and sophistication of cyberattacks across Africa are accelerating, especially against critical sectors like finance and energy,” Neal Jetton, Interpol’s director of cybercrime, said in a statement. “The outcomes from Operation Sentinel reflect the commitment of African law enforcement agencies, working in close coordination with international partners. Their actions have successfully protected livelihoods, secured sensitive personal data, and preserved critical infrastructure.” Operation Sentinel not only used the resources of law enforcement agencies, but also was assisted by efforts from cybersecurity companies including Team Cymru, The Shadowserver Foundation, Trend Micro, TRM Labs, and Uppsala Security. View the full article

The MacSync Stealer macOS malware can now infect victims’ computers using what appears to be a legitimate application with minimal user interaction, according to Apple device management and security vendor Jamf. Until now, macOS campaigns needed to persuade users to launch infected applications through relatively intrusive techniques such as ClickFix social engineering or the expert user macOS ‘drag-to-terminal’ routine. MacSync Stealer, by contrast, is downloaded from an ordinary-looking utility URL as a code-signed and notarized Swift application. Once the user initiates installation, the dropper retrieves its malware payload script from a command-and-control server. One oddity is that the download still invites victims to launch it by right-clicking and opening, even though the signed executable does not technically need this for infection. The innovation lies with its deceptive provenance: because the malware is signed by what macOS deems to be a legitimate developer and has not shown up as malicious, no warnings or extra steps are needed. This draws attention to a weakness in Apple’s Gatekeeper security – criminals can constantly reformulate their malware to evade Apple’s automated detection and notarization system. This gives attackers a window for exploitation. According to Jamf, the malware’s certificate credential was only revoked after the company reported the issue to Apple. Sign of expansion MacSync Stealer is the latest example of an expanding number of economically motivated macOS malware. The purpose is to steal data from high-value users, including account credentials, API keys, and crypto wallet data. The malware’s origins lie with an earlier Mac infostealer, Mac.c Stealer, whose appeal was that it could be bought cheaply by budding cybercriminals. However, within weeks of its appearance in April, this was rebranded as MacSync and more advanced features were added. Another macOS stealer, the Odyssey infostealer, had also been observed using the same distribution technique. “While MacSync Stealer itself is not entirely new, this case highlights how its authors continue to evolve their delivery methods,” Jamf said. “This shift in distribution reflects a broader trend across the macOS malware landscape, where attackers increasingly attempt to sneak their malware into executables that are signed and notarized, allowing them to look more like legitimate applications.” While the Mac malware “market” might appear small in volume compared to that for Windows, this largely reflects the fact that PCs remain the primary operating system used by businesses. Nevertheless, criminals have noticed that the extra development time required for Mac malware is increasingly worth it. Examples targeting enterprises and high-value individuals from 2025 include the macOS Ferret family and BlueNoroff social media campaigns associated with North Korean hackers, both connected to crypto theft. Another is the Atomic malware-as-a-service (MaaS) infostealer associated with Russian cybercriminals. View the full article

The MacSync Stealer macOS malware can now infect victims’ computers using what appears to be a legitimate application with minimal user interaction, according to Apple device management and security vendor Jamf. Until now, macOS campaigns needed to persuade users to launch infected applications through relatively intrusive techniques such as ClickFix social engineering or the expert user macOS ‘drag-to-terminal’ routine. MacSync Stealer, by contrast, is downloaded from an ordinary-looking utility URL as a code-signed and notarized Swift application. Once the user initiates installation, the dropper retrieves its malware payload script from a command-and-control server. One oddity is that the download still invites victims to launch it by right-clicking and opening, even though the signed executable does not technically need this for infection. The innovation lies with its deceptive provenance: because the malware is signed by what macOS deems to be a legitimate developer and has not shown up as malicious, no warnings or extra steps are needed. This draws attention to a weakness in Apple’s Gatekeeper security – criminals can constantly reformulate their malware to evade Apple’s automated detection and notarization system. This gives attackers a window for exploitation. According to Jamf, the malware’s certificate credential was only revoked after the company reported the issue to Apple. Sign of expansion MacSync Stealer is the latest example of an expanding number of economically motivated macOS malware. The purpose is to steal data from high-value users, including account credentials, API keys, and crypto wallet data. The malware’s origins lie with an earlier Mac infostealer, Mac.c Stealer, whose appeal was that it could be bought cheaply by budding cybercriminals. However, within weeks of its appearance in April, this was rebranded as MacSync and more advanced features were added. Another macOS stealer, the Odyssey infostealer, had also been observed using the same distribution technique. “While MacSync Stealer itself is not entirely new, this case highlights how its authors continue to evolve their delivery methods,” Jamf said. “This shift in distribution reflects a broader trend across the macOS malware landscape, where attackers increasingly attempt to sneak their malware into executables that are signed and notarized, allowing them to look more like legitimate applications.” While the Mac malware “market” might appear small in volume compared to that for Windows, this largely reflects the fact that PCs remain the primary operating system used by businesses. Nevertheless, criminals have noticed that the extra development time required for Mac malware is increasingly worth it. Examples targeting enterprises and high-value individuals from 2025 include the macOS Ferret family and BlueNoroff social media campaigns associated with North Korean hackers, both connected to crypto theft. Another is the Atomic malware-as-a-service (MaaS) infostealer associated with Russian cybercriminals. View the full article

Amazon’s chief security officer Stephen Schmidt writes that since April 2024, the company has stopped over 1800 job applications suspected of coming from North Korean agents. The number of applications linked to North Korea has also increased by about 27% per quarter in 2025. The purpose of the infiltration is said to be to obtain remote employment with foreign companies, mainly in the United States, and then transfer the income to North Korea’s weapons program. Amazon combines AI-based analysis with manual review to detect suspicious applications. Algorithms search for links to at-risk institutions, anomalies in applications, and geographic inconsistencies. Identities are verified through background checks, references, and structured interviews. According to Schmidt, the company has seen several recurring trends. Identity theft is becoming more sophisticated, with fraudsters posing as real developers. Hijacked LinkedIn accounts are being used to boost credibility, and AI and machine learning jobs are particularly vulnerable targets. Some operators use so-called “laptop farms” in the US to give the impression of local presence, and fake educational credentials from US universities are common. According to Amazon, even small details, such as phone numbers written with a country code of “1”, can help reveal fake profiles. Amazon says that the problem is likely to be industry-wide and urges other companies to review their identity verification practices and report suspicious cases to authorities such as the FBI. Related reading: North Korean group infiltrated 100-plus companies with imposter IT pros: CrowdStrike report How not to hire a North Korean IT spy North Korean hackers impersonated recruiters to steal credentials from over 1,500 developer systems North Korean fake IT workers up the ante in targeting tech firms View the full article

France’s postal service, La Poste, has been largely down for over twelve hours following a widespread network failure, reports The Register. All of La Poste’s IT systems are reportedly affected, including the website, the digital document service Digiposte, a digital ID service and the mobile app. It is still possible to handle cases over the counter. La Poste’s bank, Banque Postales, app and online services are also down. Payments and SMS verification should still work. La Poste has not said what caused the failure, but according to Le Monde Informatique it is a DDoS attack. It is unclear when the situation will be resolved and whether it could affect deliveries for Christmas. View the full article

Security firm Proofpoint has discovered that hackers have found a clever way to bypass multi-factor authentication (MFA) and thereby get their hands on accounts belonging to corporate users. In a nutshell, the hackers are using one-time codes from OAuth 2.0, an open standard that is supposed to be used to authenticate smart TVs and the like. Typically, the scammers pretend that a particular device needs a one-time code and get users to type the code into Microsoft’s authentication link. Once users do so, the hackers gain full access to their Microsoft 365 accounts with all their content. Both Russian and Chinese hackers have used this method, so there’s every reason for companies to tighten up their procedures. For additional reporting, see Hackers exploit Microsoft OAuth device codes to hijack enterprise accounts. View the full article

Outsourcing critical IT and cybersecurity once looked like a shortcut to efficiency. Today, it is a shortcut to systemic fragility. Breaches at one vendor now cascade across hundreds of organizations. A corporate decision framed as a cost-saving measure can trigger risks that extend across industries, even nations. The SolarWinds breach showed how a compromised supplier became a launchpad for global espionage. The MOVEit breach exposed how a single vulnerability could compromise sensitive data across governments, banks, and schools. If you sit on a board, lead a cyber function, or regulate markets, you can no longer treat outsourcing as a local concern. It is a systemic risk. Left ungoverned, outsourcing can magnify operational weaknesses, fuel cybercrime, and expose firms to geopolitical pressure. Left unchecked, it poses a threat to global economic security. This piece will guide you through the drivers of outsourcing, the risks it has unleashed, how these risks now escalate into systemic threats, the governance gap that enables them to thrive, and the responsibilities each stakeholder must shoulder. Why outsourcing took off The rise of outsourcing wasn’t a conspiracy. It was a rational response to competitive pressure. First came the economics. Outsourcing promised lower costs. A CIO could reduce headcount, offshore operations, and still meet budget targets without raising capital. Then came the talent squeeze. Security engineers were scarce. Outsourcing gave firms access to global pools of expertise. Cloud adoption turbocharged the trend. Instead of building everything in-house, firms leaned on managed services and third-party platforms to scale fast. Trust was often assumed, not engineered. The World Economic Forum has highlighted these “trust gaps.” Boards signed contracts with providers without embedding trust frameworks or demanding systemic assurances. Leaders gave vendors the keys to critical systems, with few checks on how those keys were safeguarded. You may save money and move faster. But if you fail to demand trust at the core, you inherit fragility. Risk categories of outsourced IT & cybersecurity When you outsource, responsibility shifts, but accountability never leaves you. The risks fall into clear categories. Operational risks The most basic risk is fragile continuity. In 2017, British Airways outsourced parts of its IT operations. A system outage grounded flights worldwide. The vendor contract delivered savings, but it also created single points of failure. When that single point snapped, the damage was immediate and global. A recent cyber-attack targeting airport check-in systems caused significant disruptions, including delays and system failures, across multiple European airports, such as Heathrow. It also reveals that the attack exploited vulnerabilities in shared infrastructure, raising serious concerns about the security of aviation support systems. Cyber risks SolarWinds remains the textbook case. Hackers compromised a widely used software update. Thousands of government agencies and Fortune 500 firms installed the backdoor, believing it came from a trusted vendor. MOVEit, a more recent breach, showed the same weakness in a different form: data transfer software was compromised, exposing millions of records across multiple jurisdictions. One weak vendor poisoned an entire ecosystem. AI-agent threats The rise of autonomous AI adds a new layer of complexity. WEF has flagged how cybercriminals are already deploying AI agents to automate attacks. Imagine outsourced IT monitored by tools vulnerable to hostile AI. A malicious agent can probe for weaknesses, adapt in real time, and exploit outsourced environments at scale. This is no longer science fiction; it is market reality. Compliance risks Cross-border outsourcing introduces accountability gaps. Regulators demand GDPR, DORA, or sector-specific compliance, but vendors spread data across multiple jurisdictions. When breaches occur, responsibility is blurred. Firms argue that vendors failed. Vendors say that clients misunderstood the model. Meanwhile, regulators and customers hold the original brand accountable. Geopolitical risks Outsourcing to hostile or unstable regions turns business contracts into national security concerns. In 2021, the Kaseya ransomware attack, launched through an IT management platform used by MSPs, spread through thousands of companies worldwide. The attackers operated from jurisdictions beyond the reach of effective law enforcement. Global security became hostage to one supply chain decision. Fresh case studies The risks are not historic. In 2023, hackers breached a Boeing subsidiary, disrupting the production of aircraft parts. A breach at UnitedHealth crippled healthcare payments across the US, leaving hospitals scrambling. These are not niche events. They serve as reminders that outsourcing can turn corporate risks into public crises. From local problems to systemic threats Outsourcing risks do not stay contained. They scale. SolarWinds showed how a single compromised supplier could infect the digital bloodstream of government and industry. The Colonial Pipeline ransomware attack disrupted fuel supply across the eastern United States. In 2025, ransomware at UnitedHealth halted healthcare reimbursements, disrupting a sector that affects millions. Economic disruption follows. Integrity360 has reported multiple 2025 global attacks with damages running into billions. A local failure in one vendor cascades through supply chains. If that vendor supports critical infrastructure, the consequences magnify. Global interdependencies make the weakest link the decisive one. Your cybersecurity posture may be robust. But if your vendor is compromised, you inherit their weakness. And if their subcontractor is compromised, the weakness doubles. This is why outsourcing is no longer a firm-level risk. It is systemic. The governance gap Why does this fragility persist? Because governance has lagged behind reality. Boards often focus on efficiency. They pressure executives to cut costs and accelerate digital adoption. But they fail to demand trust-based vendor oversight. They rarely ask how vendor risks are classified, monitored, or tested. They rarely challenge management on concentration risk. Regulators are fragmented. Some impose reporting rules. Others set sector-specific standards. But there is little global alignment. Cybercriminals exploit this patchwork. They attack through cross-border vendors, knowing compliance is reactive and uneven. CISOs face their own limits. They may demand audits, but their leverage over subcontractors is weak. Supply chain visibility fades after the first tier. Even when CISOs are aware of the risks, budget constraints, contracts, and governance inertia limit their ability to act. Add AI to the mix. Regulators have not yet prepared for AI-driven cybercrime. Many boards still view AI as an innovation story, rather than a threat multiplier. This blind spot will cost dearly when AI-driven attacks target outsourced environments. Towards responsible outsourcing Abandoning outsourcing is unrealistic. The task is to govern it responsibly. Trust by design. WEF has recommended embedding trust frameworks into outsourcing contracts. This means defining expectations for transparency, accountability, and resilience upfront. You cannot assume trust; you must structure it. AI resilience. Organizations must monitor outsourced environments for AI-agent threats. This requires investing in AI-native defenses, anomaly detection, and joint monitoring with vendors to ensure seamless integration. Vendor stress tests. Europe’s DORA and NIS2 regulations mandate stress testing of critical third parties. These should become global norms. Firms must treat vendors the way banks treat capital stress tests, by planning for failure before it occurs. Positive practices. Some firms are moving in the right direction. Banks are adopting multi-cloud strategies to reduce concentration risk. Zero-trust models ensure vendors only access what they need, when they need it. Continuous monitoring detects issues before they escalate and become more severe. The lesson is clear. Responsible outsourcing is not about cost arbitrage. It is about resilience design. Who must do what Risk ownership is collective. But responsibilities differ. Boards. You must demand trust-based vendor oversight. You cannot relegate vendor risk to a quarterly risk report; you must build it into governance charters. Demand resilience metrics. Approve investments in redundancy. Ask about the exit strategy in case a critical vendor fails. CISOs. You carry the operational burden. Map your critical vendor dependencies. Negotiate accountability clauses in SLAs. Do not accept vague promises. Push for real-time risk monitoring. Run tabletop exercises that include vendor failure scenarios. Integrate AI threat detection into third-party tracking. Regulators. You must align standards across borders. Fragmentation is a gift to cybercriminals. Mandate stress tests for systemic vendors. Demand transparency on subcontractors. Penalize opacity. Encourage information sharing across sectors. You cannot stop outsourcing, but you can ensure it is not blind outsourcing. Conclusion: Someone else can’t carry your risk Outsourcing will not disappear. In modern business, we weave it in, but if unmanaged, it risks systemic collapse. The new dimension is AI. Cybercriminals are deploying autonomous agents to probe outsourced ecosystems. At the same time, trust gaps persist. Organizations outsource without embedding frameworks of accountability. Boards chase efficiency. Regulators remain reactive. CISOs lack visibility. This is not sustainable. If outsourcing is to serve global competitiveness rather than undermine it, trust and resilience must be at its core. Boards must lead with oversight. CISOs must incorporate transparency into their contracts and monitoring processes. Regulators must harmonize and stress test. The choice is stark. Either you govern outsourcing with discipline, or outsourcing governs you with fragility. The elephant in the biz is not outsourcing itself. It is the delusion that someone else can carry your risk for you. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

A US federal securities class action lawsuit has alleged that South Korean ecommerce giant Coupang took nearly a month to disclose a massive data breach to regulators, violating SEC rules that require companies to report material cybersecurity incidents within four business days. The lawsuit, filed December 18, came just two days after Coupang finally submitted a Form 8-K disclosure to the Securities and Exchange Commission — 28 days after discovering the breach on November 18. The complaint alleges that CEO Bom Kim and CFO Gaurav Anand knew or recklessly disregarded that the company had “inadequate cybersecurity protocols” allowing a former employee to access customer data for nearly six months without detection. The breach exposed personal information from 33.7 million customer accounts, Coupang said. Disclosure deadline missed The SEC adopted cybersecurity disclosure rules in July 2023, requiring companies to disclose material incidents within four business days of determining materiality, under item 1.05 of Form 8-K. Companies can delay disclosure only if the US Attorney General determines it poses substantial national security or public safety risks. The complaint alleges that Coupang did not receive such an exemption. The company should have filed by November 24, following its November 18 discovery of the breach, but waited until December 16. Between discovery and disclosure, media reports prompted organizational upheaval. Park Dae-jun, CEO of Coupang’s South Korean operations, resigned December 10 after stating he would “take full responsibility for both the incident and the handling of the case.” Harold Rogers, Coupang’s general counsel and chief administrative officer, assumed the role of interim CEO of the Korean subsidiary. Coupang founder and CEO Bom Kim declined to appear at a South Korean parliamentary hearing about the breach, citing business obligations — a decision lawmakers condemned as a “systematic evasion of corporate responsibility.” Authentication keys left unrevoked after employee departure Investigators traced the breach to a former employee who retained valid authentication credentials after leaving the company in 2024, according to statements by South Korean lawmaker Choi Min-hee. The individual, a 43-year-old Chinese national, had worked on authentication management systems and joined Coupang in November 2022. Rep. Choi Min-hee, chair of the National Assembly’s Science, ICT, Broadcasting and Communications Committee, released analysis results in a November 30 press release pointing to failures in basic security procedures. The company failed to renew or revoke signing keys — the cryptographic credentials used to issue access tokens—when the employee left. “Abandoning a long-term valid authentication key was not simply a deviation by an internal employee, but the result of organizational and structural problems at Coupang that neglected the authentication system,” Choi said in the press release. Coupang’s own information to lawmakers indicated the company set token signing key validity periods of five to ten years, with rotation periods varying by key type. Legal test case for SEC cybersecurity rules Legal observers noted the Coupang lawsuit appears to be among the first securities class actions directly challenging compliance with the SEC’s 2023 cybersecurity disclosure guidelines. “This is a specific reason why I find the new Coupang lawsuit particularly interesting, and that is because one of the suit’s major allegations is that the company allegedly failed to make the requisite disclosures under the SEC’s cybersecurity disclosure guidelines,” legal journal, The D&O Diary, wrote in an analysis of the case. The complaint also alleges Coupang made materially false statements in quarterly reports filed in August and November 2025. Those reports incorporated risk disclosures from the company’s 2024 Annual Report detailing encryption technology and security measures — statements the complaint said “materially understated Coupang’s risk of a material cybersecurity event.” When Coupang finally filed its Form 8-K, the company stated it had activated incident response procedures, blocked unauthorized access, and reported the incident to Korean authorities. The filing acknowledged Korean regulators “will potentially impose financial penalties” but said the company could not reasonably estimate losses. Regulatory scrutiny in South Korea In South Korea, Coupang faces potential fines up to 1.2 trillion won ($814 million) under the Personal Information Protection Act, which requires companies to notify regulators within 24 hours of discovering a breach and maintain appropriate safeguards. South Korean police raided Coupang’s Seoul headquarters twice as part of their investigation. President Lee Jae Myung called for expanded class action lawsuit provisions, saying “every Korean has been affected” by the breach affecting nearly two-thirds of the country’s 51.7 million population. The lawsuit seeks to establish a class of investors who purchased Coupang securities between August 6 and December 16. Multiple law firms have announced they are investigating similar claims. A case management conference is scheduled for March 20. View the full article