CSOonline

Even the most seasoned CISOs sometimes run into insurmountable roadblocks at their organizations. Despite their best efforts at building relationships, and even with their technical depth and business acumen, they can’t garner the support needed to protect their organizations — and themselves — from pending disaster. In the big picture, CISO roles are hard, and so the majority of CISOs switch jobs every two to three years or less. Lack of support from senior leadership and lack of budget commensurate with the organization’s size and industry are top reasons for this CISO churn, according to The life and times of cybersecurity professionals report from the ISSA. More specifically, CISOs leave on account of limited board engagement, high accountability with insufficient authority, executive misalignment, and ongoing barriers to implementing risk management and resilience, according to an ISSA spokesperson. Many of these roadblocks are common across industries, so how does a CISO know when it’s time to move on? They look for the flags. Red flag: Playing lip service A common red flag and reason CISO’s leave their jobs is because leadership is paying “lip service” to auditors, customers and competitors, says FinTech CISO Marius Poskus, a popular blogger on security leadership who posted an essay about resigning from “security‑theater roles.” So, even before signing onto a new job, Poskus suggests looking for recent events proceeding the organization hiring its first-ever CISO. “I see this often. Usually after an impactful breach, they negotiate fines down by saying they’ll hire their first CISO. In fact, a friend in New Zealand reached out to me today with just such a story,” he tells CSO. Other indicators that executives are playing lip service to security include constant resource denials, lack of risk ownership, and failure to sign off on identified risks at the top level, leaving the CISO vulnerable. To this end, Poskus shared a security executive charter that outlines responsibilities of senior executives’ accountability around the cybersecurity program. And, since lack of access to the board is a top-cited reason for leaving, Poskus says to look for problematic reporting lines that block access to executives, such as through a boss who refuses to report issues and requests to executives. Red flag: Cognitive disconnect Lack of access to executives and the board comes up repeatedly in Cybersecurity Ventures reports as a top reason CISO’s decide to leave their jobs, according to Steve Morgan, founder of Cybersecurity Ventures. He cites lack of support as another top reason CISO’s leave. Splunk’s 2025 CISO report found 29% of respondents had adequate budget compared to 41% of boards who felt cybersecurity budgets were adequate. This cognitive disconnect was clear in Nawab Kabir’s case. He declined on the prospect of taking a full-time CISO role to become a fractional CISO after a merger left him reporting to an IT director rather than the CEO as he previously had reported to. “One of the key red flags for CISO’s is if their boss, usually the CIO or CTO, repeatedly blocks attempts to escalate missions to the CEO by downplaying the real risk, asking the CISO to accept that risk, and saying that the CEO simply doesn’t care. So, the risk never gets mentioned in executive leadership meetings,” Kabir says. After the merger, the initiatives and intervention strategies he developed never got past the director of IT (who came from the merger) to executive leadership. So, Kabir knew it was time to leave. “That’s one of the reasons I became a fractional cybersecurity leader, which I love because now I’m being hired to make a difference at my client companies.” Red Flag: Pushing ethical boundaries Above all these, the biggest red flag is when leadership pushes against your professional and personal ethics. For example, when a CEO or board wants to conceal compliance gaps, cover up reportable breaches, and refuse to sign off on responsibility for gaps and reporting failures they’ve been made aware of. “This happens more often than we know because most CISOs won’t make public what happened behind the scenes that made them quit, especially when they’re looking for new jobs,” Poskus explains. “Your integrity is your most important asset, so that’s the biggest red flag when we talk about leaving a role rather than staying and fighting.” In these types of scenarios, the CISO likely lacks critical allies within the organization. Acknowledge this sense of vulnerability, Poskus advises, because it’s a huge red flag. Human resources and legal teams in these situations won’t help because they owe their loyalty to the business, he adds. Such was the case with former Uber CISO Joe Sullivan who was thrown under the bus by Uber’s shady leadership after a 2016 breach. In contrast, SolarWinds CISO Tim Brown felt fully supported after a historic supply chain hack in 2020 spread to 18,000 business clients through its Orion network management product patch update system. “Joe was in such a difficult situation. The company was aggressive towards him, which was so different from my experience at SolarWinds,” says Brown, who had responded to the breach. Green flag: They have your back In contrast to Sullivan’s employer, Brown shares that everyone involved in responding to the SolarWinds breach — from IT responders to communications, legal, and executives — felt the same way he did in terms of making things right for clients and regulators. “My situation was difficult, but manageable in many ways because of that support from my team. From day one, we had no question about doing the right thing. We decided on transparency to our customers all the way through the SEC filings,” Brown explains. Even as a new CEO came onboard under a planned transition shortly after the breach, and as the SEC charged SolarWinds and Brown with fraud for certifying compliance with SolarWinds security shortly before the sophisticated supply-chain hack occurred, Brown has felt ongoing support. Given his access to the board and CEO, Brown knew well before the breach that the company had his back. He also points to another green flag: The company’s commitment to tabletop exercises of impactful breaches. Throughout the practice scenarios, teams worked together under a customer-centric mandate that advocated transparency and education, the same playbook that they followed in the 2020 breach. Ultimately, the SEC dropped its charges against Brown, and in November, he attended a virtual toast in his honor to celebrate the SEC dropping the case against him “without prejudice.” More than 200 CISOs of top companies joined, including co-host Joe Sullivan. Ultimately, as Brown had hoped, the entire experience provided teachable moments to help push the CISO role up the maturity curve. Changing internal mindsets As CISOs burn out or leave under stressful circumstances, many turn to fractional work as Kabir has. And, in his case, working with new clients gives him plenty of opportunities to turn red flags into green flags. For example, he points to lack of board access and resources. In many cases he steps into, the former cybersecurity leaders didn’t understand the business and talked technically over their executives’ heads. As a result, he’s had to convert fatigued, resistant executive teams that don’t want to repeat those experiences with a new cybersecurity leader. For these clients, he likes to call “all hands” to a meeting and conduct what he calls interactive “business continuity stress tests” in table-top scenarios that impact a revenue-generating activity. “Take manufacturing, if this machine is down for six to eight hours what would be our revenue costs associated with this downtime? That gets attention,” Kabir says. “Then finance starts talking within their teams and it goes beyond that to the CEO because now it’s seen as a business issue.” CISOs, then, can change culture to turn a red flag into a green flag. But knowing when and how to do so depends on the indicators mentioned. Even with a fractional role, CISOs should still expect some of their clients to try and compromise ethics by covering up findings for example. Fortunately, that red flag usually reveals itself early in the audit, when the executives and business units appear afraid to answer questions as if trying to hide something. “A lot of red flags have to do with lack of security culture or mismatch in understanding the risk tolerance of the company and what the actual risks are. This red flag goes beyond: If they don’t want to be questioned about what they’ve done so far, that is a huge red flag that they’re covering something up,” Kabir explains. To be safe, he carries indemnity insurance and retains his own legal counsel — as should all CISO’s with large enough salaries who are reporting to the board and C-suite. Because, as in the case with Joe Sullivan and many other examples that go unreported, CISO’s can’t count on their organizations to have their backs legally or professionally should the big one hit — especially if those executives, by virtue of their unresponsiveness and lack of support, are the cause of it. View the full article

Chim | shutterstock.com Die Softwarelieferkette – respektive ihre Schwachstellen – haben in den vergangenen Jahren für viel Wirbel gesorgt. Ein besonders schlagzeilenträchtiges Beispiel ist der Angriff auf den IT-Dienstleister SolarWinds, bei dem mehr als 18.000 Kundenunternehmen betroffen waren. Zwar war die Attacke beileibe nicht die einzige auf Softwarelieferketten – sie führte jedoch zu einer Neubewertung der Frage, wer dafür verantwortlich zeichnet. Eine Reaktion auf den SolarWinds-Angriff war beispielsweise Ex-US-Präsident Bidens “Executive Order on Improving the Nation’s Cybersecurity“. Der Erlaß hob nicht nur hervor, wie bedeutsam die Absicherung der Lieferketten ist, sondern stellt auch ausdrücklich die Verantwortung der Entwickler heraus, wenn es darum geht, sichere Software zu liefern. Zwar gilt die Anordnung ausschließlich für US-Regierungsbehörden und deren Geschäftspartner. Sie steht jedoch stellvertretend dafür, dass alle beteiligten Organisationen ihre Softwareanbieter überprüfen müssen, um sicheren Code bereitzustellen – unabhängig davon, ob ein Unternehmen nur Programme und Anwendungen für sich selbst entwickelt oder Teil der Softwarelieferkette Dritter ist. Das größte Problem dabei: Softwareentwickler wurden viele Jahre lang nahezu ausschließlich danach beurteilt, wie schnell sie programmieren können. Security war dabei entweder ein nachgelagerter Gedanke oder der Verantwortungsbereich Anderer. Zwar bilden sich viele Entwickler inzwischen in Sachen Cybersecurity fort, sie brauchen jedoch Hilfe, um sicherzustellen, dass ihr Code frei von Sicherheitslücken ist. Dazu können Tools für Dynamic Application Security Testing (DAST) und Static Application Security Testing (SAST) einen wertvollen Beitrag leisten. DAST- & SAST-Tools – was ist das? Es ist nicht überraschend, dass sowohl SAST- als auch DAST-Tools in Zusammenhang mit der Absicherung von Softwarelieferketten wieder an Bedeutung gewinnen. Schließlich geben sie den Entwicklern die Werkzeuge an die Hand, um sicheren Code bereitzustellen – entweder als Teil eines offiziellen DevSecOps-Programms oder um die Verantwortung für die Security näher an den Ort der Anwendungsentwicklung zu verlagern. Sowohl SAST- als auch DAST-Tools haben das Ziel, den Code sicherer zu machen. Im Idealfall geschieht das lange bevor eine Anwendung in eine Produktionsumgebung gelangt und Teil der Softwarelieferkette wird. Dabei verfolgen die Tools dasselbe Ziel, gehen das Problem aber aus unterschiedlichen Blickwinkeln an: SAST-Tools analysieren den Quellcode von Programmen und Anwendungen, die sich noch in der Entwicklung befinden. Sie lassen sich in eine CI/CD-Pipeline integrieren oder so konfigurieren, dass sie automatisch aktiv werden, wenn ein Entwickler eine Pull-Anfrage stellt. So können Tools für Static Application Security Testing sicherstellen, dass mit neuen Änderungen an einer Anwendung nicht unbeabsichtigt Schwachstellen hinzugefügt werden oder anderweitige Fehler entstehen. Einige SAST-Tools können auch Teil integrierter Entwicklungsumgebungen (IDE) werden. In diesem Fall warnt die Plattform die Entwickler während der Programmierarbeit vor Fehlern – ähnlich wie eine moderne Textverarbeitung mit Rechtschreibprüfung. DAST-Tools werden im Gegensatz dazu eingesetzt, nachdem eine Applikation kompiliert ist. Ein Tool für Dynamic Application Security Testing ist weniger dazu gedacht, Schwachstellen im Code aufzudecken (die ein SAST Tool im Idealfall bereits beseitigt hat), sondern fungiert als externer Tester, der versucht, ein Programm beispielsweise über offene http- oder HTML-Schnittstellen zu hacken. Einige DAST-Tools können auch konfiguriert werden, um nach Schwachstellen für gängige Angriffe in bestimmten Branchen wie dem Finanzwesen oder dem Einzelhandel zu suchen. Wegen der genannten Unterschiede müssen SAST-Tools die von Ihnen gewählte Programmiersprache unterstützen. Das Gros der DAST-Tools erfordert das nicht, obwohl diese Tools unter Umständen auch mit Quellcode arbeiten können, um Probleme zu lokalisieren. Während einige Unternehmen entweder ausschließlich ein DAST- oder ein SAST-Tool verwenden, empfiehlt es sich, eine Kombination aus beiden einzusetzen oder mit einem Tool zu arbeiten, das beide Komponenten enthält. Unternehmen, die das tun, sind in der Lage, ihre Applikationen besser zu schützen, was der Sicherheit der Softwarelieferkette insgesamt zuträglich ist. Dynamic Application Security Testing Tools: Top 4 Im Folgenden finden Sie einige der wichtigsten DAST- und SAST-Tools, die heute zum Einsatz kommen. 1. Acunetix DAST Die Acunetix DAST-Plattform nutzt DAST und IAST (Interactive Application Security Testing), um nach über 7.000 Schwachstellen in fertigem Code, Website-Designs oder Anwendungen zu suchen. Bei IAST wird der Scan- und Testcode in ein kompiliertes Programm eingebettet, ähnlich wie bei Debug-Symbolen. Somit kann Acunetix seine Scans starten, während ein Programm aktiv ausgeführt wird. auf diese Weise werden potenziell mehr Schwachstellen aufgedeckt als bei der Untersuchung einer Anwendung im Ruhezustand. IAST sollte auch die Zahl der Fehlalarme (im Vergleich zu SAST) verringern. Der Code für die Plattform ist aus Speed-Gründen in C++ geschrieben. Dabei exportiert die Plattform bis zu 90 Prozent ihrer Ergebnisse bereits, während der Scan noch nicht einmal zur Hälfte abgeschlossen ist. Die Benutzer können die Acunetix-Plattform so konfigurieren, dass sie einmalig ausgeführt wird oder Zeitpläne für wiederholte Tests im Laufe der Zeit einrichten. Und weil die Plattform so schlank ist, kann sie sogar mehrere Umgebungen gleichzeitig scannen, ohne dabei an Geschwindigkeit einzubüßen. 2. Opentext Fortify WebInspect Die ehemalige Fortify-WebInspect-Plattform von Micro Focus firmiert nach der Übernahme des Unternehmens durch Opentext unter dem Namen Fortify WebInspect. Sie ist als On-Premises-Installation, als Service oder als Kombination aus beidem innerhalb einer hybriden Umgebung verfügbar. Obwohl es als isoliertes DAST-Tool arbeitet, lässt es sich in CI/CD-Pipelines integrieren und kann auch von Entwicklern genutzt werden, die normalerweise nur SAST-Tools verwenden. Das Tool kann auch nur nach besonders kritischen Schwachstellen suchen und die Entwickler so vor schwerwiegenden Fehlern warnen, damit diese schon lange vor Bereitstellung behoben werden. Darüber hinaus ist dieses DAST-Tool auch in der Lage zu prüfen, ob der Code im Einklang mit staatlichen Regularien steht (NIST 800-53, PCI DSS, OWASP, HIPAA, etc.). Wird eine Schwachstelle entdeckt, visualisiert die Plattform das Problem mit einer grafischen Oberfläche und unterbreitet iterative Lösungsvorschläge. 3. Black Duck (ehemals Synopsis) Die DAST-Plattform von Black Duck ist auch als Managed Service verfügbar. Dadurch entfällt nicht nur interne Wartung und Management – das Unternehmen steht bei Bedarf auch mit Rat und Tat zur Seite, beispielsweise wenn Scan ein Problem aufwirft, mit dem das Entwicklungsteam überfordert ist. Das Tool deckt nicht nur alle gängigen Schwachstellen auf, die viele Programme plagen (etwa SQL-Injection oder Cross-Site-Scripting), sondern verfügt auch über einen manuellen Scan-Modus, mit dem Sie auch komplexeren Problemen gezielt auf dioe Spur kommen. Auch Sicherheitslücken in Zusammenhang mit Authentifizierungs-, Zugriffskontroll- und Session-Management-Fehlern, die bei herkömmlichen Scans nicht auftauchen, findet das Tool. 4. Tenable.io Web App Scanning Tenable ist unter den Sicherheitsanbietern eine Art Urgestein und ist in erster Linie für seine robuste, Cloud-basierte Vulnerability-Management-Plattform bekannt. Web App Scanning ist ein Teil dieser Plattform und fungiert als leistungsfähiges DAST-Tool. Die Tenable-App arbeitet nur mit Webanwendungen, führt aber einen tiefgehenden Scan durch, der sowohl HTML5 als auch Standard-HTML und AJAX abdeckt. Die App verfügt über eine simple Benutzeroberfläche, die auch für Teams zugänglich ist, die ohne Application-Security-Spezialisten auskommen müssen. Automatisierungen sind einfach einzurichten und die Benutzer können genau konfigurieren, welche Abschnitte des Programmcodes gescannt werden sollen. Davon abgesehen lässt sich der Web App Scanner auch als Standalone-Lösung verwenden – oder in eine andere Cybersecurity-Lösung von Tenable integrieren. Static Application Security Testing Tools: Top 5 1. Checkmarx SAST Das SAST-Programm von Checkmarx kombiniert fortschrittliche Funktionen mit einer der besten webbasierten Benutzeroberflächen für SAST-Tools. Die Benutzeroberfläche ermöglicht es auch Security-Unkundigen, sich zurechtzufinden. Checkmarx identifiziert nicht nur Schwachstellen, sondern erklärt auch, warum eine entdeckte Schwachstelle besonders riskant ist. Zudem erhalten Entwickler Tipps, wie die gefundenen Probleme am einfachsten und effektivsten beseitigt werden können. Standardmäßig unterstützt das Checkmarx-Tool über 25 Programmiersprachen. Zudem lässt sich die Anwendung so konfigurieren, dass sie automatisch als Teil einer CI/CD-Pipeline ausgeführt wird. Natürlich dürfen Sie auch benutzerdefinierte Abfragen einrichten und nach Bedarf ausführen und das Tool in alle gängigen IDE- oder Quellcode-Management-Plattformen integrieren. 2. Opentext Fortify Static Code Analyzer Sowohl SAST- als auch DAST-Elemente kombiniert Fortify Static Code Analyzer von Opentext. Als SAST-Plattform verwendet die Lösung eine übersichtliche, visuelle Schnittstelle, um Entwicklern die spezifischen Schwachstellen im Code (und Statistiken über die Art der regelmäßig aufgedeckten Schwachstellen) aufzuzeigen, die in 810 verschiedene Schwachstellenkategorien unterteilt sind. Anschließend werden die Entwickler zu einer Schulungsoberfläche weitergeleitet, die laut Anbieter interessante und unterhaltsame Lektionen über Security und sicheren Code bereithalten soll. Die Plattform unterstützt 27 Programmiersprachen und Frameworks und kann On-Premises oder als Service eingesetzt werden. Zudem lässt sie sich in die meisten gängigen IDEs wie Eclipse und Visual Studio integrieren. 3. Perforce Klocwork SAST Das SAST-Tool Klocwork setzt den Fokus auf Geschwindigkeit – selbst in den größten Umgebungen. Es funktioniert mit Anwendungen, die in C, C++, Java, JavaScript und Python kodiert sind – sogar innerhalb von Docker-Containern – und kann in jede größere IDE wie Visual Studio Code, IntelliJ und viele andere integriert werden. Laut Anbieter wurde Klocwork entwickelt, um ein SAST-Tool für komplexe Umgebungen zu realisieren. Mit Klocwork können Anwender riesige Codebasen scannen, die Millionen von Zeilen beinhalten. Um die Scan-Dauer zu verkürzen, werden beispielsweise nur die geänderten Codebereiche gescannt und nicht jedes Mal das gesamte Programm. Darüber hinaus hilft das SAST-Tool dabei, Entwickler in Sachen Security zu schulen: Es ist vollständig in die Schulungsplattform Secure Code Warrior integriert, die sich auf Sicherheits- und Awareness-Schulungen konzentriert. 4. Spectral SpectralOps-Plattform Check Point hat vor kurzem Spectral übernommen, aber das neue Unternehmen unterstützt weiterhin aktiv die SpectralOps-Plattform, wahrscheinlich auch wegen ihrer einzigartigen SAST-Funktionen. SpectralOps findet sensible Informationen wie API-Schlüssel, Anmeldeinformationen und Token, die Entwickler bei der Entwicklung von Programmen oft fest einkodieren. Die Idee dahinter: Fehlkonfigurationen aufzudecken, die den Zugriff auf geheime Informationen ermöglichen könnten, während sich ein Programm noch in der Entwicklung befindet. SpectralOps scannt kontinuierlich jeden Schritt im Lebenszyklus der Softwareentwicklung und nutzt Künstliche Intelligenz, um über 2.000 Erkennungs-Engines im Auge zu behalten. Um Fehlalarme in Zaum zu halten, finden auch nachgelagerte Tests statt. Im Anschluss kann das Tool seine Ergebnisse an Slack melden, ein Jira-Ticket ausstellen oder Entwickler über fast jede beliebige Kommunikationsplattform alarmieren. 5. Veracode Static Analysis SAST Die SAST-Plattform von Veracode ist ein Cloud Service – die komplexe Wartung einer SAST-Anwendung in Ihrer Umgebung entfällt damit. Sicherheitsanbieter Veracode arbeitet nach dem Prinzip des Just-in-Time-Learnings. Das bedeutet, anfälliger Code kann bereits bei der Programmierarbeit erkannt werden. Ist der Code korrigiert, erstellt die Veracode-Plattform ein Reporting, so dass Unternehmen sicherheitsbewusste Entwickler fördern und ermutigen können. Neben der Integration in eine IDE liegt der Schwerpunkt von Veracode auf Geschwindigkeit: Jeder Build eines Programms oder einer Anwendung kann automatisch gescannt werden, wobei die durchschnittliche Scan-Zeit bei lediglich 90 Sekunden liegt. Dabei wird durchgängig jede Aktion erfasst, was wiederum Audits erleichtert. 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

