KI verändert den Softwarebestand auf Entwicklerrechnern

Wer eine Entwicklungsumgebung manuell einrichtet, der entwickelt ein Bewusstsein dafür, welche Komponenten er benötigt und welche nicht. Ein KI-Agent verfolgt ein anderes Ziel: Er soll eine konkrete Aufgabe möglichst schnell und zuverlässig erledigen. Benötigt ein Projekt eine bestimmte .NET-Version, kann der Agent das entsprechende SDK installieren. Für eine andere Aufgabe kommt möglicherweise eine weitere Version hinzu. Die alte Installation wird dadurch nicht überflüssig – und schon gar nicht automatisch entfernt.

So können sich auf einem Entwicklerrechner im Laufe der Zeit zahlreiche SDK-Versionen verschiedener .NET-Generationen und Feature-Bands ansammeln. Das ist zunächst kein Fehler: Die parallele Installation unterschiedlicher SDK-Versionen ist bei .NET grundsätzlich vorgesehen und für die Entwicklung verschiedener Projekte sogar notwendig. Bleiben allerdings nicht mehr benötigte Versionen dauerhaft auf dem System, entsteht ein Security-Problem. Besonders tückisch wird die Situation beim klassischen Patch-Management.

Gepatcht bedeutet nicht zwangsläufig sicher

Microsoft veröffentlicht regelmäßig Sicherheitspatches für .NET. Diese schließen Schwachstellen in den jeweiligen Runtime-Komponenten und können dabei eine Vielzahl bekannter Schwachstellen adressieren, deren Schweregrad von „hoch“ bis „kritisch“ reicht. Die Updates ersetzen jedoch nur die eigene Runtime-Komponente (WinRT), die über Windows Update oder WSUS (Windows Server Update Services) bereitgestellt wird. Sie können die Laufzeitversion, von der ein bereits installiertes SDK noch abhängt, nicht entfernen. Das Update erkennt diese Abhängigkeit und verzichtet auf die Bereinigung, um das SDK nicht unbrauchbar zu machen.

Es handelt sich dabei nicht nur um eine einzige Laufzeitumgebung. Jedes SDK enthält eigene Kopien der .NET-Laufzeitumgebung, der ASP.NET-Core-Laufzeitumgebung und der .NET-Desktop-Laufzeitumgebung, die alle nebeneinander im selben Ordner „dotnet\shared“ liegen – ein Satz pro SDK-Feature-Band –, wobei ältere Versionen erst entfernt werden, wenn keine Abhängigkeiten mehr bestehen. Von der Konzeption her sind .NET-SDK-Feature-Bands so ausgelegt, dass sie nebeneinander existieren können, und nichts entfernt automatisch SDKs aus anderen Bändern oder Hauptversionen.

Ein aktualisiertes System erscheint deshalb in herkömmlichen Patch- und Compliance-Dashboards zunächst als sicher. Das bedeutet allerdings nicht zwingend, dass auf dem Rechner keine verwundbaren .NET-Komponenten mehr vorhanden wären. Der Grund liegt in der Architektur des .NET-SDK. Ein SDK bringt eigene Runtime-Komponenten mit, darunter die .NET Runtime, die ASP.NET Core Runtime und die .NET Desktop Runtime. Diese Komponenten werden parallel zu anderen Versionen installiert und befinden sich unter anderem im Verzeichnis dotnet\shared.

Ein Sicherheitsupdate für eine eigenständige Runtime entfernt nicht automatisch alle älteren Runtime-Versionen, die ein installiertes SDK noch benötigt. Solange entsprechende Abhängigkeiten bestehen, bleiben diese Komponenten auf dem System. Damit können zwei scheinbar widersprüchliche Zustände gleichzeitig existieren: Das zentrale Patch-Management meldet einen aktuellen Stand, während auf demselben Rechner eine ältere, weiterhin ausführbare und verwundbare Runtime-Version vorhanden ist.

Veraltete Entwicklungs-Kits als blinder Fleck

In einer Entwicklungsumgebung können sich mehrere gemeinsam genutzte Runtime-Verzeichnisse nebeneinander befinden. Enthalten sie unterschiedliche .NET-Hauptversionen, vervielfacht sich die Zahl der installierten Runtime-Komponenten. Beim Überprüfen eines solchen Systems kann sich beispielsweise zeigen, dass eine ältere ASP.NET-Core-Version weiterhin vorhanden ist und eine inzwischen bekannte Schwachstelle aufweist – obwohl eine andere Installation derselben Runtime auf dem Rechner bereits aktualisiert wurde.

Für einen Angreifer ist entscheidend, welche verwundbaren Komponenten tatsächlich auf dem Endpunkt vorhanden und ausführbar sind. Damit verschiebt sich die sicherheitsrelevante Frage von „Wurde der Patch installiert?“ zu „Welche verwundbaren Komponenten existieren noch auf dem System?“.

Visual Studio verschärft das Problem

Eine zusätzliche Komplexität entsteht durch Visual Studio. SDKs, die zusammen mit Visual Studio installiert werden, unterliegen nicht zwangsläufig demselben Aktualisierungsmechanismus wie eigenständige .NET-Runtimes. In vielen Fällen hängt ihre Aktualisierung an der Pflege der Visual-Studio-Installation. Das kann dazu führen, dass ein Sicherheitsupdate für das Betriebssystem oder eine eigenständige .NET-Runtime erfolgreich eingespielt wurde, während ältere Komponenten innerhalb einer Visual-Studio-Installation weiterhin vorhanden sind.

Hinzu kommt das typische Verhalten in Entwicklungsumgebungen: Updates der IDE werden häufig zurückgestellt. Gründe dafür können die Kompatibilität von Erweiterungen, bestehende Build-Prozesse oder schlicht die Sorge sein, eine funktionierende Entwicklungsumgebung zu verändern. Damit treffen zwei Entwicklungen aufeinander: KI-Tools erhöhen die Geschwindigkeit, mit der neue SDKs und Abhängigkeiten auf Entwicklerrechner gelangen. Gleichzeitig können bestehende Prozesse dafür sorgen, dass diese Komponenten lange Zeit nicht wieder entfernt oder aktualisiert werden.