vectorfusionart – shutterstock.com Zwar stellen Cyberkriminelle und staatlich unterstützte Angreifer gerade für den Industriesektor eine enorme und steigende Gefahr dar. Dennoch besteht die größte Bedrohung derzeit im mangelnden Wissenstransfer, was OT-Sicherheit und -Organisation (Operational Technology) angeht. Das Hauptproblem sind vertrauenswürdige Mitarbeiter, die in Rente gehen. Diese Personen sind in der Regel engagiert, sachkundig und unersetzlich. Sie wissen, auf welchem unbeschrifteten Server das System zur Erfassung historischer Daten läuft, das die Aufsichtsbehörden verlangen. Sie erinnern sich daran, warum ein bestimmtes VLAN mit scheinbar zufälligen IP-Adressen konfiguriert wurde. Sie wissen, welche Netzwerkrouten nur unter Produktionsstillstand geändert werden können. Ihr institutionelles Wissen umfasst somit Tausende von IP-Adressen, undokumentierte Netzwerkrouten und versteckte VLANs, die in der offiziellen Dokumentation fehlen. Ihre Nachfolger hingegen bringen Erwartungen an moderne, gut dokumentierte Netzwerkarchitekturen mit. Stattdessen erben sie ein komplexes Geflecht aus Altsystemen, proprietären Protokollen und undokumentierten Konfigurationen, die das Ergebnis jahrzehntelanger schrittweiser Änderungen und Notfallkorrekturen sind. Die Diskrepanz zwischen Erwartungen und Realität führt zu einer Wissenslücke, die sowohl die Betriebskontinuität als auch die Cybersicherheit gefährdet. Hierbei handelt es sich jedoch um eine Art „Single Point of Failure“, den die meisten Unternehmen erst erkennen, wenn es bereits zu spät ist. Der Weggang erfahrener OT-Fachkräfte birgt drei kritische Risiken, die weit über einfache Personalprobleme hinausgehen und bei herkömmlichen Risikobewertungen meist unterschätzt werden: 1. Systemausfälle während der Modernisierung Das unmittelbare und schwerwiegendste Risiko besteht in unbeabsichtigten Folgen während System-Upgrades oder Modernisierungsmaßnahmen. Ältere OT-Netzwerke enthalten das, was Branchenexperten als „archäologische Schichten“ bezeichnen: Jahrzehntelange inkrementelle Modifikationen, Notfallkorrekturen und undokumentierte Konfigurationen, die versteckte Abhängigkeiten schaffen. Die größten Risiken: Nicht dokumentierte Altsysteme: Die meisten Produktionsstätten verfügen über mindestens ein Windows-NT- oder Windows-XP-System, auf dem unverzichtbare historische Daten gespeichert sind oder zentrale Prozesse gesteuert werden. Diese Systeme sind oft nicht hinreichend dokumentiert. Ihre Entfernung im Zuge von Modernisierungsmaßnahmen kann zum Verlust der Produktionsdaten von Jahrzehnten führen, die für die Einhaltung gesetzlicher Vorgaben erforderlich sind. Versteckte Netzwerkabhängigkeiten: IP-Routing-Tabellen, VLAN-Konfigurationen und Firewall-Regeln enthalten oft scheinbar willkürliche Einstellungen, die jedoch tatsächlich Netzwerkkonflikte verhindern oder die Kommunikation kritischer Systeme aufrechterhalten. Eine Änderung dieser Konfigurationen ohne institutionelles Wissen kann zu einem Dominoeffekt über mehrere Produktionslinien hinweg führen. Anforderungen an proprietäre Protokolle: Viele ältere Industriesysteme kommunizieren über proprietäre oder modifizierte Standardprotokolle. Die spezifischen Konfigurationsparameter, die diese Kommunikation ermöglichen, sind selten dokumentiert und existieren nur im institutionellen Wissen ausscheidender Mitarbeiter. Lesetipp: CISOs müssen OT-Risiken stärker adressieren 2. Verlängerte Time-to-Value für neue Geräte und Prozesse Der Verlust von spezifischem Know-how verlängert die Implementierungszeiten für neue Geräte, Prozessverbesserungen und Systemintegrationen erheblich. Dieser Effekt verstärkt sich mit der Zeit und führt zu Wettbewerbsnachteilen und verpassten Optimierungsmöglichkeiten. Herausforderungen bei der Implementierung: Komplexe Netzwerkintegration: Die Installation neuer Geräte, die früher nur wenige Tage dauerte, nimmt nun Wochen oder Monate in Anspruch. Der Grund: Die neuen Mitarbeitenden müssen die bestehenden Netzwerkkonfigurationen zunächst zurückentwickeln, um die Kompatibilität sicherzustellen. Ineffiziente Fehlerbehebung: Wenn Integrationsprobleme auftreten, müssen unerfahrene Mitarbeitende häufig Trial-and-Error-Ansätze anwenden, anstatt auf historische Kenntnisse ähnlicher Probleme und deren Lösungen zurückgreifen zu können. Abhängigkeit von Anbietern: Unternehmen sind zunehmend auf externe Systemintegratoren und Gerätehersteller angewiesen, um ihre eigenen Netzwerke zu verwalten. Das erhöht die Projektkosten und -laufzeiten erheblich. 3. Unbeabsichtigte Cybersicherheitslücken Ein verstecktes Risiko liegt in gut gemeinten Verbesserungen der Cybersicherheit, die tatsächlich die Angriffsfläche vergrößern. Das neue Personal, das in modernen IT-Sicherheitspraktiken geschult ist, implementiert häufig Lösungen, die für OT-Umgebungen ungeeignet sind oder unbeabsichtigt zuvor isolierte Systeme offenlegen. Häufige Muster für die Schaffung von Schwachstellen: Fehlerhafte Netzwerksegmentierung: Versuche, eine moderne Trennung in Netzwerksegmente zu implementieren, verbinden versehentlich zuvor isolierte Netzwerkteile miteinander. So entstehen neue Angriffspfade, die in der alten Konfiguration nicht existierten. Fehlkonfigurationen von Firewalls: Durch mangelnde Kenntnisse von Legacy-Protokollen können moderne Firewall-Implementierungen legitime industrielle Kommunikationen blockieren und gleichzeitig unbefugte Zugriffe nicht verhindern. Diese drei Hauptrisiken verstärken sich gegenseitig, wenn sie gleichzeitig auftreten. Dies ist immer häufiger der Fall, da Unternehmen versuchen, veraltete Infrastrukturen zu modernisieren und gleichzeitig den Wandel in der Belegschaft zu bewältigen. (jm) Lesetipp: KI schafft neue Sicherheitsrisiken für OT-Netzwerke View the full article

vectorfusionart – shutterstock.com Zwar stellen Cyberkriminelle und staatlich unterstützte Angreifer gerade für den Industriesektor eine enorme und steigende Gefahr dar. Dennoch besteht die größte Bedrohung derzeit im mangelnden Wissenstransfer, was OT-Sicherheit und -Organisation (Operational Technology) angeht. Das Hauptproblem sind vertrauenswürdige Mitarbeiter, die in Rente gehen. Diese Personen sind in der Regel engagiert, sachkundig und unersetzlich. Sie wissen, auf welchem unbeschrifteten Server das System zur Erfassung historischer Daten läuft, das die Aufsichtsbehörden verlangen. Sie erinnern sich daran, warum ein bestimmtes VLAN mit scheinbar zufälligen IP-Adressen konfiguriert wurde. Sie wissen, welche Netzwerkrouten nur unter Produktionsstillstand geändert werden können. Ihr institutionelles Wissen umfasst somit Tausende von IP-Adressen, undokumentierte Netzwerkrouten und versteckte VLANs, die in der offiziellen Dokumentation fehlen. Ihre Nachfolger hingegen bringen Erwartungen an moderne, gut dokumentierte Netzwerkarchitekturen mit. Stattdessen erben sie ein komplexes Geflecht aus Altsystemen, proprietären Protokollen und undokumentierten Konfigurationen, die das Ergebnis jahrzehntelanger schrittweiser Änderungen und Notfallkorrekturen sind. Die Diskrepanz zwischen Erwartungen und Realität führt zu einer Wissenslücke, die sowohl die Betriebskontinuität als auch die Cybersicherheit gefährdet. Hierbei handelt es sich jedoch um eine Art „Single Point of Failure“, den die meisten Unternehmen erst erkennen, wenn es bereits zu spät ist. Der Weggang erfahrener OT-Fachkräfte birgt drei kritische Risiken, die weit über einfache Personalprobleme hinausgehen und bei herkömmlichen Risikobewertungen meist unterschätzt werden: 1. Systemausfälle während der Modernisierung Das unmittelbare und schwerwiegendste Risiko besteht in unbeabsichtigten Folgen während System-Upgrades oder Modernisierungsmaßnahmen. Ältere OT-Netzwerke enthalten das, was Branchenexperten als „archäologische Schichten“ bezeichnen: Jahrzehntelange inkrementelle Modifikationen, Notfallkorrekturen und undokumentierte Konfigurationen, die versteckte Abhängigkeiten schaffen. Die größten Risiken: Nicht dokumentierte Altsysteme: Die meisten Produktionsstätten verfügen über mindestens ein Windows-NT- oder Windows-XP-System, auf dem unverzichtbare historische Daten gespeichert sind oder zentrale Prozesse gesteuert werden. Diese Systeme sind oft nicht hinreichend dokumentiert. Ihre Entfernung im Zuge von Modernisierungsmaßnahmen kann zum Verlust der Produktionsdaten von Jahrzehnten führen, die für die Einhaltung gesetzlicher Vorgaben erforderlich sind. Versteckte Netzwerkabhängigkeiten: IP-Routing-Tabellen, VLAN-Konfigurationen und Firewall-Regeln enthalten oft scheinbar willkürliche Einstellungen, die jedoch tatsächlich Netzwerkkonflikte verhindern oder die Kommunikation kritischer Systeme aufrechterhalten. Eine Änderung dieser Konfigurationen ohne institutionelles Wissen kann zu einem Dominoeffekt über mehrere Produktionslinien hinweg führen. Anforderungen an proprietäre Protokolle: Viele ältere Industriesysteme kommunizieren über proprietäre oder modifizierte Standardprotokolle. Die spezifischen Konfigurationsparameter, die diese Kommunikation ermöglichen, sind selten dokumentiert und existieren nur im institutionellen Wissen ausscheidender Mitarbeiter. Lesetipp: CISOs müssen OT-Risiken stärker adressieren 2. Verlängerte Time-to-Value für neue Geräte und Prozesse Der Verlust von spezifischem Know-how verlängert die Implementierungszeiten für neue Geräte, Prozessverbesserungen und Systemintegrationen erheblich. Dieser Effekt verstärkt sich mit der Zeit und führt zu Wettbewerbsnachteilen und verpassten Optimierungsmöglichkeiten. Herausforderungen bei der Implementierung: Komplexe Netzwerkintegration: Die Installation neuer Geräte, die früher nur wenige Tage dauerte, nimmt nun Wochen oder Monate in Anspruch. Der Grund: Die neuen Mitarbeitenden müssen die bestehenden Netzwerkkonfigurationen zunächst zurückentwickeln, um die Kompatibilität sicherzustellen. Ineffiziente Fehlerbehebung: Wenn Integrationsprobleme auftreten, müssen unerfahrene Mitarbeitende häufig Trial-and-Error-Ansätze anwenden, anstatt auf historische Kenntnisse ähnlicher Probleme und deren Lösungen zurückgreifen zu können. Abhängigkeit von Anbietern: Unternehmen sind zunehmend auf externe Systemintegratoren und Gerätehersteller angewiesen, um ihre eigenen Netzwerke zu verwalten. Das erhöht die Projektkosten und -laufzeiten erheblich. 3. Unbeabsichtigte Cybersicherheitslücken Ein verstecktes Risiko liegt in gut gemeinten Verbesserungen der Cybersicherheit, die tatsächlich die Angriffsfläche vergrößern. Das neue Personal, das in modernen IT-Sicherheitspraktiken geschult ist, implementiert häufig Lösungen, die für OT-Umgebungen ungeeignet sind oder unbeabsichtigt zuvor isolierte Systeme offenlegen. Häufige Muster für die Schaffung von Schwachstellen: Fehlerhafte Netzwerksegmentierung: Versuche, eine moderne Trennung in Netzwerksegmente zu implementieren, verbinden versehentlich zuvor isolierte Netzwerkteile miteinander. So entstehen neue Angriffspfade, die in der alten Konfiguration nicht existierten. Fehlkonfigurationen von Firewalls: Durch mangelnde Kenntnisse von Legacy-Protokollen können moderne Firewall-Implementierungen legitime industrielle Kommunikationen blockieren und gleichzeitig unbefugte Zugriffe nicht verhindern. Diese drei Hauptrisiken verstärken sich gegenseitig, wenn sie gleichzeitig auftreten. Dies ist immer häufiger der Fall, da Unternehmen versuchen, veraltete Infrastrukturen zu modernisieren und gleichzeitig den Wandel in der Belegschaft zu bewältigen. (jm) Lesetipp: KI schafft neue Sicherheitsrisiken für OT-Netzwerke View the full article