Klassische Compliance-Scans reichen nicht mehr aus

Für Unternehmen entsteht daraus ein strukturelles Problem. Klassische Endpoint- und Compliance-Lösungen konzentrieren sich oft auf den Status bekannter installierter Produkte und deren Patches. Ein Gerät, auf dem die aktuelle eigenständige .NET-Runtime installiert ist, kann deshalb als konform erscheinen. Eine vollständige Bestandsaufnahme muss berücksichtigen, welche .NET-SDK-Versionen installiert sind, welche Runtime-Versionen diese SDKs mitbringen, welche Visual-Studio-Komponenten vorhanden sind, welche Versionen inzwischen veraltet oder verwundbar sind und welche Komponenten Entwicklungsprojekte tatsächlich noch von benötigen.

Erst die Kombination dieser Informationen ermöglicht eine realistische Bewertung des Risikos. Das ist deshalb relevant, weil Entwicklerrechner keine gewöhnlichen Arbeitsplatzsysteme sind. Sie haben häufig Zugriff auf Quellcode-Repositories, Paket-Feeds, Zugangsdaten, Zertifikate sowie Infrastrukturen für Entwicklung und Deployment. Ein kompromittierter Entwicklerendpunkt kann deshalb die Unternehmenssicherheit deutlich stärker gefährden als ein gehackter Office-PC.

KI abschalten ist keine Lösung

Aus diesem Befund lässt sich allerdings nicht ableiten, dass Unternehmen KI-Coding-Tools grundsätzlich verbieten sollten. Vielmehr muss sich das Sicherheitsmodell an die veränderte Realität der Softwareentwicklung anpassen. „Update installiert“ sollte nicht als vollständiger Sicherheitsindikator für Entwicklungsumgebungen gelten. Der Status sagt zunächst nur aus, dass eine bestimmte Komponente aktualisiert wurde.

Erforderlich ist eine Bestandsaufnahme der tatsächlich vorhandenen SDKs und Runtime-Versionen. Auf dieser Grundlage lassen sich nicht mehr benötigte Versionen identifizieren und kontrolliert entfernen. Wichtig ist es dabei, zwischen Entwicklungs- und Laufzeitabhängigkeiten zu unterscheiden. Eine Bereinigung sollte nicht einfach pauschal alte Versionen löschen, sondern zunächst prüfen, ob ein SDK oder eine Runtime noch für Builds oder andere Prozesse benötigt wird.

Sicherheitskontrolle ohne zusätzlichen Agenten

Für Unternehmen stellt sich dabei eine weitere Frage: Wie lässt sich diese Transparenz herstellen, ohne auf jedem Entwicklerrechner zusätzliche Software installieren und betreiben zu müssen? Ein möglicher Ansatz ist die inhaltsgesteuerte Erkennung. Dabei werden Informationen genutzt, die bestehende Endpoint-Management- oder Security-Agenten ohnehin erfassen – etwa installierte Anwendungen, Komponenten und Patch-Zustände. Diese Daten werden mit Sicherheitsinformationen und Regeln abgeglichen, die nicht nur einzelne Produktversionen betrachten, sondern auch Abhängigkeiten zwischen SDKs, Runtimes und Entwicklungsumgebungen.

So lässt sich beispielsweise erkennen, dass eine ältere .NET-Runtime nicht deshalb sicher ist, weil eine neuere Version auf demselben System installiert wurde. Entscheidend ist vielmehr, ob die alte Version weiterhin vorhanden ist und welche Abhängigkeiten an ihr hängen. Ein entsprechender Erkennungs- und Bereinigungsprozess kann veraltete SDK- und Visual-Studio-Versionen markieren und vor einer Entfernung zunächst prüfen, ob diese noch für Kompilierung oder andere Entwicklungsprozesse benötigt werden.

Jede Entwicklungsumgebung braucht Hygiene

Die eigentliche Herausforderung liegt damit nicht in der KI selbst. Diese Technologie beschleunigt lediglich einen Prozess, der in der Softwareentwicklung schon lange existiert: die zunehmende Zahl von Abhängigkeiten und Komponenten. Der Unterschied besteht darin, dass KI-Agenten diese Veränderungen wesentlich schneller und autonomer durchführen können. Wo ein Entwickler früher bewusst eine Entwicklungsumgebung eingerichtet und später bereinigt hat, können heute innerhalb kurzer Zeit zahlreiche automatische Installations- und Konfigurationsvorgänge stattfinden.

Damit wird die Pflege der Entwicklungsumgebung zu einem Bestandteil des Software-Supply-Chain- und Endpoint-Security-Managements. Unternehmen sollten deshalb nicht nur kontrollieren, welchen Code KI erzeugt, sondern auch beobachten, welche Softwarekomponenten durch den Einsatz von KI auf den Entwicklerrechnern entstehen.

Der blinde Fleck liegt im Bestand

KI-Coding-Tools beschleunigen die Softwareentwicklung, können aber auch den Bestand an installierten Komponenten und Abhängigkeiten schneller wachsen lassen. Für Unternehmen reicht es deshalb nicht aus, allein den Patch-Status ihrer Entwicklerrechner zu überwachen. Sie müssen wissen, welche SDKs, Runtimes und Entwicklungswerkzeuge tatsächlich installiert sind, welche davon noch benötigt werden und wo bekannte Schwachstellen bestehen. Erst diese Transparenz ermöglicht es, Sicherheitsrisiken gezielt zu reduzieren, ohne notwendige Entwicklungsumgebungen zu beeinträchtigen. jf

The post Vibe Coding schafft neue Sicherheitsrisiken appeared first on IT-Matchmaker.news.

Verlässliche Identitäten und eindeutig zuordenbare Zugänge sind allerdings nicht nur im Krisenfall relevant. Sie gehören ebenso zum täglichen Produktionsbetrieb und müssen dort funktionieren, ohne Belegschaft und Prozesse auszubremsen. Doch gerade auf dem Shopfloor ist das anspruchsvoll: Mitarbeiter wechseln zwischen Schichten und Arbeitsplätzen, mehrere Personen nutzen dieselben Terminals, externe Techniker benötigen zeitlich begrenzte Berechtigungen. Gleichzeitig verteilen sich diese Zugriffe auf On-Premises-Systeme, Cloud-Dienste, Legacy-Anwendungen und spezialisierte Produktionslösungen. Vor diesem Hintergrund wird das Zugriffsmanagement in der Fertigung zu einer organisatorischen und technischen Herausforderung.

Zu dieser technischen und organisatorischen Komplexität kommt weiterer Handlungsdruck: Laut IBM X-Force war die Fertigungsindustrie 2025 zum fünften Mal in Folge der am häufigsten von Cyberangriffen betroffene Sektor. Zudem verschärfen regulatorische Anforderungen durch NIS2 die Lage: Seit der deutschen Umsetzung Ende 2025 zählen Zugriffskontrolle sowie Multi-Faktor- oder kontinuierliche Authentifizierung für betroffene Unternehmen ausdrücklich zu den Anforderungen an das Cyberrisikomanagement.

Die Sicherheit und Nachvollziehbarkeit dürfen jedoch nicht zulasten der Produktionsabläufe gehen. Dauert der Login an einer Maschine zu lange oder funktioniert er nicht zuverlässig, kostet das wertvolle Zeit. Im schlimmsten Fall führt es zum Produktionsstillstand.

Vier Maßnahmen für wirksames Zugriffsmanagement in der Fertigung

Doch wie lässt sich das Zugriffsmanagement in der Fertigung in der Praxis sicher und zugleich nutzerfreundlich umsetzen? Vier Maßnahmen sind dafür besonders relevant:

1. Robuste und schnelle Anmeldeverfahren statt Passwörter

Klassische Passwörter passen immer weniger zu den Anforderungen moderner Produktionsabläufe. Wiederholte Eingaben kosten Zeit, Kennwortwechsel sorgen besonders an gemeinsam genutzten Terminals für Probleme, vergessene oder gesperrte Anmeldedaten erhöhen den Supportaufwand. Hinzu kommt das Phishing-Risiko: Gelangt ein Angreifer an ein Passwort, kann er damit im Extremfall weitere Systeme kompromittieren.

Passwortlose Verfahren hingegen schaffen den Brückenschlag zwischen Sicherheit und Benutzerfreundlichkeit. Mitarbeiter authentifizieren sich je nach Rolle, System und Umgebung mit dem Anmeldeverfahren, das zu ihnen passt – etwa einem Sicherheitsschlüssel oder einer Smartcard – und bestätigen ihre Identität per PIN. Der Clou: Selbst wenn es einem Hacker gelingt, die PIN auszuspähen, nutzt sie ihm ohne das physische Authentifizierungsmittel wenig.

Auf dem Shopfloor zählt allerdings auch die Handhabung. Gerade bei häufigen Maschinenwechseln oder in rauen Produktionsumgebungen ist es wenig praktikabel, an jeder Station einen Hardware-Token einzustecken und einen vollständigen Login zu durchlaufen. Kontaktlose Verfahren können hier den Zugang vereinfachen.

Praxistipp: Bei FIDO-basierten, phishingresistenten Verfahren sollte die IT festlegen, welche Sicherheitsschlüssel und Token zulässig sind, wem sie zugeordnet sind und wie lange sie genutzt werden dürfen. Bei Bedarf bestätigt eine erneute Authentifizierung, dass der Nutzer das jeweilige Authentifizierungsmittel noch besitzt.

2. Sichere Anmeldung an gemeinsam genutzten Arbeitsplätzen

Gemeinsam genutzte Arbeitsstationen gehören zum Produktionsalltag. Mit jedem Schichtwechsel ändern sich die Nutzer an Maschinen und Terminals; hinzu kommen externe Dienstleister und befristet eingesetztes Personal. Ein gemeinschaftliches Benutzerkonto mag praktisch erscheinen, erschwert jedoch die eindeutige Zuordnung eines Zugriffs zu einer bestimmten Person und damit spätere Untersuchungen und Audits. Zudem steigt das Risiko, dass missbräuchliche oder unbefugte Zugriffe unentdeckt bleiben.

Besser eignet sich ein Anmeldekonzept, mit dem sich auch an gemeinsam genutzten Arbeitsplätzen jeder User persönlich identifizieren lässt und das trotzdem schnelle Wechsel ermöglicht. Dabei erfolgt die Anmeldung nicht über ein an das Gerät gebundenes Gemeinschaftskonto, sondern mit der persönlichen Identität des jeweiligen Mitarbeiters.

Praxistipp: Bei häufigen Arbeitsplatzwechseln können kontaktlose FIDO-basierte Verfahren Zeit sparen. Nach der ersten Authentifizierung mit Sicherheitsschlüssel und PIN kann der Mitarbeiter je nach eingesetztem Verfahren innerhalb eines definierten Zeitfensters an weitere Stationen wechseln, ohne den vollständigen Anmeldevorgang zu wiederholen. Die erneute Anmeldung kann beispielsweise durch das Auflegen eines Sicherheitsschlüssels erfolgen.

3. Nachvollziehbare Zugriffe

Bei Störungen, Sicherheitsvorfällen oder Audits zählt nicht nur, ob ein Nutzer grundsätzlich eine Berechtigung besaß. Die IT muss auch nachvollziehen können, wer wann auf welches System zugegriffen hat und welche Richtlinie diesen Zugang erlaubt hat.

Gemeinschaftskonten und fragmentierte Protokolle erschweren diese Zuordnung. Ein richtlinienbasiertes Zugriffsmanagement verknüpft dagegen Nutzer mit den jeweiligen Berechtigungen und Zugriffsereignissen. So lassen sich Vorfälle schneller untersuchen, Zugänge bei Audits und Compliance-Prüfungen leichter belegen und Auffälligkeiten schneller einordnen.