Threat actors tore through an Amazon Web Services environment in under eight minutes, chaining together credential theft, privilege escalation, lateral movement, and GPU resource abuse with the help of large language models, an attack so fast that defenders had virtually no time to react. According to new findings from Sysdig’s Threat Research Team, the intruders turned a single exposed credential in a public S3 bucket into full administrative control, demonstrating how AI‑assisted automation has collapsed the cloud attack lifecycle from hours to mere minutes. The operation, observed in November 2025, reportedly combined a cloud misconfiguration with large language models (LLMs) to compress the entire attack lifecycle. “The cybersecurity world today is brand new,” said Ram Varadarajan, CEO at Acalvio. “In this threat environment, organizations have to accept that the speed of the breach has shifted from days to minutes. Autonomous intruders can now escalate from initial access to full administrative control in minutes.” Defending against this class of attacks, he added, demands “AI-focused technology” that can reason and respond at the same speed as automated attackers.” Public Buckets to privilege escalation in minutes The compromise began with valid AWS credentials left exposed in public S3 buckets. Those buckets contained AI-related data, and the associated IAM user had permissions to interact with Lambda and limited access to Amazon Bedrock. “This user was likely intentionally created by the victim organization to automate Bedrock tasks with Lambda functions across the environment,” Sysdig researchers said in a blog post shared with CSO ahead of its publication on Tuesday. With read access across the environment, the attacker rapidly enumerated AWS services, then escalated privileges by modifying an existing Lambda function. By injecting malicious code into a function that already had an overly permissive execution role, the attacker was able to create new access keys for an administrative user and retrieve them directly from the Lambda execution output. Jason Soroko, senior fellow at Sectigo, said the root cause was depressingly familiar. “We must look past the novelty of AI assistance to recognize the mundane error that enabled it,” he said. “The entire compromise began because the victim left valid credentials exposed in public S3 buckets. This failure represents a stubborn refusal to master security fundamentals.” The Lambda code showed signs of LLM generation, including comprehensive exception handling, iterative targeting logic, and even non-English comments. Lateral movement, LLMjacking, and GPU abuse Once administrative access was obtained, the attacker moved laterally across 19 distinct AWS principals, assuming multiple roles and creating new users to spread activity across identities. This approach enabled persistence and complicated detection, the researchers noted. The attackers then shifted focus to Amazon Bedrock, enumerating available models and confirming that model invocation logging was disabled. The researchers said multiple foundation models were invoked, a pattern consistent with “LLMjacking”. Then, the operation escalated into resource abuse. After preparing keys and security groups, the attackers attempted to initiate high-end GPU instances for machine learning workloads. While most powerful instances failed due to capacity limits, a costly GPU instance was eventually launched, with scripts to install CUDA, deploy training frameworks, and expose a public JupyterLab interface. Some of the code was found referencing nonexistent repositories and resources, which Sysdig researchers attributed to LLM hallucinations. Experts argue that the most unsettling takeaway isn’t that AI introduced a new attack technique. It is that AI removed hesitation.“When you strip this attack down to its essentials, what stands out isn’t a breakthrough technique,” said Shane Barney, CISO at Keeper Security. “It’s how little resistance the environment offered once the attacker obtained legitimate access.” He warned that AI collapses reconnaissance, privilege testing, and lateral movement into “a single, rapid sequence,” eliminating the buffer time defenders have historically relied on. To reduce exposure, Sysdig researchers advised enforcing least privilege across IAM users, roles, and Lambda execution roles, tightly limiting permissions such as “UpdateFunctionCode” and “PassRole”, and ensuring sensitive S3 buckets are never public. Enabling Lambda versioning, turning on Amazon Bedrock model invocation logging, and monitoring for large-scale enumeration activity are also critical, they added. View the full article

Threat actors tore through an Amazon Web Services environment in under eight minutes, chaining together credential theft, privilege escalation, lateral movement, and GPU resource abuse with the help of large language models, an attack so fast that defenders had virtually no time to react. According to new findings from Sysdig’s Threat Research Team, the intruders turned a single exposed credential in a public S3 bucket into full administrative control, demonstrating how AI‑assisted automation has collapsed the cloud attack lifecycle from hours to mere minutes. The operation, observed in November 2025, reportedly combined a cloud misconfiguration with large language models (LLMs) to compress the entire attack lifecycle. “The cybersecurity world today is brand new,” said Ram Varadarajan, CEO at Acalvio. “In this threat environment, organizations have to accept that the speed of the breach has shifted from days to minutes. Autonomous intruders can now escalate from initial access to full administrative control in minutes.” Defending against this class of attacks, he added, demands “AI-focused technology” that can reason and respond at the same speed as automated attackers.” Public Buckets to privilege escalation in minutes The compromise began with valid AWS credentials left exposed in public S3 buckets. Those buckets contained AI-related data, and the associated IAM user had permissions to interact with Lambda and limited access to Amazon Bedrock. “This user was likely intentionally created by the victim organization to automate Bedrock tasks with Lambda functions across the environment,” Sysdig researchers said in a blog post shared with CSO ahead of its publication on Tuesday. With read access across the environment, the attacker rapidly enumerated AWS services, then escalated privileges by modifying an existing Lambda function. By injecting malicious code into a function that already had an overly permissive execution role, the attacker was able to create new access keys for an administrative user and retrieve them directly from the Lambda execution output. Jason Soroko, senior fellow at Sectigo, said the root cause was depressingly familiar. “We must look past the novelty of AI assistance to recognize the mundane error that enabled it,” he said. “The entire compromise began because the victim left valid credentials exposed in public S3 buckets. This failure represents a stubborn refusal to master security fundamentals.” The Lambda code showed signs of LLM generation, including comprehensive exception handling, iterative targeting logic, and even non-English comments. According to an AWS spokesperson, AWS services and infrastructure are not affected by this issue, and they operated as designed throughout the incident described. “The report describes an account compromised through misconfigured S3 buckets. We recommend all customers secure their cloud resources by following security, identity, and compliance best practices, including never opening up public access to S3 buckets or any storage service, least-privilege access, secure credential management, and enabling monitoring services like GuardDuty, to reduce risks of unauthorized activity. AWS customers who suspect or become aware of malicious activity within their AWS accounts should follow guidance for remediating potentially compromised AWS credentials or contact AWS Support for assistance.” Lateral movement, LLMjacking, and GPU abuse Once administrative access was obtained, the attacker moved laterally across 19 distinct AWS principals, assuming multiple roles and creating new users to spread activity across identities. This approach enabled persistence and complicated detection, the researchers noted. The attackers then shifted focus to Amazon Bedrock, enumerating available models and confirming that model invocation logging was disabled. The researchers said multiple foundation models were invoked, a pattern consistent with “LLMjacking”. Then, the operation escalated into resource abuse. After preparing keys and security groups, the attackers attempted to initiate high-end GPU instances for machine learning workloads. While most powerful instances failed due to capacity limits, a costly GPU instance was eventually launched, with scripts to install CUDA, deploy training frameworks, and expose a public JupyterLab interface. Some of the code was found referencing nonexistent repositories and resources, which Sysdig researchers attributed to LLM hallucinations. Experts argue that the most unsettling takeaway isn’t that AI introduced a new attack technique. It is that AI removed hesitation.“When you strip this attack down to its essentials, what stands out isn’t a breakthrough technique,” said Shane Barney, CISO at Keeper Security. “It’s how little resistance the environment offered once the attacker obtained legitimate access.” He warned that AI collapses reconnaissance, privilege testing, and lateral movement into “a single, rapid sequence,” eliminating the buffer time defenders have historically relied on. To reduce exposure, Sysdig researchers advised enforcing least privilege across IAM users, roles, and Lambda execution roles, tightly limiting permissions such as “UpdateFunctionCode” and “PassRole”, and ensuring sensitive S3 buckets are never public. Enabling Lambda versioning, turning on Amazon Bedrock model invocation logging, and monitoring for large-scale enumeration activity are also critical, they added. View the full article

The popular open-source text editor Notepad++ was targeted in a sophisticated supply chain attack that allowed Chinese state-sponsored hackers to deliver malware through compromised software updates, the project’s maintainer disclosed in a blog post. The attack, which ran from June through December 2025, involved infrastructure-level compromise of Notepad++’s shared hosting provider that enabled threat actors to selectively intercept and redirect update traffic to servers under their control, Notepad++ author Don Ho said in the statement. “Multiple independent security researchers have assessed that the threat actor is likely a Chinese state-sponsored group, which would explain the highly selective targeting observed during the campaign,” Ho wrote. The incident highlights a critical blind spot in enterprise security. Attackers prize distribution points like update servers because one successful insertion delivers access to thousands of environments at once, according to a Forrester analysis also published Sunday. The compromise is particularly concerning because Notepad++ is widely used by developers, analysts, and IT operators, yet “does not require an enterprise contract or license, and does not include usage tracking by default and therefore may not be tracked in an enterprise software inventory,” Forrester analysts Jeff Pollard, Allie Mellen, Jess Burn, Janet Worthington, and Tope Olufon wrote in their blog post. How the attack unfolded The compromise occurred at the hosting provider level rather than through vulnerabilities in Notepad++ code, Ho said in the note. Attackers gained access to the shared hosting server and redirected traffic from the update endpoint to attacker-controlled servers. “The bad actors specifically searched for the Notepad++ domain to intercept the traffic to your website, as they might know the then-existing Notepad++ vulnerabilities related to insufficient update verification controls,” the hosting provider said in a statement shared by Ho. The name of the hosting provider, however, is not disclosed in the blog post. A detailed query seeking comments from Ho remains unanswered. The server was initially compromised until September 2, 2025, when scheduled maintenance included kernel and firmware updates. However, attackers maintained stolen credentials to internal services until December 2, 2025, allowing continued traffic interception, according to the provider’s statement. The targeting was highly selective — traffic from certain users was redirected while most legitimate updates proceeded normally, Ho said. Rapid7 identifies custom malware Cybersecurity firm Rapid7 also published a detailed technical analysis corroborating Ho’s disclosure and identifying the attack as part of a broader campaign deploying previously undocumented malware. Rapid7’s investigation uncovered a custom backdoor the firm dubbed “Chrysalis,” alongside Cobalt Strike and Metasploit frameworks. “Forensic analysis conducted by the MDR team suggests that the initial access vector aligns with publicly disclosed abuse of the Notepad++ distribution infrastructure,” Rapid7 researcher Ivan Feigl wrote. The Chrysalis backdoor supports 16 distinct command capabilities ranging from interactive shell access to complete self-removal. One loader variant exploited Microsoft Warbird, an internal code protection framework, to execute shellcode while masquerading as a legitimate Microsoft-signed binary. Rapid7 attributed the campaign to Lotus Blossom, also known as Billbug, a Chinese APT group active since 2009, known for espionage operations targeting government, telecommunications, and critical infrastructure sectors across Southeast Asia and Central America. The attribution is based on strong similarities to previously published Symantec research, particularly the use of a renamed Bitdefender executable to side-load malicious DLLs. Why detection proved difficult The sophisticated malware evaded detection for months largely because a compromised utility blends into normal developer behavior, making it challenging to identify. “Most EDR programs are blind by design to ‘expected’ developer behavior,” the Forrester analysts wrote. “A compromised utility does not need exploits, LOLBins, or exotic malware. It just needs to look boring—like something a dev would do.” Ho noted that his incident response team was unable to extract concrete indicators of compromise despite analyzing roughly 400 GB of server logs. In an edit posted Sunday, Ho acknowledged Rapid7’s more detailed findings. “Last evening I received an email from Ivan Feigl (Rapid7) to share their excellent investigation story—it seems to be the same story, and obviously, they have more tangible information (including IoCs) than I do,” he wrote. Rapid7 identified network infrastructure, including IP addresses in Malaysia and China, along with command and control URLs, including api.skycloudcenter.com and api.wiresguard.com. Security enhancements and broader implications In response, Notepad++ has migrated to a new hosting provider and enhanced WinGup (the updater component) in version 8.8.9 to verify both certificate and signature of downloaded installers, Ho said. Certificate and signature verification will be enforced starting with version 8.9.2, expected within approximately one month. “I deeply apologize to all users affected by this hijacking,” Ho wrote. “I recommend downloading v8.9.1 and running the installer to update your Notepad++ manually.” For enterprise security teams, the incident underscores the need for comprehensive software inventories that include widely used utilities, cryptographic verification of all updates, and what Forrester described as a “shift from implicit trust to continuous verification.” The Forrester analysts also warned that AI agents could amplify similar risks. “The same supply chain blind spots that let a compromised tool blend into developer noise will let a compromised agent establish persistence and elevate privileges at scale,” they wrote. Organizations that cannot strictly define what should execute and communicate are “structurally conceding this class of attack.” View the full article

Early experimentation with agentic AI has given CISOs a preview of the possible cybersecurity nightmares ahead. But with autonomous agent adoption expected to soar throughout 2026, CISOs’ lack of visibility into agentic identities, activities, and decision-making is set to get far worse in quick measure. Agentic use will vary by enterprise, but analysts, consultants, and security vendors agree that their numbers will expand far beyond CISOs’ ability to maintain control as they simultaneously navigate the price of decades of identity governance neglect for non-human identities (NHIs), including service accounts, OAuth tokens, embedded API keys, and automation credentials. Ishraq Khan, CEO of coding productivity tool vendor Kodezi, sees most enterprises today housing 8 to 10 million such identities, a figure he projects will hit 20 to 50 million by year’s end. Jason Sabin, CTO at DigiCert, predicts an even steeper rise, with enterprises’ identity role calls increasing 10 times by January 2027. “We need to rethink how identity and data provisioning is done and put in place the right processes that can scale with the growth of agentic identities,” says Justin Greis, CEO of consulting firm Acceligence and former head of the North American cybersecurity practice at McKinsey. “You simply cannot apply human processes to something that will scale at this rate.” Visibility is the bigger problem As bad as that massively expanding identity universe is, the bigger problem may be how little visibility CISOs have into NHIs, with AI agents offering not just the fastest growth but the least visibility. Jason Andersen, principal analyst for Moor Insights & Strategy, estimates 25% NHI visibility for enterprise CISOs today. “The remaining 75% is in the shadows,” he adds. Those shadows include “semi-shadow” activities, such as third parties or lines of business that have been given permission to experiment with agentic AI but have not necessarily alerted IT or security teams about what they are doing. Still, Andersen sees that number getting a lot worse, projecting visibility to drop to about 12% by year-end and then into the single digits by January 2028. “And then they’ll likely fix it,” he says, adding, “It’s a big frickin’ problem.” Gartner analysts Jeremy D’Hoinne and Akif Khan agree CISOs face urgent problems in this area today. NHIs are going to be “several orders of magnitude larger than human identities and most organizations do not have a strong enough foundation to manage both machine and agentic identities,” Gartner’s Khan says. Enterprise CISOs are “blind to what is happening. The numbers are going to be overwhelming,” D’Hoinne adds. Forrester expects similar outcomes for CISOs. “There is going to be an explosion of non-human identities,” says Forrester analyst Geoff Cairns. “The exponential growth is indisputable.” Kodezi’s Khan notes that the lack of a robust base for NHI governance — now including agentic AI — is a critical problem. “Enterprises never solved non-human authentication so we don’t have the systems in place for a good secure environment. At its core, we never had the right foundation. That means that we will never have that perfect inventory,” he explains. Cost effective fix: Do nothing Kodezi’s Khan offers an interesting fix for that foundational problem: Don’t even try. He argues it’s a money pit that will never be fully resolved. Instead, he suggests pouring resources into creating a strict identity strategy for every NHI going forward. “Aim for containment rather than for perfection. You can’t really govern every identity, but if you start now, you can govern future actions,” he says, adding that, over the years, the percentage of uncontrolled identities will slowly drop as millions more identities are added. Nik Kale, principal engineer at Cisco and member of the Coalition for Secure AI (CoSAI) and ACM’s AI Security (AISec) program committee, agrees with that assessment. “If you are drowning, you don’t start by draining the ocean.” “The ratios tell you why this is so ungovernable. These identities are growing much faster than the discovery capabilities,” Kale notes. “It becomes a math problem at that point.” As for the path forward, Kale advises not to try to fix the legacy situation. “You just have to contain it, segment it, assume it’s compromised and that it’s hostile territory,” he says. “The plan needs to be containment plus a clean slate going forward. Inventory all non-human identities. Identify which have standing versus just-in-time access. Assign ownership to every one of them. No product required — just a terrifying spreadsheet.” Kale adds that cleaning IDs from now on will deliver a better benefit to CISOs. “In my opinion, the ratio matters less than the governance gap. Whether it’s 200:1 or 500:1, if IAM [identity access management] only manages 44% of them, the attack surface is already unmanageable,” he says. But he stresses that NHIs — especially when agentic — can be particularly difficult to find, let alone control. “Most organizations are undercounting by two to three times because machine identities are scattered across cloud consoles, repos, config files, and secrets managers that nobody’s aggregating,” Kale says. “Agentic AI is a multiplier, not an addition. Agents spawn subagents, create credentials dynamically, and establish agent-to-agent auth chains. One agent deployment can generate dozens of new machine identities.” Sanchit Vir Gogia, chief analyst at Greyhound Research, sees a reckoning ahead. “The enterprise control plane has quietly shifted from humans to machines, while governance stayed behind,” he says. “Once nonhuman identities outnumber humans by hundreds to one, identity stops being an administrative discipline and becomes the operating system of trust. The failure mode is not that there are too many identities; it is that enterprises cannot assert intent, ownership, and accountability for what those identities are doing at runtime.” Moreover, the situation is intensifying thanks to today’s business environment. “This is compounded by incentive structures that reward speed and uptime while penalizing breakage, which leads teams to overpermission machines by default,” Gogia says. “Overpermission is invisible until it is catastrophic. At that point, audits, roles, and reviews offer comfort but not control.” Agentic didn’t start the fire None of this situation was caused by agentic AI, Gogia underscores. “Enterprises did not enter a machine identity crisis because of agentic AI. They entered it years ago through service accounts, embedded API keys, long lived tokens, and automation credentials that were created to keep systems moving and then quietly forgotten,” he says. “What agents change is velocity and reach. They inherit trust and then operationalize it at machine speed. A legacy identity that once represented a contained risk now becomes an execution layer across systems, vendors, and workflows.” Gogia adds: “The most dangerous assumption in enterprise security today is that valid identity implies safe behavior. In machine-driven environments, credentials are often correct and activity is authorized, yet outcomes are harmful. Machines do not follow joiner-mover-lever models. They do not pause for approvals. They operate continuously and propagate actions automatically.” As a result, decision-making agents, layered into operations, achieve a rate of action that “collapses the window for detection,” he says. “The failure shifts from prevention to detection lag. By the time humans understand what happened, the agent already did it.” This should — and likely will — cause a rethinking from both enterprise CISOs and CIOs, he says. “This moment tests leadership alignment. CIOs are under pressure to deploy agents for productivity and scale. CISOs are staring at accountability gaps, forensic complexity, and cascading blast radius. If these agendas diverge, the enterprise ends up with autonomy without responsibility. Boards will ask who owns an agent, who sets its boundaries, and who answers when it causes harm,” Gogia explains. “The next phase of governance will require responsibility mapping for agents, separation of duties for high impact actions, and clear human checkpoints where judgment truly matters,” he adds. “Incident response must also evolve toward reconstructing chains of machine decisions, not just tracing logins.” View the full article