Perspektivisch betrifft diese Aufgabe auch nichtmenschliche Identitäten. Nutzen beispielsweise KI-Agenten automatisiert Systeme und Daten, müssen Unternehmen auch für sie festlegen, welche Berechtigungen gelten und wie sich Aktivitäten nachvollziehen lassen.

Praxistipp: Berücksichtigen Sie externe Nutzer von Anfang an in Ihrem Berechtigungskonzept. Legen Sie fest, auf welche Systeme Dienstleister, Lieferanten, temporäre Mitarbeiter oder KI-Agenten zugreifen dürfen und nach welcher Richtlinie sie Zugang erhalten.

4. Einheitliche Zugangsverfahren über unterschiedliche Systeme hinweg

Ein wirksames Zugriffsmanagement in der Fertigung muss deshalb auch mit heterogenen IT-Umgebungen umgehen können. Kaum ein Produktionsbetrieb arbeitet ausschließlich mit modernen Cloud-Anwendungen. Häufig treffen diese auf lokale Systeme, Legacy-Anwendungen, Remote-Zugänge und spezialisierte Produktionslösungen. Die Systemlandschaft selbst lässt sich meist nicht vereinheitlichen – wohl aber der Zugang dazu. Einheitliche Anmeldeverfahren reduzieren den Verwaltungsaufwand und erleichtern konsistente Sicherheitsregeln, ohne dass Unternehmen ihre bestehende Infrastruktur austauschen oder vollständig in die Cloud verlagern müssen. Single Sign-on, sichere Remote-Zugänge und eine zentrale Steuerung lassen sich dabei über unterschiedliche Umgebungen, Werke und Sicherheitszonen hinweg einsetzen. Je nach System und Schutzbedarf können dennoch unterschiedliche Sicherheitsanforderungen gelten.

Praxistipp: Unternehmen müssen nicht sämtliche Zugangsszenarien auf einmal umstellen. Sie können mit einem besonders relevanten Anwendungsfall starten und das Zugriffsmodell schrittweise erweitern. Je nach Infrastruktur und regulatorischen Anforderungen kommt eine vollständig lokale oder hybride Umsetzung infrage.

Wie sich ein solches Anmeldeverfahren in der Praxis ausgestalten kann, zeigt das folgende Beispiel von Pointsharp.

The post Zugriffsmanagement in der Fertigung: Sicherheit ohne Produktionsbremse appeared first on IT-Matchmaker.news.

Mehr als 5.000 Menschen in Deutschland gaben für die Studie Auskunft über ihren digitalen Alltag, ihr Sicherheitsgefühl und ihre Erfahrungen mit IT-Sicherheit gegeben. Die Bedrohungslage bleibt hoch: Fast die Hälfte der Befragten (46 Prozent) sieht organisierte Cyberkriminelle, die mit gezielten Attacken Profit erzielen, als größte Gefahr.

In der Abwehr fehlen den Unternehmen Mitarbeiter, um sicherheitsrelevante Updates zeitnah einzuspielen und Warnmeldungen aus den Sicherheitslösungen zu bewerten. Gleichzeitig wächst der Druck durch eine Bedrohungslage, in der künstliche Intelligenz (KI) eine zunehmend größere Rolle spielt. Damit wird deutlich: IT-Sicherheit ist längst nicht mehr nur eine Frage der richtigen Technologie. Unternehmen brauchen auch ausreichend qualifizierte Menschen, die diese Technologien wirksam einsetzen können.

KI verschärft Angriffe und hilft bei der Abwehr

Künstliche Intelligenz verändert die Bedrohungslage auf beiden Seiten: Einerseits können Cyberkriminelle Angriffe schneller und effizienter durchführen. Andererseits hilft KI dabei, Attacken früher zu erkennen und schneller darauf zu reagieren. KI ist längst ein wichtiger Bestandteil der Cyberabwehr: 44 Prozent der Befragten sehen darin einen besonderen Nutzen beim frühzeitigen Erkennen von Angriffen. Für jeden Dritten hat der KI-Einsatz Vorteile beim automatisierten Auswerten großer Datenmengen sowie in automatisierten Reaktionen auf Sicherheitsvorfälle.

„Entscheidend ist nicht, ob wir KI in der Cyberabwehr einsetzen, sondern wie wirksam wir ihre Möglichkeiten nutzen“, erläutert Andreas Lüning, Mitgründer und Vorstand von G DATA Cyberdefense. „Unternehmen sollten diese Chance ergreifen, um ihre Abwehr nachhaltig zu stärken.“

IT-Sicherheit wird zum Wirtschaftsfaktor

Die wirtschaftliche Bedeutung von Cybersicherheit zeigt sich in vier Zahlen:

• 2030 werden die Kosten durch Cyberkriminalität schätzungsweise 16,9 Billionen Euro betragen. Gegenüber 2018 entspricht das einer Steigerung um 2.240 Prozent.
• 68 Prozent aller Cyberangriffe erfolgen über eine E-Mail mit Schadsoftware.
• Im Jahr 2025 lag die Aufklärungsquote der erfassten Cybercrime-Fälle in Deutschland bei 31 Prozent.
• Der Umsatz mit Security-Services hat sich weltweit innerhalb von zehn Jahren mehr als verdoppelt (2016: 11,5 Mrd. Euro, 2026: 25,4 Mrd. Euro).

„Cybersicherheit braucht mehr als gute Technologien“, betont Susanne Risch, Chefredakteurin von Brand eins Corporate Services. „Sie lebt vom Austausch, vom gemeinsamen Lernen und von Menschen, die Verantwortung übernehmen.“

The post IT-Sicherheit leidet unter Fachkräftemangel appeared first on IT-Matchmaker.news.

In industriellen Umgebungen sind Unternehmen häufig stark von spezialisierten Dienstleistern abhängig. Deren Fernwartungszugänge vergrößern die Angriffsfläche. Wird ein externer Anbieter oder ein legitimer Wartungszugang kompromittiert, können Angreifer darüber in OT-Umgebungen eindringen.

„Cyberkriminelle machen sich die digitale Lieferkette zunutze, um Unternehmen zu kompromittieren“, sagt Andreas Süß, CEO DACH bei Advens. „Deshalb sollten sich Unternehmen stets darüber im Klaren sein, welche Partner auf ihre Systeme zugreifen, welche Berechtigungen sie besitzen und wie diese Zugriffe überwacht werden.“

Um das Risiko durch Supply-Chain-Angriffe zu reduzieren, sollten Unternehmen folgende Sicherheitsmaßnahmen umsetzen:

1. Systeme zügig aktualisieren

Kritische Schwachstellen in öffentlich erreichbaren Anwendungen und verbreiteten Unternehmenslösungen sollten priorisiert behandelt werden. Idealerweise installieren Unternehmen verfügbare Sicherheitsupdates innerhalb von 72 Stunden.

2. Dienstleister und Abhängigkeiten erfassen

Unternehmen sollten ein vollständiges Verzeichnis ihrer Softwareanbieter, Cloud-Dienste, IT-Partner und externen Fernwartungszugänge führen. Abhängigkeiten sollten anhand ihrer Auswirkungen auf den Geschäftsbetrieb priorisiert werden.

The post 8 Kniffe schützen vor Supply-Chain-Angriffen appeared first on IT-Matchmaker.news.

Genau jetzt beginnt allerdings der schwierige Teil. Cyberresilienz durch sichere Kommunikation bedeutet, dass Unternehmen Sicherheitsvorfälle erkennen, bewerten und auch unter Druck kontrolliert bewältigen können. Für erhebliche Vorfälle verlangt die Richtlinie eine erste Warnung innerhalb von 24 Stunden und eine ausführliche Meldung innerhalb von 72 Stunden. Das funktioniert nur dann, wenn Zuständigkeiten, Meldewege und Kommunikationskanäle vorher geklärt und ausreichend etabliert wurden.

Die Lücke zwischen Plan und Praxis

Auf dem Papier sind viele Organisationen gut vorbereitet. Im Idealfall wissen Verantwortliche, wer im Krisenfall wann über welche Kanäle aktiv wird. Ein realer Angriff folgt jedoch selten dem Ablauf eines Audits. Ist das E-Mail-System betroffen, wechseln Teams auf Messenger. Kann ein externer Berater nicht auf die interne Plattform zugreifen, erhält er Dateien über einen kurzfristig eingerichteten Link. Muss die Geschäftsführung schnell entscheiden, entsteht eine neue Chatgruppe auf privaten Geräten.

Genau hier zeigt sich die eigentliche Lücke. In dem von Kommunikationsanbieter Wire in Auftrag gegebenen Secure Collaboration Report 2026 hielten sich 62 Prozent der befragten IT-, Security- und Compliance-Verantwortlichen für gut oder sehr gut auf regulatorische Anforderungen vorbereitet. Gleichzeitig gaben 48 Prozent an, sensible Informationen zumindest gelegentlich über ungeeignete Kanäle zu teilen. Bei 61 Prozent blieben Zugriffe auf gemeinsam genutzte Dateien länger aktiv als vorgesehen.

Im Krisenfall ist abgesicherte Kommunikation wichtig

Viele Unternehmen investieren in Angriffserkennung, Zugangsschutz und Backups. Doch selbst gute technische Schutzmaßnahmen verhindern nicht jeden Angriff. Im Ernstfall kommt es darauf an, ob Menschen weiterhin sicher zusammenarbeiten können.

Ein Krisenstab braucht einen vertrauenswürdigen Raum, in dem Entscheidungen vorbereitet, Informationen bewertet und Aufgaben verteilt werden. Die Geschäftsleitung muss erreichbar bleiben. IT, Recht, Kommunikation und externe Spezialisten müssen zusammenarbeiten können, ohne auf eine möglicherweise kompromittierte Infrastruktur zuzugreifen. Fehlt diese Möglichkeit, verzögern sich Entscheidungen. Informationen lassen sich schlecht überprüfen, und sensible Inhalte wandern auf Kanäle, die sich nicht mehr zentral kontrollieren lassen.

Schatten-IT ist selten nur ein Disziplinproblem

Viele Unternehmen reagieren auf unsichere Kommunikationswege mit neuen Richtlinien und zusätzlichen Schulungen. Das ist verständlich, aber es löst nicht das grundlegende Problem. Sobald die offiziellen Lösungen ihre Arbeit erschweren oder gar nicht verfügbar sind, greifen Mitarbeiter häufig auf private Messenger, persönliche E-Mail-Konten oder frei verfügbare File-Sharing-Dienste zurück. Das betrifft vor allem die Zusammenarbeit mit externen Beteiligten, mobile Teams und Situationen mit hohem Zeitdruck.

Ein System, das im normalen Arbeitsalltag als zu kompliziert empfunden wird, setzt sich in einer Krise erst recht nicht durch. Das gilt auch für Notfallkanäle, die zwar dokumentiert, aber nie praktisch erprobt wurden. Schatten-IT ist deshalb nicht immer ein Zeichen fehlender Sensibilität. Sie kann darauf hinweisen, dass Sicherheitsvorgaben und Arbeitsabläufe nicht zusammenpassen.

Der ideale NIS2-Test startet ohne E-Mail

Der ideale Praxistest beginnt dort, wo die gewohnten Systeme nicht mehr verfügbar oder vertrauenswürdig sind. Unternehmen sollten deshalb prüfen, wie sie handlungsfähig bleiben, wenn E-Mail, zentrale Identitätsdienste und die übliche Kollaborationsplattform gleichzeitig ausfallen. Das Management muss klären, wie im Krisenfall die Entscheider zusammenkommen, wie externe Fachleute eingebunden werden, wie sich Identitäten überprüfen, Informationen schützen und Entscheidungen dokumentieren lassen. All das muss gelingen, ohne dass Mitarbeiter auf private Kanäle ausweichen.