Today’s applications are based on numerous components, each of which, along with the development environments themselves, represents an attack surface. Regardless of whether companies develop code in-house or rely on third-party vendors, CISOs, security experts, and developers should pay particular attention to the software supply chain. These risks include, for example, React2Shell, Shai-Hulud, and XZ Utils — all vulnerabilities in the software supply chain that started small and later had massive repercussions. Shai-Hulud stands out in particular, signaling the end of the “passive era” of supply chain attacks and the beginning of the “active worm” era. This shift promises devastating consequences for software pipelines. Traditionally, supply chain attacks were passive traps. An attacker would upload a misspelled package (typosquatting), such as “reqeusts” instead of “requests,” sit back, and wait for a complacent developer to make a mistake. The blast radius was linear and rather slow. Shai-Hulud changed the rules of the game by introducing a worm-like propagation method. Once it lands on a developer’s machine, it actively collects credentials (NPM tokens, GitHub secrets). It uses these stolen credentials to automatically publish infected versions of other legitimate packages managed by the victim. Unlike spyware, which aims to remain hidden, variants of Shai-Hulud include a “dead man switch.” If it detects that it is being blocked or analyzed, it attempts to wipe the victim’s system, completely erasing all traces of itself. The goal is no longer just the application, but the developer’s identity and the automated CI/CD pipelines that implicitly trust them. What if the next iteration of Shai-Hulud affected other coding languages? Programming languages ​​as ticking time bombs One example of this is Python, the language of AI and data science. The next evolutionary stage of the supply chain worm will likely not only steal AWS keys but also leverage the rise of AI coding assistants. Security researchers are already observing “hallucination hijacking,” in which attackers register packets whose existence AI tools falsely predict. A worm like Shai-Hulud could infect a data scientist’s laptop, scan their local LLM chat history for private packet names, and automatically register malicious versions publicly. A worm in this ecosystem would not only crash a website but could also subtly poison financial models, alter medical research data, or insert backdoors into corporate AI training sets — damage that could potentially go undetected for years. Other examples could involve the coding languages ​​Java/JVM or Rust/Go; here too, the effects would be catastrophic. The polyglot supply chain attack The most frightening prospect, however, is the convergence of these threats in a polyglot supply chain attack. Currently, security teams operate in isolation. AppSec monitors the code, CloudSec monitors the cloud, NetworkSec monitors the perimeter. A polyglot attack is designed to seamlessly break through these silos. This happens as follows: A worm infiltrates a frontend developer’s laptop via a low-level JavaScript dependency. It detects that the developer also has access to the company’s backend Rust repository, steals these credentials, and injects malicious build scripts into the Rust CI pipeline. The Rust pipeline then deploys a compromised binary to a Kubernetes cluster. The attack could begin in NPM but end as a compiled binary backdoor in the production cloud infrastructure. The JavaScript security team won’t detect it because it immediately left their domain. The cloud security team would also miss the threat because it was delivered from a trusted CI pipeline using valid credentials. CISOs need to be aware of this and take appropriate precautions Recommendations for CISOs The EU Cyber ​​Resilience Act (CRA) provides recommendations for CISOs. It mandates the protection of digital products for manufacturers, importers, and distributors, encouraging them to invest in secure design during development and maintenance. The requirements outlined therein must be implemented gradually by the end of 2027, and include the security of networked hardware and software through the handling of vulnerabilities and their publication or notification to the relevant authorities. Furthermore, the three aforementioned stakeholders must also document the components of the software in software bills of materials (SBOMs). The NIS2 Directive, which has now entered into force, contains similar requirements for operators of critical infrastructure (KRITIS) to those stipulated in the NIS2 Implementation Act (NIS2UmsuCG) and the KRITIS Umbrella Act regarding products and suppliers. OpenKRITIS provides a worthwhile overview. To protect themselves from Shai-Hulud and similar threats, CISOs and their teams should implement the following steps: You must end the “implicit trust” in identities. In the scenarios described earlier involving Shai-Hulud, the problem was that CI/CD systems were too often blindly trusted. Therefore, CISOs should ensure their teams critically examine their pipeline security. CI/CD systems must not automatically assume an activity is legitimate simply because it was signed with a valid developer token. Instead, they must prioritize identity protection. Attackers have already been observed specifically stealing credentials such as NPM tokens and GitHub secrets to automatically publish infected packages. Measures to protect these identities must therefore be given top priority. Security silos should be broken down. Many security aspects still aren’t consolidated under a single, overarching management structure. Tools and departments dedicated to application security, infrastructure security, cloud security, network security, and many others create numerous islands within the vast sea of ​​security strategy. They all need to collaborate more closely and be coordinated by the CISO. A key risk is the previously described polyglot supply chain attack, which seamlessly transcends these silos. Therefore, CISOs must implement cross-departmental and cross-functional monitoring. To further illustrate the danger: An attack could begin with a JavaScript file, propagate through build scripts, and ultimately result in a backdoor in the cloud. Often, there’s no integrated visibility to track this entire process. The JavaScript team might lose sight of the attack once it leaves its sphere, while the cloud team relies on the CI pipeline. CISOs must therefore establish systems that monitor the entire path from software development to build and all the way to runtime. SBOMs, which document all software used, provide a solution. Prepare for active worms and ensure the protection of AI tools. To mitigate AI-driven risks, it’s crucial to prevent the hijacking and manipulation of AI tools. Numerous software developers rely on these tools to write their software. Security researchers are already observing attackers using packets that cause AI tools to hallucinate. Active worms represent the next level of threat. Therefore, security strategies should extend beyond simply protecting against typos. Threats like Shai-Hulud spread exponentially, like a worm. At this speed, manual packet inspection processes are no longer sufficient. This type of supply chain worm also features a “dead man switch” that wipes the victim’s system if an analysis is detected. CISOs should ensure that logs are secured even outside the developer’s machine to preserve traces of the attack for forensic investigations. View the full article

intersoft consulting services AG Montagmorgen, 8:00 Uhr. Die Mitarbeitenden können sich nicht einloggen. Die Produktionsbänder stehen still, und auf den Bildschirmen prangen digitale Erpresserschreiben. Der Albtraum eines jeden CIOs ist wahr geworden: Ein Ransomware-Angriff hat den Betrieb lahmgelegt. Jetzt endet der Regelbetrieb, und der Ausnahmezustand beginnt. Für Joanna Lang-Recht, Director IT Forensics und Prokuristin bei der intersoft consulting services AG in Hamburg, ist dies der Alltag. Sie leitet eine hochspezialisierte Eingreiftruppe, die den Tathergang rekonstruiert und den Schaden eindämmt, während die anderen tief im Chaos versinken. „Man kann sich das tatsächlich ähnlich vorstellen wie in der kriminalistischen Forensik“, erklärt Lang-Recht. Doch die Realität habe dann doch wenig mit grellen Taschenlampen in dunklen Räumen zu tun, auch wenn die Parallelen in der Vorgehensweise zu erkennen seien. „Wir sammeln keine Schmauchspuren oder Fußabdrücke, wie konzentrieren uns auf Spuren im digitalen Raum“, so die Forensikerin. Wenn Cyberkriminelle zuschlagen, hinterlassen sie trotz aller Verschleierungstaktiken digitale Fragmente. Das können Logfiles sein, veränderte Zeitstempel oder Fragmente im Arbeitsspeicher. All das sind Puzzleteile, aus denen Lang-Recht und ihr Team das Bild des Angriffs zusammensetzen. Ihr Motto: Rekonstruieren statt Spekulieren. Doch bevor die detektivische Arbeit beginnen kann, müssen Unternehmen erst einmal aus der Schockstarre herausfinden. Zwischen Panik und Paralyse Ransomware-Angriffe folgen meist einem perfiden Timing. Beispielsweise wissen die Täter genau, wann IT-Abteilungen besonders verwundbar sind. „Häufig finden solche Angriffe über das Wochenende oder an Feiertagen statt“, berichtet die Expertin aus Hamburg in dem Podcast TechTalk Smart Leadership von COMPUTERWOCHE und CIO-Magazin. Die „Encryption-Phase“, in der die Daten des Opfers verschlüsselt werden, laufe dann von Freitag- bis Sonntagabend durch. Wenn die Belegschaft am Montag ins Büro kommt, sei das Unheil bereits geschehen. Die erste Reaktion in den betroffenen Unternehmen beschreibt Lang-Recht als einen Zustand absoluter Panik. „Wir reden hier von einem wirklichen Ausnahmezustand“, betont sie. Keine E-Mails, kein Zugriff auf Kundendaten, keine Produktion. In diesem ersten „Stadium der Akzeptanz“, wie Lang-Recht es nennt, würden oft die größten Fehler gemacht, die eine spätere Aufklärung massiv erschweren könnten. Der menschliche Impuls sei verständlich: Man möchte retten, was zu retten ist. Doch die Forensikerin warnt eindringlich vor Aktionismus. „Wir sehen häufig, dass IT-Teams gleich versuchen, zu bereinigen oder Backups einzuspielen, bevor sie überhaupt wissen, was passiert ist.“ Warum der Stecker nicht gezogen werden darf Lang-Recht empfiehlt, die Systeme vom Internet zu trennen, aber nicht auszuschalten. Das Herunterfahren eines Servers könne einen „forensischen Suizid“ bedeuten. „Das vernichtet wertvolle Hinweise“, erklärt sie. Viele Angreifer hinterlassen demnach Spuren im RAM-Speicher. Wird der Strom gekappt, sind diese Informationen unwiederbringlich verloren. Die Daten sind aber essenziell, um zu verstehen, wie die Hacker sich im Netzwerk bewegt haben (Lateral Movement) und ob sie noch aktiv sind. Die korrekte Vorgehensweise, so die Expertin, sei die Isolierung. „Die Verbindungen zu Dienstleistern, Kunden und Lieferanten sollten gekappt werden, um die Supply Chain nicht zu gefährden.“ Erst wenn die Infrastruktur in sich gesichert sei, beginne die eigentliche Arbeit der Forensik. Und diese erfordere oft das Auffahren schwerer Geschütze. Die Dimension von Cyberangriffe sprenge nämlich nicht selten die verfügbaren Speicherkapazitäten vor Ort. Um forensische Images – exakte 1:1-Kopien der Datenträger – zu erstellen, müssen laut Lang-Recht riesige Datenmengen gesichert und analysiert werden. Sind aber hunderte Server und tausende Clients zu untersuchen, werden die Verantwortlichen an physikalische Grenzen stoßen. Wer steckt hinter den Angriffen? Das Bild vom einsamen Hacker im Hoodie, der zwischen Pizzaschachteln im Keller hockt, ist laut Joanna Lang-Recht unrealistisch. „Wir haben es mit hochprofessionellen Tätergruppen zu tun“, stellt sie klar. Die Cyberkriminalität hat sich industrialisiert. Das Geschäftsmodell „Ransomware-as-a-Service“ (RaaS) dominiert den Markt. Die Gruppierungen seien wie mittelständische Betriebe aufgestellt. Sie verfügten oft sogar über Personalabteilungen, die Entwickler anwerben, und über Marketingabteilungen, die den Brand der Hackergruppe pflegten. Nicht selten hätten sie sogar einen mehrsprachigen Kundensupport installiert. „Wenn man in die Verhandlung geht, hat man es tatsächlich teilweise mit einem First-Level- und einem Second-Level-Support zu tun“, sagt Lang-Recht. Es gebe Preislisten, Rabattaktionen und Ticket-Systeme. Diese Professionalisierung mache die Angriffe effizient und besonders gefährlich, biete aber auch Ansatzpunkte für Verhandlungen. Für die Angreifer gehe es um ein Geschäft und nicht etwa um eine persönliche Vendetta. Das einzige Ziel ist der Profit. Doch genau hier entsteht oft ein moralisches Dilemma für die betroffenen Unternehmen: Zahlen oder nicht zahlen? Das Dilemma der Lösegeldzahlung Während Behörden wie das BSI empfehlen, grundsätzlich nicht zu zahlen, ist die Realität in den Vorstandsetagen eine andere: Wenn die Existenz des Unternehmens auf dem Spiel steht, wird die Moral zur Nebensache. „Es ist am Ende eine rein wirtschaftliche Entscheidung“, sagt sie nüchtern. Geschäftsführern rät sie dringend davon ab, selbst in den Chat mit den Erpressern zu gehen. Hier seien Emotionen absolut fehl am Platz. Besser sei es, auf spezialisierte Unterhändler zu setzen. Ziel müsse sein, zunächst Zeit zu gewinnen, die Forderung zu drücken und herauszufinden, ob die Täter überhaupt in der Lage sind, die Daten wiederherzustellen. Besonders ärgerlich aus Sicht des angegriffenen Unternehmens ist die sogenannte Double Extortion. Dabei verschlüsseln die Täter nicht nur die Daten, sondern sie drohen auch mit deren Veröffentlichung. Wenn sich also das Opfer weigert zu zahlen, erhöhen die Kriminellen den Druck und kündigen die Veröffentlichung sensibler Kundendaten oder Konstruktionspläne an. Die Hausaufgaben für den C-Level „Die Haupteinfallstore sind schwache Passwörter, die per Brute-Force geknackt werden, ungesicherte Fernwartungszugänge (VPN/RDP) und klassisches Phishing“, resümiert Lang-Recht. Versäumnisse in der „IT-Hygiene“ öffneten den Tätern Tür und Tor. Dazu zählen insbesondere veraltete Systeme, unzureichendes Patch-Management und eine fehlende Netzwerksegmentierung. Wenn ein Angreifer einmal im Netz ist, sollte er sich nicht ungehindert bewegen können. In vielen Unternehmen seien die Netzwerke aber „flach“, so die Forensikerin, wer drin sei, komme überall hin. „Wenn ein Angreifer in einen Teilbereich eindringt, darf er nicht die gesamte Infrastruktur verschlüsseln können“, fordert Lang-Recht. Die Segmentierung des Netzwerks sei die wirksamste Maßnahme, um den Schaden zu begrenzen. Der Faktor Mensch und Organisation Technik ist aber nur die eine Seite der Medaille. Die Expertin betont, wie wichtig es sei, auf den Notfall vorbereitet zu sein. Ein Unternehmen muss wissen, an wen es sich im Notfall wendet. Verträge, die garantieren, dass bei einem Angriff ein Expertenteam bereitstehen, sind für sie unverzichtbar. Zudem müssten Verantwortlichkeiten klar geregelt sein. In der Krise sei keine Zeit für Kompetenzgerangel. Wer entscheidet, ob der Internet-Zugang gekappt wird? Wer kommuniziert mit Kunden, Lieferanten und gegebenenfalls der Presse? Wer informiert den Datenschutzbeauftragten? „Es gibt in der Regel immer eine Person, die kommunikativ die Führung übernimmt“, beobachtet Lang-Recht. Diese Rolle müsse nicht nur definiert, sondern auch trainiert sein – durch Krisenstabsübungen und Notfallsimulationen. Ein Wettrüsten mit KI Der Blick in die Glaskugel zeigt keine Entspannung. Das Katz-und-Maus-Spiel zwischen Angreifern und Verteidigern geht nicht nur weiter, es wird durch den Einsatz von künstlicher Intelligenz auf ein höheres Niveau gehoben. Angreifer nutzen KI, um bessere Phishing-Mails zu schreiben und um Schwachstellen schneller zu finden. Verteidiger nutzen sie, um Anomalien im Netzwerkverkehr in Echtzeit zu erkennen. Lang-Recht bleibt trotz der bedrohlichen Lage Optimistin. Hundertprozentige Sicherheit gibt es nicht, aber man könne es den Angreifern schwer machen. Sie empfiehlt: Investieren Sie in saubere Backups (offline!), Netzwerksegmentierung und Mitarbeiterschulung, und haben Sie einen Plan für den Tag X. (mb) width="100%" height="152" frameborder="0" allowfullscreen allow="autoplay; clipboard-write; encrypted-media; fullscreen; picture-in-picture" loading="lazy" src="https://open.spotify.com/embed/episode/76glj1FbyI6DYwhk4Z8Nw8?utm_source=oembed"> View the full article