Ein Beispiel für eine dafür taugliche Kommunikationsplattform ist Wire. Dieser Service beinhaltet eine vollständige Suite an Messaging-, Audio-, Video- und Filesharing-Funktionen. Die Kommunikation ist nach dem Verschlüsselungsstandard MLS (Messaging Layer Security) geschützt. Das sperrt Hacker aus und stellt sicher, dass der Service stets vertrauenswürdig arbeitet.

Wer als Führungskraft die oben genannten Fragen überzeugend beantworten kann, hat mehr erreicht als die formale NIS2-Compliance. Wer lediglich auf Registrierung, Richtlinien und freigegebene Tools verweist, hat erst den einfachen Teil erledigt. Entscheidend für Cyberresilienz durch sichere Kommunikation ist, ob die Organisation auch dann kontrolliert handeln kann, wenn die vertrauten Systeme nicht mehr zur Verfügung stehen. jf

The post Cyberresilienz braucht sichere Kommunikation appeared first on IT-Matchmaker.news.

Eine weitere Gefahr sind Angriffe zur Datenspionage. Statistiken der europäischen Agentur für Cybersicherheit ENISA und des Computer Emergency Response Teams CERT-EU zeigen, dass die Gesamtzahl der Angriffe auf alle Branchen kontinuierlich von Jahr zu Jahr steigt. Checkpoint hatte für das Sommerquartal 2025 anhand der Auswertung von Data-Leakage-Seiten eine im Jahresvergleich steigende Aktivität der Hacker belegt.

Um die risikobehaftete Urlaubszeit zu überstehen, empfehlen ENISA und andere Organisationen oder Unternehmen eine klare Strategie. Für die IT-Sicherheit im Urlaub kommt es dabei vor allem auf eine gute Vorbereitung vor der Sommerperiode, strenge Kontrollen während dieser Monate sowie die Analyse der nach dem Sommer gewonnenen Erkenntnisse, um die Maßnahmen für die Urlaubssaison im Winter anzupassen. Die Cyberresilienz-Experten von Commvault geben sechs praktische Ratschläge, wie sich IT-Verantwortliche angemessen auf die Sommerperiode vorbereiten:

1. Den Sommer-Betriebsmodus offiziell erklären

Sicherheitsexperten fordern klare Rollen, Verantwortlichkeiten und die Verfügbarkeit von Sicherheitsfunktionen. Auch das Bundesamt für Sicherheit in der Informationstechnik (BSI) warnt, dass Personalabwesenheit und Wissensmonopole Geschäftsprozesse gefährden können. Die Verantwortlichen für die Sicherheit, Sicherung und Verfügbarkeit der IT und der Daten sollten daher für die Monate Juli und August einen ‚Reduced Staff Operating Mode‘ definieren. Dieser regelt den Vorrang kritischer Services und berücksichtigt die Minimalvorgaben an eine notwendige Betriebsfähigkeit. Er benennt auch die Verantwortlichen, die Stellvertreter sowie Bereitschaftsdienste, hinterlegt die einschlägigen Kontakte in der Supply Chain und definiert Eskalationszeiten.

2. Stellvertreter benennen – Vier-Augen-Prinzip einrichten

Kein kritischer Prozess sollte von einer einzelnen Person abhängen: Administratoren, Security Operation Center sowie die Verantwortlichen für Netzwerk, Identity Access Management, Backup, Cloud, Service Desk, Einkauf/Finanzen und Kommunikationsfreigaben benötigen benannte Stellvertreter. Ebenso wichtig sind Inventare privilegierter Konten sowie deren regelmäßige Validierung.

3. Patch- und Schwachstellenüberwachung aktiv halten

Die Zahl der durch intelligente Algorithmen wie Mythos offengelegten Schwachstellen steigt. Das so beschleunigte Aufkommen von Angriffen oder Angriffsversuchen erfordert zusätzliche Aufmerksamkeit. Kritische Schwachstellen dürfen nicht bis nach den Ferien warten: Die IT-Sicherheitsverantwortlichen müssen sicherstellen, dass tägliche oder zumindest regelmäßige Checks erfolgen und Risiken priorisiert werden. Kompensierende Maßnahmen sind im Vorfeld zu testen, zu implementieren und zu dokumentieren. Generell gilt es, Schwachstellen zu überwachen, Scans durchzuführen und kritische Verwundbarkeiten schnell zu behandeln.

4. Nicht-kritische Änderungen einfrieren

Für die Urlaubszeit gilt: Notfall-Prozesse für kritische Patches und Vorfälle sind aufrechtzuerhalten, nicht Kritisches ist zu verschieben. Ein praxistaugliches Notfallmanagement verlangt, dass Patches und Änderungen geplant, genehmigt, dokumentiert und getestet sowie durch eine Recovery-Lösung abgesichert werden. Ebenso wichtig sind Änderungsverfahren mit Risikoanalyse, Tests, Rollback und Dokumentation.

5. Backup und Recovery in der Praxis überprüfen

Vor den Sommermonaten ist es wichtig, die Funktionsfähigkeit von Backups zu überprüfen. Verantwortliche sollten sich nicht nur vergewissern, ob Backups laufen, sondern, ob sie damit kritische Dienste tatsächlich wiederherstellen können. Zum Testkatalog gehören Restore-Tests sowie das Überprüfen der Integrität der Daten, Offsite-, Offline-, Immutable-Kopien, getrennte Administratorrechte und der Zugang auf eine dokumentierte Recovery auch dann, wenn das Unternehmensnetzwerk nicht verfügbar ist. Die Commvault-Experten raten zu Backup-Plänen, zu einer sicheren getrennten Speicherung, Integritätsprüfungen und regelmäßigen Wiederherstellungstests.

6. Incident-Response-Runbooks durchspielen

Noch vor der Sommerferienzeit empfiehlt sich ein sogenannter Tabletop-Test für mindestens drei Ausfallszenarien: Phishing/Account-Takeover, Ransomware/Backup-Manipulation, kritischer SaaS-/Cloud-Ausfall. Die ENISA empfiehlt getestete Incident-Response-Verfahren, Playbooks/Runbooks und jährliche Tests mit Lessons Learned.