intersoft consulting services AG Montagmorgen, 8:00 Uhr. Die Mitarbeitenden können sich nicht einloggen. Die Produktionsbänder stehen still, und auf den Bildschirmen prangen digitale Erpresserschreiben. Der Albtraum eines jeden CIOs ist wahr geworden: Ein Ransomware-Angriff hat den Betrieb lahmgelegt. Jetzt endet der Regelbetrieb, und der Ausnahmezustand beginnt. Für Joanna Lang-Recht, Director IT Forensics und Prokuristin bei der intersoft consulting services AG in Hamburg, ist dies der Alltag. Sie leitet eine hochspezialisierte Eingreiftruppe, die den Tathergang rekonstruiert und den Schaden eindämmt, während die anderen tief im Chaos versinken. „Man kann sich das tatsächlich ähnlich vorstellen wie in der kriminalistischen Forensik“, erklärt Lang-Recht. Doch die Realität habe dann doch wenig mit grellen Taschenlampen in dunklen Räumen zu tun, auch wenn die Parallelen in der Vorgehensweise zu erkennen seien. „Wir sammeln keine Schmauchspuren oder Fußabdrücke, wie konzentrieren uns auf Spuren im digitalen Raum“, so die Forensikerin. Wenn Cyberkriminelle zuschlagen, hinterlassen sie trotz aller Verschleierungstaktiken digitale Fragmente. Das können Logfiles sein, veränderte Zeitstempel oder Fragmente im Arbeitsspeicher. All das sind Puzzleteile, aus denen Lang-Recht und ihr Team das Bild des Angriffs zusammensetzen. Ihr Motto: Rekonstruieren statt Spekulieren. Doch bevor die detektivische Arbeit beginnen kann, müssen Unternehmen erst einmal aus der Schockstarre herausfinden. Zwischen Panik und Paralyse Ransomware-Angriffe folgen meist einem perfiden Timing. Beispielsweise wissen die Täter genau, wann IT-Abteilungen besonders verwundbar sind. „Häufig finden solche Angriffe über das Wochenende oder an Feiertagen statt“, berichtet die Expertin aus Hamburg in dem Podcast TechTalk Smart Leadership von COMPUTERWOCHE und CIO-Magazin. Die „Encryption-Phase“, in der die Daten des Opfers verschlüsselt werden, laufe dann von Freitag- bis Sonntagabend durch. Wenn die Belegschaft am Montag ins Büro kommt, sei das Unheil bereits geschehen. Die erste Reaktion in den betroffenen Unternehmen beschreibt Lang-Recht als einen Zustand absoluter Panik. „Wir reden hier von einem wirklichen Ausnahmezustand“, betont sie. Keine E-Mails, kein Zugriff auf Kundendaten, keine Produktion. In diesem ersten „Stadium der Akzeptanz“, wie Lang-Recht es nennt, würden oft die größten Fehler gemacht, die eine spätere Aufklärung massiv erschweren könnten. Der menschliche Impuls sei verständlich: Man möchte retten, was zu retten ist. Doch die Forensikerin warnt eindringlich vor Aktionismus. „Wir sehen häufig, dass IT-Teams gleich versuchen, zu bereinigen oder Backups einzuspielen, bevor sie überhaupt wissen, was passiert ist.“ Warum der Stecker nicht gezogen werden darf Lang-Recht empfiehlt, die Systeme vom Internet zu trennen, aber nicht auszuschalten. Das Herunterfahren eines Servers könne einen „forensischen Suizid“ bedeuten. „Das vernichtet wertvolle Hinweise“, erklärt sie. Viele Angreifer hinterlassen demnach Spuren im RAM-Speicher. Wird der Strom gekappt, sind diese Informationen unwiederbringlich verloren. Die Daten sind aber essenziell, um zu verstehen, wie die Hacker sich im Netzwerk bewegt haben (Lateral Movement) und ob sie noch aktiv sind. Die korrekte Vorgehensweise, so die Expertin, sei die Isolierung. „Die Verbindungen zu Dienstleistern, Kunden und Lieferanten sollten gekappt werden, um die Supply Chain nicht zu gefährden.“ Erst wenn die Infrastruktur in sich gesichert sei, beginne die eigentliche Arbeit der Forensik. Und diese erfordere oft das Auffahren schwerer Geschütze. Die Dimension von Cyberangriffe sprenge nämlich nicht selten die verfügbaren Speicherkapazitäten vor Ort. Um forensische Images – exakte 1:1-Kopien der Datenträger – zu erstellen, müssen laut Lang-Recht riesige Datenmengen gesichert und analysiert werden. Sind aber hunderte Server und tausende Clients zu untersuchen, werden die Verantwortlichen an physikalische Grenzen stoßen. Wer steckt hinter den Angriffen? Das Bild vom einsamen Hacker im Hoodie, der zwischen Pizzaschachteln im Keller hockt, ist laut Joanna Lang-Recht unrealistisch. „Wir haben es mit hochprofessionellen Tätergruppen zu tun“, stellt sie klar. Die Cyberkriminalität hat sich industrialisiert. Das Geschäftsmodell „Ransomware-as-a-Service“ (RaaS) dominiert den Markt. Die Gruppierungen seien wie mittelständische Betriebe aufgestellt. Sie verfügten oft sogar über Personalabteilungen, die Entwickler anwerben, und über Marketingabteilungen, die den Brand der Hackergruppe pflegten. Nicht selten hätten sie sogar einen mehrsprachigen Kundensupport installiert. „Wenn man in die Verhandlung geht, hat man es tatsächlich teilweise mit einem First-Level- und einem Second-Level-Support zu tun“, sagt Lang-Recht. Es gebe Preislisten, Rabattaktionen und Ticket-Systeme. Diese Professionalisierung mache die Angriffe effizient und besonders gefährlich, biete aber auch Ansatzpunkte für Verhandlungen. Für die Angreifer gehe es um ein Geschäft und nicht etwa um eine persönliche Vendetta. Das einzige Ziel ist der Profit. Doch genau hier entsteht oft ein moralisches Dilemma für die betroffenen Unternehmen: Zahlen oder nicht zahlen? Das Dilemma der Lösegeldzahlung Während Behörden wie das BSI empfehlen, grundsätzlich nicht zu zahlen, ist die Realität in den Vorstandsetagen eine andere: Wenn die Existenz des Unternehmens auf dem Spiel steht, wird die Moral zur Nebensache. „Es ist am Ende eine rein wirtschaftliche Entscheidung“, sagt sie nüchtern. Geschäftsführern rät sie dringend davon ab, selbst in den Chat mit den Erpressern zu gehen. Hier seien Emotionen absolut fehl am Platz. Besser sei es, auf spezialisierte Unterhändler zu setzen. Ziel müsse sein, zunächst Zeit zu gewinnen, die Forderung zu drücken und herauszufinden, ob die Täter überhaupt in der Lage sind, die Daten wiederherzustellen. Besonders ärgerlich aus Sicht des angegriffenen Unternehmens ist die sogenannte Double Extortion. Dabei verschlüsseln die Täter nicht nur die Daten, sondern sie drohen auch mit deren Veröffentlichung. Wenn sich also das Opfer weigert zu zahlen, erhöhen die Kriminellen den Druck und kündigen die Veröffentlichung sensibler Kundendaten oder Konstruktionspläne an. Die Hausaufgaben für den C-Level „Die Haupteinfallstore sind schwache Passwörter, die per Brute-Force geknackt werden, ungesicherte Fernwartungszugänge (VPN/RDP) und klassisches Phishing“, resümiert Lang-Recht. Versäumnisse in der „IT-Hygiene“ öffneten den Tätern Tür und Tor. Dazu zählen insbesondere veraltete Systeme, unzureichendes Patch-Management und eine fehlende Netzwerksegmentierung. Wenn ein Angreifer einmal im Netz ist, sollte er sich nicht ungehindert bewegen können. In vielen Unternehmen seien die Netzwerke aber „flach“, so die Forensikerin, wer drin sei, komme überall hin. „Wenn ein Angreifer in einen Teilbereich eindringt, darf er nicht die gesamte Infrastruktur verschlüsseln können“, fordert Lang-Recht. Die Segmentierung des Netzwerks sei die wirksamste Maßnahme, um den Schaden zu begrenzen. Der Faktor Mensch und Organisation Technik ist aber nur die eine Seite der Medaille. Die Expertin betont, wie wichtig es sei, auf den Notfall vorbereitet zu sein. Ein Unternehmen muss wissen, an wen es sich im Notfall wendet. Verträge, die garantieren, dass bei einem Angriff ein Expertenteam bereitstehen, sind für sie unverzichtbar. Zudem müssten Verantwortlichkeiten klar geregelt sein. In der Krise sei keine Zeit für Kompetenzgerangel. Wer entscheidet, ob der Internet-Zugang gekappt wird? Wer kommuniziert mit Kunden, Lieferanten und gegebenenfalls der Presse? Wer informiert den Datenschutzbeauftragten? „Es gibt in der Regel immer eine Person, die kommunikativ die Führung übernimmt“, beobachtet Lang-Recht. Diese Rolle müsse nicht nur definiert, sondern auch trainiert sein – durch Krisenstabsübungen und Notfallsimulationen. Ein Wettrüsten mit KI Der Blick in die Glaskugel zeigt keine Entspannung. Das Katz-und-Maus-Spiel zwischen Angreifern und Verteidigern geht nicht nur weiter, es wird durch den Einsatz von künstlicher Intelligenz auf ein höheres Niveau gehoben. Angreifer nutzen KI, um bessere Phishing-Mails zu schreiben und um Schwachstellen schneller zu finden. Verteidiger nutzen sie, um Anomalien im Netzwerkverkehr in Echtzeit zu erkennen. Lang-Recht bleibt trotz der bedrohlichen Lage Optimistin. Hundertprozentige Sicherheit gibt es nicht, aber man könne es den Angreifern schwer machen. Sie empfiehlt: Investieren Sie in saubere Backups (offline!), Netzwerksegmentierung und Mitarbeiterschulung, und haben Sie einen Plan für den Tag X. (mb) width="100%" height="152" frameborder="0" allowfullscreen allow="autoplay; clipboard-write; encrypted-media; fullscreen; picture-in-picture" loading="lazy" src="https://open.spotify.com/embed/episode/76glj1FbyI6DYwhk4Z8Nw8?utm_source=oembed"> View the full article

Even as they become ever more stealthy with AI-driven tools, threat actors are not giving up on simple, tried-and-true phishing — because it still works. According to new research, attackers are still making mischief with PDFs, the old business standby, and are exploiting growing trust in services like Dropbox. Forcepoint’s X-Labs team has uncovered a multi-stage phishing campaign that exploits PDF files and Dropbox storage through a layered redirection attack. After clicking on what looks like a legitimate PDF, victims are rerouted to a Dropbox logon impersonation page designed to harvest their credentials for internal access, account takeover, or other fraud. “This is a perfect example of why phishing is still the number one way for criminals to get at organizations,” said David Shipley of Beauceron Security. “This attack works because it mimics normal business behavior.” Anatomy of a multi-layered PDF attack In this campaign, victims first receive a professional-sounding email that seems to be part of a normal procurement or tender process and asks them to review an attached document. The type of wording is “commonly used in tender or procurement fraud, where urgency and legitimacy are deliberately created to encourage quick action,” wrote Forcepoint researcher Prashant Kumar. The PDF serves as the primary malware delivery mechanism. Unbeknownst to the victim, the sender address is spoofed or associated with a compromised account. Once they click on the attachment, they are directed to a second PDF hosted on a trusted cloud service (public.blob[.]vercel-storage[.]com), which further redirects them to a fake Dropbox login page. If they take the bait, they’ll log in with their email address and password, and those credentials will be exfiltrated to attacker-controlled command and control (C2) infrastructure. “The first [document] passed the email filter because it’s perfectly legitimate and links to a trusted service,” said Beauceron’s Shipley. “There’s no way to stop that without lots of negative business consequences.” The second one works because it’s not the trusted cloud service’s job to vet content hosted in it. These types of email also often pass standard authentication checks such as sender policy framework (SPF), DomainKeys Identified Mail (DKIM), and domain-based message authentication, reporting, and conformance (DKIM). “The minimal and business-like content helps avoid keyword-based detection, making the message look and feel more like a routine operational request,” Kumar wrote. Thus, attackers are able to convince victims that they need to authenticate to view the documents. This phishing campaign is interesting in that it’s multi-faceted and has been “very well thought out,” noted Erik Avakian, technical counselor at Info-Tech Research Group. And it’s effective because “nothing looks obviously wrong to the end user at any single stage. The original email is clean and gets by most filters, the first PDF opens normally and seems to be hosted on a legitimate cloud service, and the Dropbox login page looks real. “Each step, by itself, passes the sniff test,” he said. “The danger only becomes obvious when you zoom out and look at the entire chain, and most users don’t think about chains. They think in clicks.” Masquerading as a safe document format But after so many warnings about this over time — why are people still so trusting of PDFs and Dropbox? “Because, historically, they’ve actually been trained to be,” said Avakian. PDFs are routinely used in the business world and have been positioned as a safe, read-only document format for invoices, contracts, HR forms, and statements. This applies to Dropbox, too; it’s become a mainstream business tool that employees have been encouraged to use, and has been positioned so that its services “are not some sketchy file-sharing site anymore.” “When people see a PDF or a Dropbox logo, their guard naturally drops,” said Avakian. Familiarity and the need for speed prevent them from pausing and taking a closer look. Attackers know this, and “exploit it perfectly.” On top of this, Avakian pointed out, cloud infrastructure has become a “shield” for attackers. Security awareness has conditioned users to be wary of shady domains, but not of reputable platforms. It’s a mental model that’s outdated, and “attackers are way ahead of it.” ‘Don’t click links’ is not enough Hackers know that many employees tend to touch payment processes and documents, noted Lionel Menchaca, content marketing and technical writing specialist at Forcepoint, so they must be trained to verify that invoices, purchase orders (POs), and contracts are coming from confirmed vendors, affiliates, and agencies. “If they cannot verify, they should report suspicious emails to IT or security teams,” he said. But the precautions don’t stop there, Shipley noted. Employees must develop good e-mail processing habits, such as by taking frequent breaks; simulations can help, as they allow people to break out of routine. Many email clicks (he estimates about 40%) occur when people are on autopilot and aren’t processing at the deep thinking level, “they’re just acting on instinct.” Avakian agreed that email security awareness training must evolve beyond “don’t click links.” Employers and leaders at all levels must understand that modern phishing is increasingly “multi-stage, cloud-hosted, brand-impersonating, and intentionally boring-looking.” PDFs are no longer “safe by default,” and cloud services are no longer “trusted by default.” “This type of incident becomes a great example, and [an] opportunity to build more sophisticated phishing testing,” said Avakian. “The goal is not to embarrass users, but to build security minded habits as to how attacks unfold today.” While the basics still matter, they need to be framed honestly, he said. Hover over links, but understand that cloud-hosted URLs can still be malicious; check the sender’s “from” address and domain, but recognize that compromised or look-alike domains exist; be cautious of unexpected attachments, even PDFs, especially when they lead you somewhere else; treat any login prompts as a moment to pause, “especially when they’re triggered indirectly,” Avakian advised. “Security awareness has to grow up, just like the threats did,” he said. Still, clicks will happen, and effective multi-layered controls limit the damage. Multi-factor authentication (MFA), conditional access, and anomaly detection are critical, and a zero-trust mindset embeds security into a culture where the “trust by default” mindset goes away, said Avakian. “At the end of the day, PDFs and Dropbox aren’t the problem; unquestioned trust is,” he said. View the full article

Even as they become ever more stealthy with AI-driven tools, threat actors are not giving up on simple, tried-and-true phishing — because it still works. According to new research, attackers are still making mischief with PDFs, the old business standby, and are exploiting growing trust in services like Dropbox. Forcepoint’s X-Labs team has uncovered a multi-stage phishing campaign that exploits PDF files and Dropbox storage through a layered redirection attack. After clicking on what looks like a legitimate PDF, victims are rerouted to a Dropbox logon impersonation page designed to harvest their credentials for internal access, account takeover, or other fraud. “This is a perfect example of why phishing is still the number one way for criminals to get at organizations,” said David Shipley of Beauceron Security. “This attack works because it mimics normal business behavior.” Anatomy of a multi-layered PDF attack In this campaign, victims first receive a professional-sounding email that seems to be part of a normal procurement or tender process and asks them to review an attached document. The type of wording is “commonly used in tender or procurement fraud, where urgency and legitimacy are deliberately created to encourage quick action,” wrote Forcepoint researcher Hassan Faizan. The PDF serves as the primary malware delivery mechanism. Unbeknownst to the victim, the sender address is spoofed or associated with a compromised account. Once they click on the attachment, they are directed to a second PDF hosted on a trusted cloud service (public.blob[.]vercel-storage[.]com), which further redirects them to a fake Dropbox login page. If they take the bait, they’ll log in with their email address and password, and those credentials will be exfiltrated to attacker-controlled command and control (C2) infrastructure. “The first [document] passed the email filter because it’s perfectly legitimate and links to a trusted service,” said Beauceron’s Shipley. “There’s no way to stop that without lots of negative business consequences.” The second one works because it’s not the trusted cloud service’s job to vet content hosted in it. These types of email also often pass standard authentication checks such as sender policy framework (SPF), DomainKeys Identified Mail (DKIM), and domain-based message authentication, reporting, and conformance (DKIM). “The minimal and business-like content helps avoid keyword-based detection, making the message look and feel more like a routine operational request,” Faizan wrote. Thus, attackers are able to convince victims that they need to authenticate to view the documents. This phishing campaign is interesting in that it’s multi-faceted and has been “very well thought out,” noted Erik Avakian, technical counselor at Info-Tech Research Group. And it’s effective because “nothing looks obviously wrong to the end user at any single stage. The original email is clean and gets by most filters, the first PDF opens normally and seems to be hosted on a legitimate cloud service, and the Dropbox login page looks real. “Each step, by itself, passes the sniff test,” he said. “The danger only becomes obvious when you zoom out and look at the entire chain, and most users don’t think about chains. They think in clicks.” Masquerading as a safe document format But after so many warnings about this over time — why are people still so trusting of PDFs and Dropbox? “Because, historically, they’ve actually been trained to be,” said Avakian. PDFs are routinely used in the business world and have been positioned as a safe, read-only document format for invoices, contracts, HR forms, and statements. This applies to Dropbox, too; it’s become a mainstream business tool that employees have been encouraged to use, and has been positioned so that its services “are not some sketchy file-sharing site anymore.” “When people see a PDF or a Dropbox logo, their guard naturally drops,” said Avakian. Familiarity and the need for speed prevent them from pausing and taking a closer look. Attackers know this, and “exploit it perfectly.” On top of this, Avakian pointed out, cloud infrastructure has become a “shield” for attackers. Security awareness has conditioned users to be wary of shady domains, but not of reputable platforms. It’s a mental model that’s outdated, and “attackers are way ahead of it.” ‘Don’t click links’ is not enough Hackers know that many employees tend to touch payment processes and documents, noted Lionel Menchaca, content marketing and technical writing specialist at Forcepoint, so they must be trained to verify that invoices, purchase orders (POs), and contracts are coming from confirmed vendors, affiliates, and agencies. “If they cannot verify, they should report suspicious emails to IT or security teams,” he said. But the precautions don’t stop there, Shipley noted. Employees must develop good e-mail processing habits, such as by taking frequent breaks; simulations can help, as they allow people to break out of routine. Many email clicks (he estimates about 40%) occur when people are on autopilot and aren’t processing at the deep thinking level, “they’re just acting on instinct.” Avakian agreed that email security awareness training must evolve beyond “don’t click links.” Employers and leaders at all levels must understand that modern phishing is increasingly “multi-stage, cloud-hosted, brand-impersonating, and intentionally boring-looking.” PDFs are no longer “safe by default,” and cloud services are no longer “trusted by default.” “This type of incident becomes a great example, and [an] opportunity to build more sophisticated phishing testing,” said Avakian. “The goal is not to embarrass users, but to build security minded habits as to how attacks unfold today.” While the basics still matter, they need to be framed honestly, he said. Hover over links, but understand that cloud-hosted URLs can still be malicious; check the sender’s “from” address and domain, but recognize that compromised or look-alike domains exist; be cautious of unexpected attachments, even PDFs, especially when they lead you somewhere else; treat any login prompts as a moment to pause, “especially when they’re triggered indirectly,” Avakian advised. “Security awareness has to grow up, just like the threats did,” he said. Still, clicks will happen, and effective multi-layered controls limit the damage. Multi-factor authentication (MFA), conditional access, and anomaly detection are critical, and a zero-trust mindset embeds security into a culture where the “trust by default” mindset goes away, said Avakian. “At the end of the day, PDFs and Dropbox aren’t the problem; unquestioned trust is,” he said. View the full article

Microsoft has announced that the phase-out of NT LAN Manager (NTLM) is now transitioning to disabling the protocol by default, in an effort to increase security in Windows 11 and Windows Server. NTLM is a series of security protocols that were introduced in the 1990s, but since Kerberos became the default protocol in Windows 2000, its use has declined with each passing year. Still, many legacy enterprise systems still support or use NTLM, making them vulnerability to NTLM relay attacks, for example. And while Microsoft administrators have been preparing for the demise of NTLM for years, many still struggle to rid their networks of the protocol. In recent years, hackers have exploited NTLM flaws to gain full access to networks, so the disadvantages of supporting it outweigh the advantages. Microsoft now considers NTLM deprecated. A timetable for the deactivation can be found on the Windows IT Pro Blog. View the full article

FAMILY STOCK – shutterstock.com Unternehmen investieren Millionen von Dollar in Firewalls, Endpunktsicherheit oder Verschlüsselung. Doch eine einzige Person kann eine Katastrophe auslösen. Es reicht, wenn sie eine infizierte Datei herunterlädt oder auf einen betrügerischen Link klickt. Analysen zeigen: Zwischen 70 und 90 Prozent aller Sicherheitslücken entstehen, weil Menschen Fehler machen. Sie fallen auf Social Engineering herein oder nutzen riskante Dienste ohne Erlaubnis der IT. Zudem verschärft sich die Lage, da Angreifer zunehmend künstliche Intelligenz und Deepfakes einsetzen. Das Problem ist bekannt. Deshalb gaben Organisationen im Jahr 2025 etwa sechs Milliarden Dollar für Security Awareness Trainings (SAT) aus. Manche Firmen tun dies freiwillig. Die meisten beugen sich jedoch Vorschriften wie der Datenschutz-Grundverordnung oder dem Health Insurance Portability and Accountability Act. Letzterer verpflichtet etwa alle Beschäftigten im Gesundheitswesen rechtlich zu solchen Programmen. Experten erwarten, dass die Ausgaben für diese Maßnahmen jährlich um 15 Prozent steigen. Warum das klassische Training scheitert Obwohl diese Schulungen zum Standard gehören, bleibt ihr Nutzen fragwürdig. Viele Firmen haken das Thema nur ab, um Regeln einzuhalten. Den eigentlichen Mehrwert ignorieren sie dabei. Die Angestellten wiederum spielen das Spiel mit. Sie klicken sich so schnell wie möglich durch die Tutorials, damit sie weiterarbeiten können. Selbst wer aufpasst, vergisst das Gelernte oft schnell wieder, wenn er es im Alltag nicht aktiv anwendet. Manchmal schaden die Kurse sogar. Studien belegen: Wer in den Tests besonders gut abschneidet, wird oft leichtsinnig. Diese Personen wiegen sich in falscher Sicherheit. Meiner Meinung nach stecken wir in einem Paradoxon. Trotz hoher Investitionen und strenger Regeln bleibt der Nutzen minimal. Das System ist defekt. Wir brauchen deshalb einen radikalen Kurswechsel: weg von sporadischen Kursen, hin zum Human Risk Management. Was bedeutet Human Risk Management? Dieser Ansatz verfolgt eine klare Strategie: Er identifiziert menschliches Verhalten als Risiko und versucht, dieses gezielt zu senken. Während herkömmliche Schulungen nur theoretisches Wissen vermitteln, konzentriert sich das Human Risk Management darauf, wie Menschen tatsächlich handeln. Das System verbindet sich direkt mit E-Mail-Programmen oder Identitäts-Management-Systemen. So erkennt es menschliche Schwachstellen sofort. Es nutzt Daten, um riskante Nutzer aufzuspüren. Danach greift es gezielt ein – etwa durch kurze Lerneinheiten oder automatisierte Kontrollen. Am Ende überwacht das System, ob sich das Verhalten wirklich verbessert. Manche glauben, man müsse für beides separat bezahlen. Das stimmt nicht. Tatsächlich sind führende HRM-Lösungen von Anbietern wie Fable Security, KnowBe4 und Mimecast vollgepackt mit Standard-SAT-Material. Sie bieten sogar spezifische Schulungsunterstützung für regulatorische Compliance-Anforderungen. Lesetipp: Menschenzentrierte Cybersicherheit gewinnt an Bedeutung Demokratisierung durch künstliche Intelligenz Klingt das nach neuem Marketing-Hype? Vielleicht. Aber diese Methode nutzt künstliche Intelligenz als Partner. Anders als bei vielen Trends sind sich Experten hier einig: KI wird die Bildung grundlegend verändern. KI agiert wie ein persönlicher Tutor. Sie gibt kleine Stöße in die richtige Richtung. Klickt jemand auf einen gefährlichen Link, erhält er sofort eine passende Lerneinheit. So verfestigt sich das richtige Verhalten im Moment des Fehlers. Zudem lernt das System, wie einzelne Personen am besten begreifen. Die eine Person liest lieber Texte, die andere schaut lieber Videos. Die Werkzeuge können sogar Rollenspiele durchführen und den Wettbewerb unter Kollegen anspornen. Das demokratisiert Expertenwissen auf eine völlig neue Weise. Für Unternehmen lohnt sich das finanziell. Verantwortliche berichten nicht mehr nur, wie viele Leute ein Video geschaut haben. Sie belegen stattdessen, wie sich die digitale Hygiene im Betrieb verbessert. Wer ständig Fehler macht, bekommt individuelle Hilfe. So lässt sich direkt nachweisen, dass das Training die Zahl der echten Sicherheitsvorfälle senkt. Aristoteles sagte einmal: „Wir sind das, was wir wiederholt tun. Vorzüglichkeit ist also keine Handlung, sondern eine Gewohnheit.“ Genau hier setzt das Human Risk Management an. Es verändert Gewohnheiten. Wäre Aristoteles heute Sicherheitschef, würde er diesen logischen Schritt sicher befürworten. (jm) View the full article

FAMILY STOCK – shutterstock.com Unternehmen investieren Millionen von Dollar in Firewalls, Endpunktsicherheit oder Verschlüsselung. Doch eine einzige Person kann eine Katastrophe auslösen. Es reicht, wenn sie eine infizierte Datei herunterlädt oder auf einen betrügerischen Link klickt. Analysen zeigen: Zwischen 70 und 90 Prozent aller Sicherheitslücken entstehen, weil Menschen Fehler machen. Sie fallen auf Social Engineering herein oder nutzen riskante Dienste ohne Erlaubnis der IT. Zudem verschärft sich die Lage, da Angreifer zunehmend künstliche Intelligenz und Deepfakes einsetzen. Das Problem ist bekannt. Deshalb gaben Organisationen im Jahr 2025 etwa sechs Milliarden Dollar für Security Awareness Trainings (SAT) aus. Manche Firmen tun dies freiwillig. Die meisten beugen sich jedoch Vorschriften wie der Datenschutz-Grundverordnung oder dem Health Insurance Portability and Accountability Act. Letzterer verpflichtet etwa alle Beschäftigten im Gesundheitswesen rechtlich zu solchen Programmen. Experten erwarten, dass die Ausgaben für diese Maßnahmen jährlich um 15 Prozent steigen. Warum das klassische Training scheitert Obwohl diese Schulungen zum Standard gehören, bleibt ihr Nutzen fragwürdig. Viele Firmen haken das Thema nur ab, um Regeln einzuhalten. Den eigentlichen Mehrwert ignorieren sie dabei. Die Angestellten wiederum spielen das Spiel mit. Sie klicken sich so schnell wie möglich durch die Tutorials, damit sie weiterarbeiten können. Selbst wer aufpasst, vergisst das Gelernte oft schnell wieder, wenn er es im Alltag nicht aktiv anwendet. Manchmal schaden die Kurse sogar. Studien belegen: Wer in den Tests besonders gut abschneidet, wird oft leichtsinnig. Diese Personen wiegen sich in falscher Sicherheit. Meiner Meinung nach stecken wir in einem Paradoxon. Trotz hoher Investitionen und strenger Regeln bleibt der Nutzen minimal. Das System ist defekt. Wir brauchen deshalb einen radikalen Kurswechsel: weg von sporadischen Kursen, hin zum Human Risk Management. Was bedeutet Human Risk Management? Dieser Ansatz verfolgt eine klare Strategie: Er identifiziert menschliches Verhalten als Risiko und versucht, dieses gezielt zu senken. Während herkömmliche Schulungen nur theoretisches Wissen vermitteln, konzentriert sich das Human Risk Management darauf, wie Menschen tatsächlich handeln. Das System verbindet sich direkt mit E-Mail-Programmen oder Identitäts-Management-Systemen. So erkennt es menschliche Schwachstellen sofort. Es nutzt Daten, um riskante Nutzer aufzuspüren. Danach greift es gezielt ein – etwa durch kurze Lerneinheiten oder automatisierte Kontrollen. Am Ende überwacht das System, ob sich das Verhalten wirklich verbessert. Manche glauben, man müsse für beides separat bezahlen. Das stimmt nicht. Tatsächlich sind führende HRM-Lösungen von Anbietern wie Fable Security, KnowBe4 und Mimecast vollgepackt mit Standard-SAT-Material. Sie bieten sogar spezifische Schulungsunterstützung für regulatorische Compliance-Anforderungen. Lesetipp: Menschenzentrierte Cybersicherheit gewinnt an Bedeutung Demokratisierung durch künstliche Intelligenz Klingt das nach neuem Marketing-Hype? Vielleicht. Aber diese Methode nutzt künstliche Intelligenz als Partner. Anders als bei vielen Trends sind sich Experten hier einig: KI wird die Bildung grundlegend verändern. KI agiert wie ein persönlicher Tutor. Sie gibt kleine Stöße in die richtige Richtung. Klickt jemand auf einen gefährlichen Link, erhält er sofort eine passende Lerneinheit. So verfestigt sich das richtige Verhalten im Moment des Fehlers. Zudem lernt das System, wie einzelne Personen am besten begreifen. Die eine Person liest lieber Texte, die andere schaut lieber Videos. Die Werkzeuge können sogar Rollenspiele durchführen und den Wettbewerb unter Kollegen anspornen. Das demokratisiert Expertenwissen auf eine völlig neue Weise. Für Unternehmen lohnt sich das finanziell. Verantwortliche berichten nicht mehr nur, wie viele Leute ein Video geschaut haben. Sie belegen stattdessen, wie sich die digitale Hygiene im Betrieb verbessert. Wer ständig Fehler macht, bekommt individuelle Hilfe. So lässt sich direkt nachweisen, dass das Training die Zahl der echten Sicherheitsvorfälle senkt. Aristoteles sagte einmal: „Wir sind das, was wir wiederholt tun. Vorzüglichkeit ist also keine Handlung, sondern eine Gewohnheit.“ Genau hier setzt das Human Risk Management an. Es verändert Gewohnheiten. Wäre Aristoteles heute Sicherheitschef, würde er diesen logischen Schritt sicher befürworten. (jm) View the full article

The first time you’ll hear, “We’re always in incident mode,” it won’t be said with drama. It will be said the way you mention the weather. Grey again. Pager again. And that’s the problem. When a constant alarm becomes normal, your team stops asking the only question that matters. Why do we keep ending up here? You can buy more tools. You can hire more analysts. You can hang more dashboards. You’ll still end up sprinting after the last breach, the last misconfiguration, the last vendor surprise, the last “minor” change that ate your weekend. The best cyber teams we’ve worked with didn’t win because they ran faster. They won because they were adaptive and changed the risk landscape. They built a culture where weak signals had a microphone, and action didn’t require heroics. Forecasting in cybersecurity is not fortune-telling. It’s disciplined habits, clear choices and a team that treats risk as daily practice, not an annual slide. The trap: When ‘busy’ replaces ‘aware’ Reactive teams don’t choose chaos. Chaos chooses them, one small compromise at a time. A rushed change goes in late Friday. A privileged account sticks around “temporarily” for months. A patch slips because the product has a deadline, and security feels like the polite guest at the table. A supplier gets fast-tracked, and nobody circles back. Each event seems manageable. Together, they create a pattern. The pattern is what burns you. Most teams drown in noise because they treat every alert as equal and security’s job. You never develop direction. You develop reflexes. Reflexes feel useful. They look good on incident bridges. They can also keep you blind. Forecasting begins when you stop rewarding the “save” and start rewarding the “see and act.” Risk culture: What it is when you strip the slogans People talk about culture like it’s soft. Posters. Values. A town hall with applause on cue. Culture is harder. Culture is what people do when nobody is watching, and when the clock is loud. Culture is what gets you the truth at 4 p.m., not at 4 a.m. In cybersecurity, risk culture answers four questions. Do people notice risk early? Do they name it clearly? Do they know who can decide? Do they act without fear? If anyone fails, you get silence. Silence is the most dangerous gap in the building. We’ve seen teams with expensive tooling and miserable outcomes because engineers learned one lesson. “If I raise a risk, I’ll get punished, slowed down or ignored.” So they keep quiet, and you get surprised. We’ve also seen teams with average tooling but strong habits. They didn’t pretend risk was comfortable. They made it speakable. Speakable risk is the start of foresight. Foresight enables the right action or inaction to achieve the best result! Signal discipline: Give weak signals a place to land Forecasting is not about seeing everything. It’s about seeing the right things early enough to act. Top teams collect near misses like pilots collect flight data. Not for blame. For pattern. A near miss is the attacker who almost got in. The bad change that almost made it into production. The vendor who nearly exposed a secret. The credential that nearly shipped in code. Most organizations throw these away. “No harm done.” Ticket closed. Then harm arrives later, wearing the same outfit. So you need a place for near misses to land. A lightweight log. A channel people trust. A small weekly ritual where you ask, “What almost happened?” Not “Who messed up.” You also need shared language. Not ten pages of taxonomy. Just words that mean the same thing across teams. When someone says “critical,” do they mean “drop everything,” or “put it in the next release?” Ambiguity breeds delay. Delay breeds surprise. Decision rights: Speed dies in committees We’ve seen incident calls where 20 people had opinions, and nobody had authority. It’s like watching a committee try to steer a ship mid-storm. Forecasting requires speed, and speed requires decision rights and Risk Intelligence. Many programmes invest in detection and forget the human bottleneck. Even perfect visibility is useless if every decision needs a meeting, and every meeting needs a senior leader who is “in back-to-backs.” Top teams make risk-intelligent decisions before the heat. Who can block a release? Who can isolate a system? Who can force key rotation? Who can accept risk, and under what conditions? When an issue jumps a level, and what triggers that jump. If you want forecasting, fix your approval grid. Make it short. Make it usable at 2 a.m. Then protect it. One override for convenience, and people learn the real rules. The real rules always win. Behavioral standards: What ‘good’ looks like on Tuesday You can’t ask people to “care about risk” and expect it to stick. People run on what gets rewarded and what gets them in trouble. So strong teams set behavioral standards. Not as a lecture. As an operating agreement. Security’s job is to reduce harm while keeping work moving, not to act as a gatekeeper. That means rules people can follow, and guardrails that make the right path easier than the wrong one. Engineering’s job is to own what they ship, not to “help security.” If you build it, you own the blast radius. Product’s job is to make exposure part of design, not to treat security as a late-stage checklist. If you can’t explain why a feature is worth the risk, you don’t understand the feature. Vendor owners have a job too. They can’t outsource supplier risk to a questionnaire. They own the follow-up when a supplier says, “We’ll fix it next quarter.” A small practice I love. Ask each team for three “no surprises” rules. No privileged access without expiry. No production change without rollback. No new vendor without an owner and an exit plan. Short list. Clear verbs. Real enforcement. That’s culture. Operating rhythm: The week is where risk becomes real If you only talk about risk during audits and incidents, you don’t have a culture of risk. You have a seasonal sport. Forecasting lives in cadence. In the meetings you actually attend. Weekly, run a short review with three questions. What changed that affects exposure? What almost went wrong? What needs a decision? Keep it tight. If it turns into status theatre, kill it and start again. Monthly, practice one scenario. Plain, no fancy decks. If ransomware hits this service, what happens in the first hour? Who decides. What do you shut down, and what must stay alive? Quarterly, test what you claim. Backups. Access controls. Vendor escalation. If you can’t test it, you don’t know it. This rhythm teaches people that risk isn’t a surprise visitor. Risk is a resident. You don’t panic when you see it. You deal with it. Imagine you once joined a team’s weekly review as a guest. Ten minutes in, an ops lead said, “We changed the identity provider settings yesterday. It felt odd.” No panic. No blame. Just a raised hand. Security asked two questions, engineering checked logs and they rolled back a risky toggle before lunch. Nothing made the news. Nobody got a medal. Everyone went home on time. That’s what a good rhythm buys you. Most weeks, quietly. Measures that point forward: Count what moves before damage Many dashboards tell you what already happened. Incidents. Downtime. Loss. Useful, but late. If you want forecasting, track measures that move before the mess. Let’s shift to being a little more proactive and presilience-focused, instead of testing our reactions and resilience as the go-to responses. How long do critical patches sit on systems that matter? How often do privileged access exceptions expire on time? How many urgent changes bypass checks, and where? How many near misses get reported, and how fast you learn? Watch a team celebrate fewer incidents while near-miss reporting fell to zero. They thought they improved. In reality, people stopped speaking. Six weeks later, they got hit. The silence was the signal. You don’t want perfect numbers. You want honest trends that trigger choices, not slides. Leadership: The culture you reward is the culture you get Leaders say they want transparency. Then they punish the first person who brings bad news. That one moment teaches the organization more than any policy ever could. If you want forecasting and Presilience, protect the messenger. Praise early escalation. Treat risk as a trade, not as a personal failure. Also, stop romanticising heroics. The midnight save feels good. It makes a great story. It also hides the root issue: poor planning, weak controls, unclear ownership and a habit of postponing boring work. Boring work buys calm, discipline buys reliability but risk intelligence enables the right balance of compliance, resilience and presilience to manifest. Think of board conversations where someone asked, “Why spend on resilience when nothing happened this quarter?” And you answered with a question. “Would you rather pay for brakes or for ambulances?” It landed because it was true. A simple 90-day shift: Small moves, real change If your team feels stuck, don’t start with a massive program. Start with a few moves that change behavior fast. First 30 days. Map your top repeat failures. Pick five signals to watch weekly. Name owners. Days 31 to 60. Fix one decision bottleneck. Write the rule. Use it. Days 61 to 90. Run one scenario practice a month. Learn one thing. Change one playbook. Close one gap. You’re not chasing perfection. You’re building a habit. Habits compound. If you do this well, something shifts. You stop being surprised by the same problems. People raise issues earlier. Engineers stop hiding bad news. Security stops shouting into the void. The organization feels calmer. Not complacent. Calm. That calm is not luck. It’s culture. The right balance between prevention, reaction and proactivity ensures sustainable high performance. And here’s the quiet mic-drop. When risk becomes a daily conversation, you don’t need to guess the future. You stop being shocked by the present. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Security researchers at Point Wild have disclosed a new Windows malware campaign that uses a multi-stage infection chain to establish persistent, memory-resident access on compromised systems and steal sensitive data. The analysis found the malware relying on standard Windows components for execution and persistence, limiting the number of artifacts written to disk. The activity, analyzed by the company’s Lat61 team, involves a .NET-based, modular remote access trojan (Pulsar RAT) that supports live, interactive operator control. The malware’s reliance on in-memory execution and living-off-the-land techniques limits the effectiveness of file-based detection tools, the researchers noted in a blog post. “The malware exhibits advanced anti-analysis techniques, including anti-VM, anti-debugging, and process injection detection, alongside extensive credential harvesting, surveillance capabilities, and remote system control,” they said. “Stolen data is exfiltrated as ZIP archives over Discord webhooks and Telegram bots.” Initial access and memory-resident execution The infection chain begins with a small batch script that establishes persistence through a per-user Registry Run key. Rather than deploying a full executable, the script launches a PowerShell-based loader, reducing the likelihood of immediate detection by traditional endpoint security tools. This PowerShell loader decodes and executes shellcode generated using Donut, an open-source framework commonly used to convert. NET assemblies into position-independent shellcode. The shellcode injects the payload directly into memory, avoiding the need to write a portable executable to disk. By operating entirely in memory after initial execution, the malware limits the effectiveness of file-based scanning and static analysis. Point Wild researchers noted that the attack blending into normal Windows activity calls for behavioral or memory-focused telemetry. Once loaded, the malware deploys a heavily obfuscated .NET component that serves as the core execution framework for the operation. RAT capabilities and stealer functionality The .NET payload implements a remote access trojan that allows operators to interact directly with compromised systems. Unlike many commodity RATs that rely on periodic check-ins, this malware supports live command handling, enabling attackers to issue instructions and receive responses in near real-time. This interactive design allows operators to perform reconnaissance, manipulate files, execute commands, and manage persistence dynamically based on what they observe on the infected host. Alongside the RAT functionality, the malware includes an information-stealing component that collects sensitive system data. While the disclosure did not attribute the Stealer to a specific malware family, the researchers noted that it operates in parallel with the RAT, allowing data collection to continue while operators actively engage with the system. Persistence, evasion, and mitigation Persistence is maintained through Registry-based autorun entries and reinforced by the malware’s ability to re-establish execution if disrupted. The use of obfuscation across the .NET payload further complicates reverse engineering and slows analysis. Point Wild emphasized that the campaign’s effectiveness stems from disciplined execution of Living-off-the-land binaries, in-memory payloads, and obfuscated managed code. Together, they make detection difficult. The researchers noted that detecting the activity requires monitoring process and memory behavior rather than relying on file-based indicators, which include watching for suspicious PowerShell execution, shellcode injection into running processes, and suspicious persistence via Registry Run keys. Rapid host isolation and live response were emphasized to contain interactive activity and limit data theft once a compromise is suspected. View the full article