IT-Sicherheit im Urlaub braucht klare Prioritäten

IT-Sicherheit im Urlaub bedeutet daher vor allem, personelle Engpässe frühzeitig abzufedern, kritische Prozesse abzusichern und auf mögliche Sicherheitsvorfälle vorbereitet zu sein. „Da  Cyberkriminelle zunehmend Künstliche Intelligenz nutzen, müssen Unternehmen in der Urlaubszeit menschliche und technische Fähigkeiten koordinieren, um eine angemessene Resilienz zu erreichen“, berichtet Mark Molyneux, Field CTO beim Security-Spezialisten Commvault. „Um den Druck auf die IT-Teams zu reduzieren, sollten im Sommer nichtkritische geschäftliche Änderungen reduziert werden. So bekommen die Administratoren Zeit, ihre Prozesse anzupassen. Die Urlaubszeit sollte nicht zum Krisensommer werden – sie sollte vielmehr der Moment sein, in dem die Teammitglieder ihre Stärken zur Geltung bringen.

The post IT-Sicherheit im Urlaub: 6 Maßnahmen für eine sichere Ferienzeit appeared first on IT-Matchmaker.news.

The post Netzwerksicherheit in fünf Stufen appeared first on IT-Matchmaker.news.

Mythos 1: Security kann man später ergänzen.

Faktencheck: Nein, genau das ist das Problem.

Die Vorstellung, Sicherheitsfunktionen erst nachträglich zu integrieren, ist weit verbreitet. In der Praxis entstehen sicherheitskritische Entscheidungen jedoch bereits im Design: etwa bei Datenflüssen, Schnittstellen oder Identitätsmodellen. Werden diese Aspekte ohne Security-Perspektive umgesetzt, entstehen strukturelle Schwachstellen, die sich später nur mit großem Aufwand oder gar nicht beheben lassen. Security nachträglich hinzuzufügen, führt daher meist zu doppelten Kosten oder einem dauerhaften Risiko.

Mythos 2: Security ist eine reine IT-Aufgabe.

Faktencheck: Nein, echte Sicherheit wird ganzheitlich gedacht.

Wer sagt, Sicherheit liege primär bei IT- oder Security-Teams, verschiebt damit Verantwortung an die falsche Stelle im Lebenszyklus. In der Praxis entstehen viele Risiken bereits bei grundlegenden Produktentscheidungen. Etwa, welche Daten überhaupt gesammelt werden, wie einfach sich ein Konto anlegen lässt oder welche Funktionen für Nutzer offen zugänglich sind. Diese Entscheidungen wirken oft harmlos, bestimmen aber maßgeblich die Angriffsfläche eines Produkts. Die IT kann solche Vorgaben später nur noch absichern, aber nicht mehr grundlegend ändern. Security-by-Design bedeutet deshalb, Sicherheit von Anfang an mitzudenken – nicht erst, wenn das Produkt technisch umgesetzt ist.

The post 5 Mythen über Security-by-Design im Faktencheck appeared first on IT-Matchmaker.news.

Beim Balanceakt zwischen Risiko und Sicherheit gibt es mehrere Widersprüche.

1. Updates schließen Sicherheitslücken – und öffnen neue

Jedes Update reduziert ein bekanntes Risiko und führt im gleichen Zuge eventuell ein neues, unbekanntes ein. Denn jede Änderung an bestehender Software, sei es durch neue Funktionen, Anpassungen oder Fehlerkorrekturen, kann unerwartete Nebenwirkungen und neue Angriffsflächen erzeugen. Sicherheit wird nicht einmalig durch einen neuen Patch hergestellt, sie muss mit jedem Update neu austariert werden.

2. Je bekannter die Schwachstelle, desto größer das Risiko

Wird eine Schwachstelle entdeckt und ein entsprechender Patch geliefert, ist das erstmal eine gute Nachricht. Gleichzeitig beginnt jedoch ein Wettlauf gegen die Zeit. Angreifer analysieren Updates, um daraus Exploits abzuleiten. Fälle wie CrackArmor zeigen, wie klein das Zeitfenster zwischen Veröffentlichung und Angriffen dabei sein kann.

3. Sicherheits-Tools bergen stets ein Risiko

Sicherheitssoftware benötigt weitreichende Systemrechte, um ihre Aufgabe erfüllen zu können. Leider macht genau dieser Umstand ihre Updates besonders kritisch, wie das Beispiel von Trivy deutlich gezeigt hat. Jeder Patch verändert nicht nur eine Anwendung, sondern potenziell einen hochsensiblen Zugriffspunkt im System. Spielt ein Administrator ein fehlerhaftes oder manipuliertes Update ein, kann sich der Schaden sofort systemweit ausbreiten.

4. Fehlerhafte Updates können mehr Schaden anrichten als Angriffe

Während Cyberattacken oft gezielt einzelne Systeme bedrohen, können fehlerhafte Updates auf einen Schlag ganze Infrastrukturen in die Knie zwingen. Der CrowdStrike-Vorfall im Jahr 2024 hat eindrucksvoll vor Augen geführt, welche Auswirkungen ein einzelner fehlerhafter Rollout auf globale IT-Systeme haben kann. Der Unterschied: Ein Angriff nutzt bestehende Schwächen aus, während ein fehlerhaftes Update verschiedene Systeme gleichzeitig destabilisieren kann. Dadurch entsteht ein systemisches Risiko, das schwer vorhersehbar und kaum isolierbar ist.

Angesichts der Widersprüche rund um Software-Updates und IT-Sicherheit empfiehlt Nadine Riederer, CEO des Software-Dienstleisters Avision, mehrere Best Practices: „Wichtig ist es, größere Updates durch Backups abzusichern. So können Administratoren im Fehlerfall schnell auf eine vorherige Version zurückkehren. Sinnvoll ist es zudem, Updates zunächst in einer sicheren Testumgebung zu validieren und die Release Notes und Rückmeldungen aus der Community zu prüfen.“