Last month, while running a routine access audit on our Azure environment, I came across a service account called svc-dataloader-poc. It had not been touched in 793 days — two years of sitting dormant. When I checked its permissions, my stomach dropped: Owner-level access to three production subscriptions, including our customer database. The account had been spun up for a proof-of-concept migration that never went live. The contractor who created it left 18 months ago. Nobody knew it existed. This was not a one-off. I found 47 similar accounts in that same audit. Forty-seven doors left wide open. Here is the uncomfortable reality facing every security leader in 2026: while we spent the last decade perfecting MFA rollouts and zero-trust architectures for our human users, something else was quietly multiplying across our environments. Service accounts. API keys. Automation credentials. AI agents. These non-human identities now outnumber actual employees in most enterprises by ratios that would have seemed absurd five years ago. ManageEngine’s 2026 Identity Security Outlook found that organisations reported machine-to-human ratios of 100:1; some hit 500:1. And the vast majority of these identities sit completely outside our governance programmes. We locked the front door. The back door has been open this whole time. Why the NHI explosion is different this time Machine identities are not new. What changed is the velocity. Five years ago, a typical enterprise application was a monolith talking to a database. Today, that same application is 50 microservices, each needing credentials to talk to the others. Every Kubernetes pod that spins up during auto-scaling creates workload identities. Every GitHub Actions workflow generates tokens. Every Terraform run provisions service principals. I watched a single deployment pipeline create more machine identities in 20 minutes than our entire company had human users. Then came agentic AI, and the problem accelerated again. These are not chatbots answering questions. They are systems authorised to execute commands, move production data, modify configurations and trigger downstream workflows autonomously. Microsoft Copilot has access to your SharePoint. GitHub Copilot can commit to your repos. The AI assistant your marketing team just deployed can pull customer records from Salesforce. One Identity is predicting 2026 will see the first major breach traced back to an over-privileged AI agent. The terrifying part? It will not look like an attack. It will look exactly like the system doing what it was designed to do. Our IAM systems were never built for this. They assume identities belong to people with managers who respond to access review emails and eventually resign or retire. Machine identities have no manager. They never respond to certification campaigns. They do not quit. The OWASP Non-Human Identities Top 10 ranks improper offboarding as the number one risk. When a project gets cancelled, when a vendor integration gets deprecated, when a developer leaves — does anyone remember to delete the service accounts? In my experience running IAM programmes across multiple organisations, the answer is almost never. The three blind spots I keep finding After years working in cloud security and identity management, certain patterns show up everywhere I look. Three problems in particular appear in nearly every environment I assess. Secrets where they should never be. I still find API keys hardcoded in source files. Still. In 2026. Last year, GitGuardian detected 13 million secrets exposed in public GitHub repositories. Google API keys, MongoDB credentials, AWS access keys — sitting in plaintext for anyone to harvest. But the public repos are not even the biggest problem. In my own assessments, I have found production database passwords in Jira tickets, Slack messages, Confluence runbooks and shared Google Docs. A colleague once discovered an admin token for a payment gateway pasted into a Teams chat from 2023, still valid, still granting full access. Once secrets escape into collaboration tools, you have lost control. They get copied, forwarded, indexed, archived. They never truly disappear. Service accounts with absurd privilege levels. This one makes me angry because it is so preventable. A developer needs a service account for a new Lambda function. They are under deadline pressure. Figuring out the exact minimum permissions takes time, so they attach AdministratorAccess and move on. The function works. Nobody revisits it. That account now has god-mode access to your entire AWS environment for a task that needed read access to one S3 bucket. Multiply this across every team, every sprint, every year. The 2025 State of Non-Human Identities report from Entro Security found 97% of NHIs have excessive privileges. Ninety-seven percent. Even more alarming: just 0.01% of machine identities control 80% of cloud resources. Compromise one of those accounts and the attacker owns your environment. No lifecycle ownership whatsoever. When an employee leaves, HR triggers offboarding. Access gets revoked. There is a process. When a service account is no longer needed, what happens? Nothing. It sits there. I routinely find accounts untouched for six months, twelve months, sometimes three years — all still holding production access. Veza’s research found dormant accounts nearly doubled year over year. Orphaned identities grew 40%. Former employees — 78,000 of them in one dataset — still had active credentials because HR systems flagged them as inactive but nobody revoked their service accounts. These are not theoretical vulnerabilities. These are live credentials waiting for someone to find them. A practical path forward for security leaders Acknowledging the problem is step one. Fixing it requires treating machine identities with the same governance discipline we finally learned to apply to human users. Based on what I have seen actually work, here is where I would focus. Build a real inventory. You cannot protect what you cannot see. Before anything else, discover every non-human identity in your environment. Every service account across your cloud platforms. Every API key in your applications. Every secret in your vaults, config files, CI/CD pipelines. Every third-party integration with access to your systems. Most organisations I work with drastically underestimate their footprint. The actual number is typically three to five times what teams expect. This cannot be a manual exercise or an annual audit. Identities are created faster than humans can count them. Automate discovery and make it continuous. Enforce least privilege without exceptions. Every NHI needs to be scoped to the minimum access required for its function. Yes, this takes work. Yes, developers will push back. Do it anyway. Start with new deployments and make least privilege the default from day one. For existing accounts, compare assigned permissions against actual usage patterns. You will find plenty of accounts with broad access that only ever touch one or two resources. Those are quick wins. Require security approval before any NHI gets elevated privileges. Make it a gate, not a suggestion. Eliminate static credentials wherever possible. Long-lived secrets are the root cause behind most NHI breaches. The goal should be eliminating them entirely. Replace permanent API keys with short-lived tokens that expire automatically. Implement just-in-time access that grants permissions for a specific task and revokes them immediately after. Automate credential rotation on a defined schedule — weekly, daily, even hourly for sensitive systems. Research shows 71% of non-human identities are not rotated within recommended timeframes. Every day a credential sits unchanged is another day an attacker could be using it without detection. The security industry is converging on a clear consensus for 2026: machine identities will become the primary breach vector in cloud environments. Tenable predicts it. Delinea predicts it. One Identity predicts it. Attackers already know that compromising a service account is often easier and quieter than targeting humans. They are not breaking down doors anymore. They are walking through the ones we forgot to lock. The organisations that get ahead of this threat will be the ones treating their non-human identities with the same seriousness they apply to their executive accounts. Full visibility. Strict governance. No exceptions. The ones who keep treating NHIs as an afterthought will be the ones explaining to their boards how a forgotten service account from a cancelled project brought down the house. We locked the front door years ago. It has been a long time since we secured the back. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

BMI/ Laurin Schmid Deutschland und Israel haben nach Angaben des Bundesinnenministeriums erstmals gemeinsam die Abwehr eines schweren Cyberangriffs trainiert. Die Übung mit dem Namen “Blue Horizon” war demnach der erste konkrete Schritt aus dem Cyber- und Sicherheitspakt, den Bundesinnenminister Alexander Dobrindt (CSU) und Israels Ministerpräsident Benjamin Netanjahu kürzlich vereinbart hatten. “Cyberdome” soll vor Angriffen schützen Der Pakt sieht unter anderem eine enge Vernetzung der Sicherheitsbehörden beider Länder sowie eine noch engere Kooperation in den Bereichen Cyberkriminalität, Künstliche Intelligenz (KI) und Drohnenabwehr vor. Bei der Übung sollten sich Experten beider Seiten laut Innenministerium besser kennenlernen. Kern der Zusammenarbeit ist demnach der Aufbau eines deutschen “Cyberdomes”, angelehnt an das israelische Modell. Israel hat Erfahrung mit Cyberangriffen Der “Cyberdome” ist israelischen Angaben zufolge ein Verteidigungssystem, das unterschiedliche Daten zusammenführt und mit Hilfe von Künstlicher Intelligenz Schwachstellen oder auch Bedrohungen im Netz erkennt. Organisationen können auf diese Weise frühzeitig vor möglichen Hackerangriffen gewarnt werden. Israel gilt als Vorreiter im Bereich Cybersicherheit. Die oftmals iranischen Cyberattacken zielen Experten zufolge darauf, Israels Infrastruktur zu sabotieren, Daten zu sammeln sowie Falschnachrichten zu verbreiten. Israel arbeitet mit mehreren Verbündeten zusammen, um solche Angriffe abzuwehren. (dpa/jm) View the full article

BMI/ Laurin Schmid Deutschland und Israel haben nach Angaben des Bundesinnenministeriums erstmals gemeinsam die Abwehr eines schweren Cyberangriffs trainiert. Die Übung mit dem Namen “Blue Horizon” war demnach der erste konkrete Schritt aus dem Cyber- und Sicherheitspakt, den Bundesinnenminister Alexander Dobrindt (CSU) und Israels Ministerpräsident Benjamin Netanjahu kürzlich vereinbart hatten. “Cyberdome” soll vor Angriffen schützen Der Pakt sieht unter anderem eine enge Vernetzung der Sicherheitsbehörden beider Länder sowie eine noch engere Kooperation in den Bereichen Cyberkriminalität, Künstliche Intelligenz (KI) und Drohnenabwehr vor. Bei der Übung sollten sich Experten beider Seiten laut Innenministerium besser kennenlernen. Kern der Zusammenarbeit ist demnach der Aufbau eines deutschen “Cyberdomes”, angelehnt an das israelische Modell. Israel hat Erfahrung mit Cyberangriffen Der “Cyberdome” ist israelischen Angaben zufolge ein Verteidigungssystem, das unterschiedliche Daten zusammenführt und mit Hilfe von Künstlicher Intelligenz Schwachstellen oder auch Bedrohungen im Netz erkennt. Organisationen können auf diese Weise frühzeitig vor möglichen Hackerangriffen gewarnt werden. Israel gilt als Vorreiter im Bereich Cybersicherheit. Die oftmals iranischen Cyberattacken zielen Experten zufolge darauf, Israels Infrastruktur zu sabotieren, Daten zu sammeln sowie Falschnachrichten zu verbreiten. Israel arbeitet mit mehreren Verbündeten zusammen, um solche Angriffe abzuwehren. (dpa/jm) View the full article

IT security was a critical element of retired US Col. Barry Hensley’s 24-year military career as an Army Signal Officer, as he was often responsible for the engineering and installation of “military networks, whether in garrison or in support of combat troops deployed.” “The pinnacle of my military career was working with an elite group of cyber forces with the ultimate mission to operate and defend the military’s global communications network,” Hensley tells CSO. “It was during this period that I realized the severity of cybersecurity issues facing this [US] nation, and I wanted to commit my professional career to be part of the solution while continuing to fight the good fight.” Today, Hensley is the CSO of Brown & Brown, a global insurance brokerage, with the goal to help clients safeguard what matters most to them. CSO spoke to Barry Hensley about cybersecurity in the insurance industry, how to keep cyber professionals inspired, and more. How do organizations today perceive cybersecurity? Hensley: The awareness of cybersecurity risks is more consistent across industry today; but the degree of required call to action often varies greatly. Cybersecurity is foundational to any organization, especially where customer confidence and trust are essential. And part of that trust includes the security of the networks, the data, and the services we provide. It was not that long ago that organizations did not believe the risks were real or relevant to them. Times have changed as more organizations have either experienced a significant incident firsthand or have seen enough third- and fourth-party breach notifications to take up arms. All these events drive awareness and give credibility to the threats and associated risks. However, there is still a challenge in establishing an appropriate risk tolerance that drives the right investments in effective security controls, especially for budget constrained organizations. We also cannot forget the rise of government intervention and fines and other regulatory actions related to cybersecurity events that will influence those perceptions. What specific security risks are you facing in the insurance industry today? Threat actors today have a common theme, and that’s how they capitalize on their access. So, personally, I do not over-index on the vertical specific threats; it’s really about the data or access those organizations possess and its perceived value. Specific to the insurance industry, there may be information collected to inform a claim or policy that a threat actor might determine valuable even if it only refines their targeting efforts of others. However, we also cannot wish away the “idealist” or “ideologically motivated” threat actors that target the insurance industry because of historical misconceptions or animosity toward the industry. Specific to ransomware, threat actors are likely to target organizations that have a high likelihood of paying or be exploited. So, it’s as much about the data those organizations possess, not necessarily the industry verticals themselves, and the maturity of their security program. Threat actors want to expend the least number of resources for the highest return on investment, so they often target low-hanging fruit, which are, in many cases, the least mature security programs. Do you see your cybersecurity strategy changing in the next few years? Our strategy remains the same: focused security investments aligned to our risk tolerance, staying a step ahead of an increasingly active threat landscape. An example is the adoption of artificial intelligence hacking tools, clearly an illustration of the need to adapt. The question is, How do our security teams combat this advancement with our own AI strategy? How do we leverage AI to carry out those commodity tasks while unleashing our human teammates to focus on business context as it relates to the overall risk reduction and prioritization of training those AI models? So, imagine an AI security workforce that is led by human security subject-matter experts ensuring we have appropriate defenses at the right time and right place. An example would be conducting continuous penetration testing to find the gaps in our defenses that might otherwise go unnoticed. We do see the evolution of third- and fourth-party risk management, especially in how we validate our security partner’s maturity and resilience. The evolution of risk is partly based on third and fourth parties swapping their underlying technologies to reduce cost or increase efficiencies that a customer has little to no understanding of the risks that might expose. So, for the security functions we’re going to provide internally, we’ll focus on the basics and do them well. With the controls/functions we outsource, we must reimagine not only how we verify our partner environments but how do we actively participate to improve their security programs as well as ours. We cannot forget that much of cybersecurity is about doing the basics brilliantly. And in this case, those basics of building and securing an infrastructure that will still be leveraged for years to come. What do you do to retain cybersecurity professionals? Leadership is about how you inspire people to achieve or accomplish a shared vision beyond what they ever expected they could do. Leaders must first understand teammates’ passions and relevant skills to align them to achieve business goals. Getting their buy-in is key while clearly articulating where they fit in the overall vision. At Brown & Brown, we help others protect what is most valuable to them. To retain our top talent, we make sure our teammates understand where they fit into that mission. Our success story is based upon earning people’s business every day, and ensuring that our environment, networks, and data are secure is critical to building and retaining that trust. We need to demonstrate to our teammates just how integral they are to maintaining that trust in our customer relationships. We want them to wake up every day knowing that they play an important role not only in our security program, but also the broader Brown & Brown ecosystem. At Brown & Brown, we put the teammate first, as their expertise will always be a key differentiator. What are you most proud of? I am most proud of the inspiring team of security professionals that I work with each day. They always put the team before themselves, strive to be the very best at what they do, and always go the extra mile to ensure the security and protection of their teammates and the organization. I am truly blessed to be part of an amazing team whose work ethic and commitment to excellence are unparalleled in my experience. Are there any questions CISOs should be asking themselves? Are we assessing the most relevant risks, rather than the risks of yesterday? And, because we can get so wrapped up in the playbook that we ran in our last organization, how do we ensure the current playbook is relevant to the organization at hand? An example would be how much time we focus on phishing training, which burdens our teammates to be the first line of defense, where we could instead leverage anomaly-based detection to automate the detection and response actions. What are the biggest security challenges cybersecurity leaders are facing right now? Hensley: In this business, there is no single biggest challenge, but multiple, ever-evolving challenges that compete for our attention. A shared challenge across the entire cybersecurity community is having to be right 100% of the time in a world where threat actors are so agile, innovative, well-resourced, and advantaged with the element of surprise. Cybersecurity professionals also struggle with prioritizing their efforts while providing innovative solutions for their enterprises. Every cybersecurity leader must wrestle with the risks posed by new technologies; AI being just one of many. While there is no absolute “right” answer to the risk question, the age-old formula of mitigating threats against your most critical assets holds firm. Security teams have an ongoing mission to identify weaknesses, assess the likelihood of exploitation, and determine the resulting impact on the business. It’s a difficult but necessary step in the risk versus reward trade-off. What keeps you up at night? Hensley: The unknown. As I shared above, cybersecurity professionals must be right 100% of the time, while threat actors only need to exploit one unknown or unmitigated vulnerability, or take advantage of a single user with privileged access. Our risk modeling should invest in effective security controls to minimize the unknown threats as much as possible against our most critical assets. View the full article

Responsible disclosure is built on an assumption that “doing the right thing” will be met with timely action, fair treatment, and professional respect, if not a bounty award. Increasingly, that assumption is failing. And when it does, organizations alienate researchers and create regulatory, legal, and reputational risk. Over the past few years, security researchers have found themselves waiting months, sometimes more than a year, for companies to acknowledge responsibly disclosed vulnerabilities, even as the same flaws quietly put customers at risk. In several cases, frustration over silence, disputed severity assessments, or shifting scope boundaries pushed researchers toward public disclosure, legal escalation, or questionable behavior companies later characterized as extortion. As vulnerability reporting becomes slower, more bureaucratic, and less rewarding, the line between cooperative research and adversarial pressure is blurring. For CISOs, this is no longer an ethics debate. It is a governance and risk-management problem. A recent flashpoint Most recently, the React2Shell vulnerability (CVE-2025-55182) illustrated how responsible disclosure can work when the right structures are in place. The flaw was privately reported to the React maintainers on 29 November 2025. The disclosure triggered a coordinated response involving the React team, Next.js maintainers at Vercel, and major cloud providers including Amazon Web Services (AWS) and Cloudflare, allowing patches to be developed and tested ahead of public disclosure. Despite the prompt acknowledgment and remediation efforts, the vulnerability was quickly exploited in the wild. Responsibility for mitigation was effectively distributed across maintainers, framework integrators, and downstream users. Because React sits at the core of the modern web stack, the flaw rippled across development and security teams globally, highlighting how even well-handled disclosures can still produce widespread operational risk. React benefits from strong institutional support through the React Foundation and backing from multiple large technology companies. That support enables coordinated fixes, communication, and sustained maintenance. The more difficult question is what happens when a researcher uncovers a similarly critical flaw in a widely used open-source project that has no corporate backing, no formal security team, and no bounty program? In those cases, exploitation is clearly unethical, but reporting the issue often means unpaid labor with uncertain outcomes. The dilemma raised in practitioner circles after React2Shell was not about this specific incident, but about the broader incentive gap. If responsible disclosure offers neither compensation nor assurance of timely action, what realistically motivates researchers to continue doing the right thing? The question resonated not because it’s new, but rather that it reflects a growing disconnect between how vulnerability disclosure is supposed to function and how it increasingly does in practice. Enter the gray zone of ethical disclosure The result is a growing gray zone between ethical research and adversarial pressure. Based on years of reporting on disclosure disputes, that gray zone tends to emerge through a small set of recurring failure modes. Silent treatment and severity warfare: Researchers submit detailed reports and receive no response for months, or face disputes over CVE scope and CVSS scoring that turn technical discussions into negotiations. Researchers feel compelled to defend impact claims aggressively and to be taken seriously, while vendors push back against what they view as inflated risk. In some cases, bounty hunters preemptively elevate severity, anticipating resistance and delays. Process as denial of service: Automated scanners, AI-assisted fuzzing, and largely theoretical bugs increasingly flood maintainers and security teams with low-signal reports — a dynamic repeatedly highlighted by Daniel Stenberg, the founder of the cURL project. As a defensive response, maintainers demand ever more concrete proof of exploitability, raising the threshold for engagement even for legitimate findings. In some cases, projects begin questioning whether bug bounties meaningfully improve security, or simply externalize triage cost under the guise of incentives. Coercive escalation: Finally, when established disclosure channels appear unresponsive or dismissive, some researchers resort to public pressure, legal threats, or ethically ambiguous demonstrations to force action. Each of these failure modes seems rational in isolation. Together, they erode trust and steadily push responsible disclosure toward a more adversarial posture. Case studies from the fault line In 2025, a responsibly reported email spoofing flaw affecting a major delivery platform was deemed out of scope, triggering a dispute over severity and impact. The underlying issue was not whether the bug existed, but whether it crossed the organization’s internal threshold defining risk. The disclosure process stalled, and frustration escalated on both sides, with the vulnerability reporter barred from the bug bounty program over advances the company saw as extortion. A similar pattern appeared at a ride hailing company, where multiple researchers independently reported a flaw that allowed emails to be sent appearing to originate from the company’s domain. Despite clear reproduction steps and repeated follow-ups, the reports went unanswered for more than a year. Ethical disclosure was met not with remediation, but with silence. Elsewhere, disputes have emerged over overlapping CVE claims, with multiple parties arguing over attribution for the same underlying issue. What is meant to be a coordination mechanism instead became a contest for recognition, further distorting narratives. More troubling are cases where researchers crossed ethical boundaries entirely. For example, hijacking open-source libraries to harvest cloud credentials, or taking control of legitimate packages to embed job application messages, compromising downstream users in the process. Such actions are indefensible but are best understood as symptoms of a disclosure ecosystem that increasingly rewards escalation, visibility, or leverage over patience and cooperation. Why is this happening now? It would be easy to frame these disputes as a breakdown in professional norms, but what is happening beneath the surface is the convergence of several structural forces. Vulnerability report volume has surged. Automated scanners and AI-driven fuzzing tools now generate vast numbers of technically valid but operationally irrelevant findings. Maintainers and security teams are forced to triage at scale, often under significant time and resource constraints. At the same time, compliance pressures have hardened organizational responses. Once a CVE is reported, it is often treated as a problem by default, before context or exploitability is assessed. High severity scores can trigger build failures, audits, or executive escalation regardless of practical impact — a common frustration for developers using SCA tools that block builds over edge cases that ultimately need to be ignored or waived. CVSS scoring itself is mechanically calculated and intentionally environment-agnostic, meaning low-impact edge cases can score similarly to actively exploited flaws, contributing to alert fatigue and skepticism. Finally, open source infrastructure remains structurally underfunded. Many critical components are maintained by a small number of individuals with no obligation, or capacity, to absorb the operational cost imposed by global dependency chains. In this environment, demanding proof of real-world impact is a form of noise control, rather than hostility. That seemingly reasonable demand, however, has downstream consequences. When proof becomes unpaid consulting In many disputes, disclosure breaks down not because a vulnerability does not exist, but because proving its real-world impact requires environment-specific analysis that neither side budgeted for. Researchers are asked to build realistic PoCs, demonstrate exploit chains, or validate assumptions across configurations they do not control. Maintainers are asked to reason about downstream usage patterns far beyond their original design scope. Both are performing system-level analysis without compensation. Maintainers are justified in pushing back against low-signal reports. Researchers are justified in feeling that the bar for engagement keeps rising. The system offers no obvious place to send the cost. Why should CISOs care and what can they do? For cybersecurity leaders, the implications are concrete. When disclosure channels are perceived as slow, dismissive, or adversarial, researchers disengage. Some go quiet. Others escalate publicly. A few take ethically questionable paths. None of these outcomes improve security posture. In practice, most of the levers that determine these outcomes sit with software vendors, platform providers, and open-source stewards. In those environments, CISOs oversee product security incident response teams (PSIRTs), vulnerability intake, disclosure timelines, and researcher engagement. This is where incentives are set, researcher experience is shaped, and triage decisions determine whether cooperation compounds or collapses. For CISOs operating in vendor, platform, and open-source environments, there is no single fix. Outcomes improve materially when disclosure is treated as an operational function rather than a moral expectation. Practical steps that CISOs in this space can take include: Establish and honor service-level expectations for acknowledgement and triage, even when fixes take time. Assign clear ownership for the researcher experience, not just vulnerability intake. Publish severity triage criteria and document rationale when disagreeing with reports. Avoid treating CVSS scores as deployment gates without environmental context. Use third-party disclosure programs or coordinators to absorb overflow and reduce friction. Offer meaningful non-cash recognition where bounties are not feasible. Commit to upstreaming fixes when patching dependencies internally. Provide legal safe harbor language for good faith testing to reduce adversarial escalation. Fund the open-source dependencies your organization relies on, whether through sponsorship, contracts, or consortiums. Be explicit about what level of proof is expected and what isn’t. None of these steps require endorsing exploit sales or paying ransoms for vulnerabilities. They require acknowledging that ethical behavior does not scale on goodwill alone. For CISOs in healthcare, finance, education, and other consuming organizations, the risk manifests differently but no less acutely. When disclosure breaks down upstream, it surfaces downstream as delayed patches, brittle compensating controls, and security decisions driven by incomplete or distorted signals. Left unaddressed, those gaps can become governance failures. Organizations may be unable to explain why known vulnerabilities remained unpatched, why risk signals were discounted, or why vendor assurances were accepted without scrutiny. Enterprise CISOs influence this system through procurement requirements, vendor accountability, and how rigorously vulnerability data is contextualized before triggering disruption. Treating disclosure quality as a third-party risk factor is no longer optional. View the full article

Gorodenkoff | shutterstock.com In den letzten Jahren hat künstliche Intelligenz (KI) ihre Tentakel über die globale Technologielandschaft ausgebreitet. Das verdeutlicht unter anderem auch der zunehmende Einsatz von Automatisierung und autonomen Technologien in diversen Branchen und Sektoren. Und während die Welt noch mit dem Impact der KI ringt, steht mit Quantencomputing bereits das “next big thing” in den Startlöchern. Das Aufeinandertreffen dieser beiden Technologien verspricht, der nächste große technologische Schauplatz zu werden. Dieser könnte nicht nur Computing und Cybersicherheit, sondern sogar geopolitische Machtstrukturen entscheidend prägen. Denn während KI-Algorithmen dafür bekannt sind, Muster zu erkennen und aus den ihnen zugeführten Daten zu lernen, versprechen Quantencomputer, mehrere Wege gleichzeitig zu erkunden. Das legt nahe, dass mit der Technologie eine Revolution in Sachen Datenverarbeitung bevorsteht. Anstelle von Bits (0en und 1en), wie sie von KI-Systemen verwendet werden, nutzen Quantencomputer Qubits, die dank der Prinzipien der Superposition und Verschränkung gleichzeitig in mehreren Zuständen existieren können. So verspricht ein gut konzipiertes Quantensystem, Probleme in Mikrosekunden zu lösen, für die konventionelle Computer Jahre benötigen würden. Das könnte beispielsweise dazu beitragen, künftig manipulationssichere Kommunikationsinfrastrukturen zu etablieren – Stichwort Quantum Key Distribution (QKD). KI trifft Quantum Computing – ein zweischneidiges Schwert Je mehr Daten in einen KI-Algorithmus einfließen, desto besser sind im Regelfall die Ergebnisse. Besonders großangelegte KI-Systeme wie ChatGPT oder DeepMind AlphaFold haben jedoch regelmäßig mit den Grenzen zu kämpfen, die ihre zugrundeliegende Hardware aufwirft. Mit Quantencomputern würden sich diese Limitationen in Luft auflösen: Sie nutzen Quantum Machine Learning (QML), um etwa Muster zu erkennen oder Simulationen zu optimieren. Darüber hinaus macht das Konzept des QML-Trainings es sehr wahrscheinlich auch überflüssig, Echtzeit-Trainingsdaten über riesige Rechenzentren bereitzustellen. In der Praxis wird die Kapazität von Quantencomputern Ergebnisse in Mikrosekunden liefern. Das macht etwa globale Echtzeit-Klimasysteme und Real-Time-Finanzmarktsimulationen möglich. Doch die schöne neue Quanten-Zukunft hat auch eine dunkle Seite: Schließlich kann die Technologie auch von Cyberkriminellen als Waffe instrumentalisiert werden. Mit den resultierenden, quantengestützten Cyberbedrohungen könnten aktuelle Verschlüsselungsverfahren wie ECC, RSA oder AES ausgehebelt werden – wobei die beiden erstgenannten etwa von Finanzinstituten genutzt werden, um Online-Transaktionen abzusichern. Würden diese Encryption-Methoden kompromittiert, wäre die Vertraulichkeit verschlüsselter Daten passé. Der Tag, an dem es dazu kommt, bezeichnet man auch als „Q-Day“. Und es lauern noch weitere, quantengestützte Gefahren. So könnten Cyberkriminelle die Technologie etwa auch einsetzen, um: Passwörter zu knacken, digitale Zertifikate zu fälschen, oder Deepfakes von KI-Systemen zu erstellen. Der Weg in die Quanten-Zukunft Sowohl Unternehmen als auch Regierungsinstitutionen, bereiten sich bereits auf den Q-Day vor. Das britische National Cyber Security Centre (NCSC) verfolgt etwa einen stufenweisen Ansatz, um bis zum Jahr 2035 sämtliche seiner Systeme entsprechend zu härten. In den USA soll die Umstellung der nationalen Sicherheitssysteme ähnlich laufen – hier ist 2030 das Ziel. Diese Bemühungen sind ein proaktiver Verteidigungsansatz, der darauf fokussiert, quantenresistente Verschlüsselungsmodelle und adaptive Cybersicherheitsrichtlinien zu entwickeln, die die Sicherheit kryptografischer Schlüssel im nahenden Quantenzeitalter gewährleisten können. Weil auch Quanten-Systeme auf Wahrscheinlichkeiten basieren und nicht auf Gewissheiten, besteht die Herausforderung für diejenigen, die diese Innovationen entwickeln, nicht nur darin, die schnellsten und effizientesten Kombinationsmöglichkeiten von KI- und Quantensystemen aufzutun. Es geht dabei auch und insbesondere um das Thema Trust. Dieses Vertrauen müsste in Form von Cybersecurity Frameworks und -Regulierungen aufgebaut werden, die die Sicherheit, Transparenz und Governance optimieren. Das kann auch dazu beitragen, die Themenfelder Post-Quanten-Kryptografie, KI-Audits, Observability und Ethik anzugehen, die die Grundlage für widerstandsfähige digitale Ökosysteme bilden werden. Auch wenn KI und Quantencomputing die menschliche Intelligenz nicht ersetzen werden, werden ihre Spuren in nicht allzu ferner Zukunft überall zu sehen sein. Die eigentliche Frage ist dabei jedoch, ob sich unsere Gesellschaft an das Tempo dieser technologischen Entwicklungen anpassen kann – bevor sie von ihr beherrscht wird. Trotz aller positiven Aussichten ist die Gefahr groß, dass die Kombination aus Quantum Computing und KI die Grundlagen des digitalen Vertrauens und der Privatsphäre, auf denen moderne Gesellschaften beruhen, untergraben. Und angesichts des immer näher rückenden Q-Day steigt auch die Dringlichkeit, sich auf die Post-Quanten-Welt vorzubereiten. Für Unternehmen, Regierungen und Cybersicherheitsexperten heißt das in erster Linie, über die Innovation und den technologischen Fortschritt, den die Technologien mit sich bringen, hinauszublicken und die Resilienz in den Fokus zu nehmen. Das wird massive Investitionen erfordern, um ethische KI-Governance, Regulierungsrahmen und Vorschriften sowie Post-Quanten-Kryptografie-Standards in bestehenden Systemen zu fördern. (fm) Dieser Beitrag wurde im Rahmen des englischsprachigen Experten-Netzwerks von Foundry veröffentlicht. View the full article

View the full article