Entscheidend sei stets die risikobasierte Bewertung: „Kritische Systeme sollten schnell aktualisiert werden, während weniger exponierte Systeme gegebenenfalls zunächst beobachtet und zeitlich gestaffelt aktualisiert werden können.“ Die getroffenen Entscheidungen ließen sich im Nachhinein meist einfach bewerten. In der Praxis bleibe eine kontinuierliche Abwägung zwischen Sicherheit, Stabilität und Verfügbarkeit.

The post 4 Best Practices lindern das Update-Paradoxon appeared first on IT-Matchmaker.news.

Vom 5. bis 16. Februar 2026 hat das Consultinghaus 1.060 IT‑Experten aus Unternehmen mit einer Größe von mindestens 500 Mitarbeitern in Deutschland und den USA online befragt. Die repräsentativen Ergebnisse wurden mittels Quotierung ausgewertet und berücksichtigen einen statistischen Fehler von 4,3 Prozentpunkten.

Kritisch in Sachen Sicherheit ist der sogenannte Q-Day. So bezeichnen Sicherheitsexperten den Moment, ab dem Quantencomputer bestehende Verschlüsselung brechen können. Bereits heute droht Gefahr durch das Szenario „Store now, decrypt later“. Hierbei werden aktuell verschlüsselte Daten abgefangen und gespeichert, um sie später zu entschlüsseln. Sehr wichtig ist es daher, dass Unternehmen sich zeitnah mit der Post‑Quantum‑Kryptographie befassen und ihre Produkte sowie Systeme entsprechend absichern.

Über 80 Prozent aller Unternehmen stärken ihre Sicherheit

„Der Einfluss von Quantencomputern auf die Cybersicherheit ist real und kein fernes Zukunftsszenario“, berichtet Dr. Jan Wehinger, Partner bei MHP. Unternehmen sind sich dessen offensichtlich bewusst. Post-Quantum-Kryptografie erhält nämlich aktuell deutlich mehr Aufmerksamkeit, als es die öffentliche Debatte vermuten lässt. Rund 86,6 Prozent der Organisationen in Deutschland treiben dieses Thema bereits voran – von der strategischen Planung über Pilotprojekte bis hin zur aktiven Migration. 14,3 Prozent geben sogar an, ihre kritischen Systeme bereits auf Quantum-resistente Verschlüsselung migriert zu haben.

Ein ähnliches Bild zeigt sich in den USA: Dort beschäftigen sich 87,3 Prozent der Unternehmen mit Post-Quantum-Kryptografie. 15,4 Prozent davon haben bereits entsprechende Sicherheitsmaßnahmen umgesetzt. Unternehmen ohne jegliche Aktivitäten sind klar in der Minderheit – mit 9,8 Prozent in Deutschland und 8,9 Prozent in den USA.

Deutliche Unterschiede zeigen sich jedoch bei der operativen Umsetzung. Während viele deutsche Unternehmen noch auf manuelle Inventarisierung setzen (41,7 Prozent), dominieren in den USA automatisierte Ansätze (50,8 Prozent). Genau hier entscheidet sich, wie schnell die Umstellung auf neue Kryptostandards tatsächlich gelingt.

In 5 Jahren könnte heutige Verschlüsselung brechen

Unternehmen ist der Einfluss von Quantencomputern auf IT-Sicherheit bewusst. In Deutschland erwarten 45,3 Prozent den Q-Day innerhalb der nächsten fünf Jahre bis 2031, in den USA sogar 55,2 Prozent. Weitere 39 Prozent in Deutschland und 33,5 Prozent in den USA in den nächsten zehn Jahren bis 2036. Gleichzeitig geben fast alle befragten Unternehmen an, dass sie über große Mengen sensibler Daten verfügen, die für zehn oder mehr Jahre gesichert werden müssen. Kommt der Q-Day – wie von den meisten Befragten angenommen – innerhalb der nächsten fünf Jahre, sind Teile dieser Daten schon kompromittiert.

Der geschätzte Zeitaufwand, um die technische Migration in Richtung Post-Quantum-Kryptografie abzuschließen, ist sehr hoch. Deutsche Unternehmen rechnen zum Großteil zu 53,4 Prozent mit 2 bis 5 Jahren, 27,5 Prozent sogar mit 5 bis 10 Jahren. Ein ähnliches Bild in den USA: 51,8 Prozent in 2 bis 5 Jahren sowie 21,8 Prozent in 5 bis 10 Jahren. Wer noch nichts getan hat oder sich gerade erst in der Planungsphase befindet, könnte zukünftig hinterherhinken.

Komplexe Altsysteme verzögern die Umsetzung

Mehrere Faktoren verlangsamen oder verhindern in Unternehmen die Umstellung der Sicherheitstechnologie. Ganz vorne stehen dabei komplexe Altsysteme mit 33,8 Prozent in Deutschland und 35 Prozent in den USA. Sie bremsen die Unternehmen an vielerlei Stellen aus und sind schwer überwindbar. Hier gibt es auch in den befragten Branchen kaum einen signifikanten Unterschied. An zweiter Stelle steht in Deutschland fehlendes Budget oder fehlende Ressourcen mit 19,6 Prozent, während in den USA mit 21,5 Prozent vor allem ein Mangel an interner Kryptographie-Expertise vorliegt. Mangelnde Wahrnehmung der Dringlichkeit fällt in Deutschland mit 13,8 Prozent und in den USA mit 11,3 Prozent auf den vorletzten Platz.

„Wer seine Altsysteme zügig unter Kontrolle bringt, der schafft auch den Umstieg auf Post-Quantum-Kryptografie“, erklärt Christian Zgardea, Partner bei MHP. „Auch abseits der aktuellen Sicherheitsstandards lohnt es sich, seine eigenen Systeme unter Kontrolle zu haben und Wildwuchs einzugrenzen.“

The post Bei quantensicherer Kryptografie drängt die Zeit appeared first on IT-Matchmaker.news.