Ein global tätiger Elektronikhersteller muss seinen gesamten Entwicklungsprozess auf den Cyber Resilience Act ausrichten. Keine kritischen Produkte, aber komplexe Strukturen, historisch gewachsene Prozesse und Kompetenzlücken in mehreren Abteilungen. Was folgt, ist kein Compliance-Projekt. Es ist ein Neustart der Produktsicherheit.

Ausgangssituation: Viel Unsicherheit, wenig Zeit

Durch das Inkrafttreten des Cyber Resilience Acts (CRA) muss ein global tätiger Hersteller smarter Haushaltsgeräte mit Sitz in Deutschland die Cybersicherheit seiner Produkte mit digitalen Elementen/Komponenten auch für die gesamte Produktlebensdauer sicherstellen. Es herrschte zunächst große Unsicherheit, welche Bedeutung genau der CRA für ein digitales Produkt hat und wie sich das mit bestehenden Produkt- & Softwareentwicklungsprozessen vereinbaren lässt. Unklar war ebenfalls, welche Produkte (nicht) vom CRA betroffen und welche Anforderungen des CRA bereits (teilweise) umgesetzt sind.

Der Hersteller beauftragte unser fachübergreifendes Expertenteam, eine holistische Strategie zur Erreichung der CRA-Compliance zu entwickeln, um fortan ein hohes Niveau an Cybersicherheit entlang des gesamten Lebenszyklus der digitalen Produkte zu erreichen.

Herausforderungen

Historisch gewachsene Prozesse

Die bisherigen Prozesse des Herstellers zur Produkt- und Softwareentwicklung haben sich teilweise über einen langen Zeitraum hinweg sowie uneinheitlich entwickelt. Außerdem wurden Aspekte der Cybersecurity bisher nicht sonderlich stark oder nur vereinzelt bedacht.

Komplexe Unternehmensstruktur

Die Komplexität der Unternehmensstruktur unseres global tätigen Kunden stellt eine weitere Herausforderung dar. So besteht das Unternehmen aus zahlreichen autarken Abteilungen mit teils geringen Kommunikationsschnittstellen zueinander. Cybersecurity wurde bisher nur in wenigen Abteilungen, und dort jeweils sehr unterschiedlich, berücksichtigt.

Ressourcen und Kompetenzen

Die für die Umsetzung des Cyber Resilience Act (CRA) erforderlichen personellen und finanziellen Ressourcen sowie das notwendige Fachwissen waren sehr unterschiedlich in den Abteilungen vorhanden und fehlten an einigen Stellen ganz. Infolgedessen herrschte große Unsicherheit über die erforderlichen Maßnahmen, um den Anforderungen des CRA zu entsprechen.

Integration mit anderen Regularien und unternehmensinternen Vorgaben

Da auch andere nationale, europäische und internationale Regularien auf das Unternehmen einwirken, sind Überschneidungen und Dopplungen zwischen diesen nicht bekannt und einbezogen. Außerdem decken unternehmensinterne Vorgaben diese Regularien teilweise bereits ab oder behindern deren Erfüllung. Eine Harmonisierung dieser Regularien und Vorgaben fand noch nicht statt.

Um diesen Herausforderungen zu begegnen und Lösungen zu entwickeln, wurden unser CRA Cybersecurity Expertenteam beauftragt.

Vorgehen: Strukturiert, Schritt für Schritt

Betroffene Produkte und Regularien identifizieren

Der erste Schritt für eine erfolgreiche Einführung des CRA bestand darin, die betroffenen Produkte zu identifizieren. Dafür musste das gesamte Portfolio sowie die komplexe Struktur des Unternehmens analysiert und die Produkte die unter den CRA fallen identifiziert werden. Bei der Überprüfung erfolgte außerdem eine Analyse, ob der Kunde oder das Produkt gegebenenfalls auch unter andere relevante Regularien (NIS-2 oder RED – Radio Equipment Directive) fällt.

Diese Einordnung diente als Basis für die weiteren Schritte.

Verantwortlichkeiten und Budget klären

Nach der Identifikation der betroffenene Produkte wurde gemeinsam eine klare Zuweisung von Verantwortlichkeiten erarbeitet. Dabei wurden Rollen für die Umsetzung des CRA innerhalb des Unternehmens definiert und auf der Managementebene Sichtbarkeit für das Thema erzielt. Gleichzeitig wurde das benötigte Budget für die Umsetzung der Anforderungen des CRA abgeschätzt und so berechnet, dass genug Ressourcen und Kompetenzen für die Umsetzung zur Verfügung stehen. Bei der Budgetplanung wurden sowohl die einmaligen als auch die laufenden Kosten berücksichtigt. Ein klar definiertes Budget ermöglichte eine realistische und effiziente Umsetzung der Sicherheitsmaßnahmen.

Zum Abschluss der Planung wurde der weitere zeitliche Ablauf definiert, um die wichtigen Fristen der EU einzuhalten und Verzögerungen bei den Releases neuer Produkte zu vermeiden. Da sich das Unternehmen rechtzeitig mit dem CRA auseinandersetzte, entstanden keine größeren Verzögerungen.

Soll/Ist Analyse der Anforderungen des CRA

Nun wurden bei einer Soll-Ist-Analyse die bestehenden Sicherheitsmaßnahmen des Unternehmens und der Produkte mit den Anforderungen des CRA verglichen und Lücken identifiziert. Durch eine Dokumentenprüfung, fachliche Interviews mit Ansprechpartnern sowie Sichtung von Auditberichten kamen wir zu folgenden Ergebnissen:

Die Produkte des Unternehmens verfügten schon über die grundlegenden Sicherheitsmechanismen, jedoch waren die Strukturen und Prozesse im Unternehmen nicht auf die neuen Anforderungen des CRA ausgerichtet. Es existierten zwar Maßnahmen wie Software-Updates und Zugriffskontrollen, doch dem Produktlebenszyklus fehlte ein systematisches Sicherheitskonzept nach dem Prinzip Security by Design. Die Sicherheitsaspekte wurden nicht bereits in der Entwurfsphase beachtet, sondern erst kurz vor oder sogar erst nach dem Release der Produkte. Außerdem fehlte manchen Produkten das Prinzip Security by Default, da sie mit einem Standardpasswort ausgeliefert wurden. Die Software-Updates wurden aufgrund von mangelnden technischen Möglichkeiten nicht über den kompletten Lebenszyklus der Geräte verfügbar gemacht, sondern wurden oft bereits nach 3 Jahren eingestellt. Zudem wurde festgestellt, dass dem Unternehmen die Prozesse und die Infrastruktur für das geforderte Incident Response Management und Security Monitoring fehlten. Die Mitarbeitenden waren nur teilweise im Bereich Cybersicherheit geschult. Die Dokumentationen (allgemeine Produktbeschreibung, Risikobewertungen und angewandte Normen) des Unternehmens waren teilweise vorhanden, es fehlte jedoch die geforderte SBOM (Software Bill of Materials).

Diese Ergebnisse wurden dann in einem Bericht zusammengefasst, um dem Kunden einen transparenten Überblick über seinen aktuellen Stand zu geben. Das Ergebnis zeigte auf, welche Maßnahmen bereits konform waren und welche Maßnahmen im weiteren Verlauf noch eingeführt werden müssten. Auf der Basis des Berichts wurden konkrete Handlungsempfehlungen formuliert.

Risiken innerhalb der betroffenen Produkte analysieren

Nach der Soll-Ist-Analyse wurde eine detaillierte Risikoanalyse durchgeführt. Es wurden potenzielle Sicherheitsrisiken für die Produkte evaluiert. Dabei wurden klassische Schwachstellenanalysen mit Threat-Informed Defense (TID) kombiniert, um eine fundierte Priorisierung der erforderlichen Sicherheitsmaßnahmen vorzunehmen.

Außerdem wurden bei einigen Produkten Penetrationstests durchgeführt mit dem Ziel, die kritischen Schwachstellen der Produkte zu identifizieren. Wir vervollständigten auf diese Weise unser Bild vom Unternehmen. Auf Grundlage der gewonnenen Erkenntnissen nahmen wir eine Priorisierung der erforderlichen Sicherheitsmaßnahmen vor und sie flossen in unsere Handlungsempfehlungen ein.

Umsetzung identifizierter Maßnahmen (prozessual & technisch)

Die erste durchgeführte Maßnahme war die Schulung des relevanten Personals. Neben dem vermittelten Wissen hatte dies den Nebeneffekt, dass wir die Mitarbeitenden besser in die Umsetzung der Maßnahmen einbeziehen konnten.

Eine besondere Herausforderung stellten die historisch gewachsenen Produkt- und Softwareentwicklungsprozesse dar, die über Jahre hinweg ohne einheitliche Sicherheitsstrategie entstanden waren. Diese haben wir angepasst, indem wir strukturierte Security by Design Prinzipien eingeführt und somit einen sicheren Produktentwicklungsprozess und Lebenszyklus eingeführt haben. Die Produktsicherheit wird im Unternehmen nun schon ab der Designphase in allen Phasen des Produktslebenszyklus berücksichtigt. Dabei wurde auch miteinbezogen, dass die Sicherheitsupdates für Produkte nun der Lebensdauer der Produkte entsprechen müssen. Die Technik wird so gewählt, dass sie auch nach 5 Jahren noch Sicherheitsupdates erhalten kann.

Darüber hinaus führte das Unternehmen mit unserer Unterstützung eine neue Continuous Integration und Continuous Delivery (CI/CD) Pipeline mit automatisierten Sicherheitsprüfungen ein. Dazu wurde eine Application Security Platform eingeführt, die den Code der Entwickler automatisch überprüft und schon während der Programmierung Schwachstellen im Code und in Bibliotheken meldet. Außerdem kann dieses Programm die vom CRA geforderte SBOM für die gesamte entwickelte Software des Unternehmens erstellen.

Zeitgleich wurde ein Incident Response Team im Unternehmen eingerichtet und die Infrastruktur für Incident Response Management und Security Monitoring geschaffen. Das Unternehmen ist jetzt in der Lage, innerhalb von maximal 24 Stunden Schwachstellen und Sicherheitsvorfälle zu melden. Es kann schnell auf interne, sowie externe Meldungen reagiert werden und den Nutzern Sicherheitsupdates für ihre Produkte zur Verfügung gestellt werden.

Aufgrund der neuen Prozesse und des neuen Sicherheitsdenkens erfüllen die Produkte jetzt die Prinzipien Security by Design & Default.

Durchführung der Konformitätsbewertung

Das Unternehmen hatte keine kritischen Produkte, somit konnte die Konformitätsbewertung vom Unternehmen selbst durchgeführt werden, es brauchte keine Evaluation durch einen Dritten. Bei der Selbstevaluation unterstützten wir das Unternehmen und konnten die CE Kennzeichnung für die neuen Produkte erlangen, sodass diese ohne Verzögerung nach Dezember 2027 auf den EU-Markt kommen können.

Mehrwert

Dank des tiefgehenden Fachwissens unseres CRA Cybersecurity Expertenteams sowie unserer langjährigen Erfahrung im Bereich der Product Security und der sicheren Softwareentwicklung waren wir in der Lage, die spezifischen Herausforderungen unseres Kunden sowie der einzelnen Organisationseinheiten genau zu erfassen und passgenaue Lösungen zu erarbeiten.

Neben unserer transparenten und ganzheitlichen Herangehensweise trugen auch eine enge kundenorientierte Kommunikation und Flexibilität maßgeblich zum Erfolg bei. Durch eine gründliche Bewertung des bestehenden Reifegrads in den Abteilungen sowie eine umfassende Aufklärung über gesetzliche Vorgaben verschafften wir dem Kunden einen klaren Überblick und förderten sein Sicherheitsbewusstsein.

Bei carmasec legen wir großen Wert auf eine enge Zusammenarbeit mit unseren Kunden. Durch ausführliche zielgerichtete Interviews und die Einbindung aller relevanten Stakeholder konnten wir in diesem Projekt ein tiefgehendes Verständnis für die spezifischen Herausforderungen erzeugen. So war es uns möglich, maßgeschneiderte Empfehlungen zu erarbeiten, um die Erfüllung des CRA und weiterer kundenspezifischen Anforderungen sicherzustellen. Dabei setzten wir auf einen integrativen Ansatz mit unseren Open Source Security Experten, der sowohl in der Strategieentwicklung als auch bei der Definition konkreter Maßnahmen berücksichtigt wurde. Neben der Analyse und Bewertung unterstützten wir auch die praktische Umsetzung, indem wir den Kunden befähigten, nachhaltige und praxisnahe Product Security-Strukturen aufzubauen. Gemeinsam definierten wir Rollen und Verantwortlichkeiten und entwickelten eine Roadmap für die Implementierung von Sicherheitsmaßnahmen, wie die Integration von Security-Schritten in den Entwicklungsprozess, die Definition von Secure Coding Standards und die Einführung eines Prozesses für Vulnerability- und Incident-Management. Zusätzlich standen wir als Experten bei der Erstellung erforderlicher Dokumentationen und Prozesse beratend zur Seite.

Binnen eines Jahres haben wir die Rahmenbedingungen für CRA festgelegt und sowohl einen sicheren Entwicklungsprozess als auch ein umfassendes Vulnerability Management mitsamt der CRA-Meldepflichten implementiert.

Dies ersparte dem Kunden die Herausforderung, schwer verfügbare Expert:innen zu rekrutieren, und ermöglichte ihm stattdessen, internes Wissen gezielt aufzubauen. Dadurch konnte er Product Security effektiv implementieren und die Weichen für sichere Produkte von morgen stellen.

Fazit

Compliance mit dem Cyber Resilience Act ist kein einmaliges Projekt. Sie ist eine Strukturfrage. Unternehmen, die Sicherheit spät im Entwicklungsprozess einbauen, zahlen zweimal: einmal für die Nachrüstung, einmal für den Zeitverlust.

Dieses Projekt zeigt, was möglich ist, wenn früh angefangen wird. Security by Design als Prinzip. Eine SBOM als Grundlage. Incident Response als Infrastruktur. Und ein Team, das die Anforderungen nicht von außen aufgedrückt bekommt, sondern versteht, warum sie sinnvoll sind.

Das Ergebnis ist kein abgehaktes Compliance-Dokument. Es ist ein Produktentwicklungsprozess, der ab sofort sicher startet.

FAQ zur CRA-Umsetzung in der Praxis

Dein Team steht vor ähnlichen Fragen?

Unser Team unterstützt dich von der ersten Bestandsaufnahme bis zur CE-Kennzeichnung. Kompetent, direkt und ohne Umwege.

Erstgespräch vereinbaren

Red Teaming Assessments werden eingesetzt, um die Abwehrmechanismen eines Unternehmens gegen gezielte Angriffe zu überprüfen und zu verbessern. Sie simulieren reale Bedrohungsszenarien, um Schwachstellen zu identifizieren und die tatsächliche Effektivität von Sicherheitsmaßnahmen sowie Reaktionsprozessen zu bewerten.
In dieser Case Study stellen wir die Ergebnisse eines Red Teaming Assessments bei einem unserer Kunden vor. Dieses wurde von unseren Kollegen Timo Sablowski, Senior Security Consultant und Pascal Waffenschmidt, Security Consultant, durchgeführt.

Zusätzlich sollten die Incident Response Prozesse des Kunden getestet werden, sobald unser Angriff entdeckt würde. Die Mitarbeitenden der Security-Abteilung wurden deshalb nicht eingeweiht, um ein realistisches Szenario zu simulieren. Als Testobjekt diente ein regulär konfigurierter Arbeitslaptop mit einem normal eingerichteten E-Mail-Konto. Für unser Assessment wählten wir zusammen mit dem Kunden einen „assumed breach“-Ansatz. Hierbei wird davon ausgegangen, dass Social Engineering-Angriffe zu einem bestimmten Zeitpunkt immer erfolgreich sind und Angreifer mit ausreichendem Aufwand immer ein System infiltrieren können.

Vorbereitung der Angriffssimulation

Die Vorbereitung der Angriffssimulation erfolgte in drei sorgfältig geplanten Schritten.

1. Abstimmung der TTPs gemäß dem Mitre ATT@CK Framework

Zu Beginn stimmten wir gemeinsam mit unserem Kunden die zu testenden Taktiken, Techniken und Prozeduren (TTPs) des Mitre ATT@CK Frameworks ab. Der Fokus unserer Tests lag explizit auf dem Bereich Command & Control. Die zu testenden TTPs waren konkret:

• Initial Access über Phishing-Attacken wie Spearphishing-Attachments (T1556.001) und -Links (T1556.002) sowie die Verbreitung über Wechseldatenträger wie USB-Sticks (T1091).
• User Execution über eine schädliche Datei (T1204.002).
• Im Bereich Command & Control konzentrierten wir uns auf verschlüsselte Kommunikationskanäle (T1573.001) und die Nutzung von Non-Standard Ports (T1571).

Über das Mitre ATT@CK Framework
Die umfangreiche Wissensdatenbank enthält gegnerische Taktiken und Techniken, die auf realen Beobachtungen von Cyberangriffen basieren. Das Mitre ATT&CK Framework wird weltweit von Sicherheitsexperten eingesetzt, um Bedrohungen zu identifizieren, abzuwehren und zu analysieren.

2. Entwicklung eines maßgeschneiderten C2-Kanals

Im zweiten Schritt programmierten wir eine speziell auf dieses Assessment zugeschnittene Serversoftware und einen Agenten, der auf dem Arbeitslaptop des Kunden eingeschleust werden sollte.
Damit unser C2-Kanal nicht direkt entdeckt werden konnte, bauten wir einige Features ein:

• Unser Agent meldete sich in unregelmäßigen Abständen beim Server (Beaconing & Jitter), um die Regelmäßigkeit der Kommunikation zu verschleiern.
• Wir haben die Kommunikation mit AES (Advanced Encryption Standard) verschlüsselt, damit sie trotz SSL-Inspektion durch die Firewall nicht als verdächtig erkannt wird.
• Wir hatten vorab für den Server eine unauffällige Domain registriert. So fällt der Server in der Kommunikation kaum auf.

3. Erstellung eines ausführlichen Testplans

Schließlich erstellten wir einen umfassenden Testplan, der verschiedene Szenarien abdeckte. Zentrale Fragestellungen waren:

• Über welche Wege kann der Agent in das Zielsystem eingeschleust werden?
• Welcher Kommunikationskanal wird für die Verbindung zwischen Agent und Server verwendet (z.B. HTTPS,
• Kommunikation über Non-Standard Ports)?
• Können Kommandos über den C2-Kanal auf dem Zielsystem ausgeführt werden?
• Ist eine Local Privilege Escalation möglich, um Administrationsrechte auf dem Gerät zu erlangen?

Durchführung des Assessments

Um die Sicherheitsmaßnahmen des Kunden umfassend zu prüfen, gliederten wir das Assessment in mehrere wesentliche Schritte.

1. Infiltration des Zielsystems

Im ersten Schritt testeten wir verschiedene Methoden, um den Agenten auf das Zielsystem zu bringen.
Per USB-Stick:
Diese häufig übersehene, aber sehr effektive Methode nutzt physische Zugangsmöglichkeiten aus. Wir hatten Erfolg und konnten unseren Agenten mit Hilfe eines USBs-Sticks schlussendlich auf den Testrechner laden.
Phishing:
Auch per E-Mail verschickte Links und Anhänge konnten auf dem Testrechner geöffnet und so unser Agent eingeschleust werden.

2. Ausführung der Schadsoftware

Als nächstes prüften wir, ob wir den C2-Kanal aufbauen und darüber Kommandos auf dem Testrechner ausführen konnten.
C2-Kommunikation über HTTPS:
Diese Methode erwies sich als effektiv. Der C2-Kanal konnte aufgebaut und Kommandos erfolgreich ausgeführt werden.
Weitere getestete Methoden:
Wir haben zudem verschiedene andere Kommunikationsmethoden getestet:

Bad USB (Flipper Zero): Der Flipper Zero ist ein tragbares Gerät, das verschiedene drahtlose Protokolle und physische Zugangstechniken testen und analysieren kann, einschließlich RFID, NFC, Bluetooth, Infrarot und GPIO-Interaktionen. Mit Hilfe dieses kleinen Multitools konnten wir Tatstaureingaben simulieren und so erfolgreich Schadcode auf dem Testrechner ausführen.

• Word-Makro als E-Mail-Anhang: Der Empfang von E-Mails, die Word-Dokumente mit Makros im Anhang enthielten, wurde durch die Sicherheitslösung zumindest teilweise blockiert. Diese Sicherheitsmaßnahme konnte jedoch mit einfachen Techniken umgangen und die Word-Dokumente schließlich per E-Mail auf das Testsystem gebracht werden. Die Ausführung der Word-Makros auf dem Testrechner war jedoch ohne weiteres möglich, so dass auf diesem Weg Schadcode ausgeführt werden konnte.
• Zip-Dateien als Download: Mit Hilfe einer Zip-Datei konnten wir die Security-Lösung umgehen und die Schadsoftware auf dem Testrechner ausführen.
• Virtuelles Laufwerk mit Schadsoftware in PDF: Wir prüften auch, ob wir Schadsoftware über ein PDF einschleusen und mit Hilfe eines virtuellen Laufwerks ausführen konnten. Dieser Ansatz scheiterte allerdings an fehlenden Administrationsrechten zum Einbinden des Laufwerks.

Insgesamt ist es uns gelungen, über mehrere Wege unseren Agenten auszuführen, den C2-Kanal aufzubauen und auf dem Testsystem Kommandos auszuführen. Diese wurden von der Sicherheitslösung zumindest eine Zeit lang nicht erkannt.

3. Testen weiterer C2-Kommunikationsmöglichkeiten

Nachdem wir das Hauptziel, unentdeckt einen C2-Kanal aufzubauen und Kommandos auszuführen, erreicht hatten, konzentrierten wir uns im weiteren Assessment darauf, die Flexibilität und Robustheit des C2-Kanals zu testen. Dazu überprüften wir verschiedene Protokolle und Ports. Allerdings mussten wir schnell feststellen, dass lediglich HTTPS zuverlässig funktionierte. Andere Ports konnten aus dem internen Netzwerk heraus nicht erreicht werden.

4. Versuch einer Local Privilege Escalation

Zusätzlich führten wir eine grundlegende Überprüfung des Rechtemanagements auf dem Testrechner durch. Dazu verwendeten wir gängige Methoden zur Erlangung von Administratorrechten, einschließlich der Nutzung von Exploits für bekannte Schwachstellen oder der Ausnutzung von Schwächen in der Benutzerkontensteuerung (User Account Control, UAC). Diese Versuche blieben jedoch erfolglos, das System war angemessen gehärtet.

5. Entdeckung und Incident Response

Wir blieben lange Zeit unentdeckt und konnten den C2-Kanal für einige Kommandos nutzen. Erst als wir dem Testplan weiter folgten und weitere Wege zur Ausführung von Schadsoftware prüften, reagierte die EDR-Lösung aufgrund der abnehmenden Verschleierung unserer Aktionen, blockierte schlussendlich einen unserer Versuche und alarmierte den Kunden.
Nach der Entdeckung des Angriffs durch das Security Operations Center (SOC) griffen effiziente Incident Response Prozesse. Unsere vorherige Angriffe konnten im SIEM nachvollzogen werden und die Meldewege wurden eingehalten.

6. Erstellung des Testprotokolls und Reports

Abschließend haben wir alle Ergebnisse ausführlich dokumentiert und einen detaillierten Report erstellt. Dieser zeigt alle gefundenen Schwachstellen auf und bietet unserem Kunden eine fundierte Grundlage für weitere Sicherheitsmaßnahmen.

Empfehlungen für unseren Kunden

• Optimierung der Endpoint Detection & Response (EDR)-Lösung notwendig
  Unsere Analyse zeigte, dass die Endpoint Detection & Response (EDR)-Lösung des Kunden nicht ausreichend alarmiert. Gründe dafür können Konfigurationsprobleme oder mangelndes Fachwissen sein. Unser Kunde sollte daher die Konfiguration der Endpoint Protection überprüfen und anpassen, um Angriffe wie in unserem Test zukünftig früher zu erkennen.
• Einführung eines Application Allow Listings
  Um die Sicherheitsmaßnahmen zu verbessern, empfehlen wir die Einführung eines Application Allow Listing. Dieses blockiert alle unbekannten Anwendungen und verhindert somit auch die Ausführung von Schadsoftware.
• Office-Makros standardmäßig blockieren
  Die Ausführung von Office-Makros sollte jederzeit blockiert werden, um das Risiko durch Makro-basierte Malware zu minimieren.
• Unbekannte USB-Geräte blockieren
  Unbekannte USB-Geräte sollten immer blockiert werden, um das Risiko von Bad USB-Angriffen zu minimieren. In unseren Tests war das nicht der Fall und wir konnten über eine USB-Schnittstelle Schadcode auf den Testrechner spielen.
• Regelmäßige Sensibilisierung der Benutzer
  Regelmäßige Schulungen und Sensibilisierungsmaßnahmen sind unerlässlich, um das Bewusstsein der Mitarbeitenden für mögliche Bedrohungen zu schärfen und die Sicherheitskultur im Unternehmen zu stärken.

Fazit

Im Rahmen des Assessments konnten wir ungehindert Schadsoftware auf das Testsystem spielen, diese ausführen und Command-and-Control-Kanäle aufbauen, ohne dass die Endpoint Protection wirksam eingreifen konnte.
Dies bedeutet, dass unser Kunde nicht ausreichend gegen die im Scope definierten Szenarien geschützt ist. Die Eintrittswahrscheinlichkeit einer erfolgreichen gezielten Kompromittierung von Benutzern und deren Endgeräten stufen wir aufgrund der Größe des Kundens und seines Geschäftsmodells als sehr hoch ein, wenn die anvisierten Benutzer unaufmerksam sind.

Regelmäßige Assessments durchführen!
Regelmäßige Tests wie das von uns durchgeführte Red Teaming-Assement sind für Unternehmen unerlässlich. Solchen Tests zeigen nicht nur technische Schwachstellen, sondern auch Lücken in den Sicherheitsprozessen und Verantwortlichkeiten auf. So haben Unternehmen die Chance zu reagieren und ihre Sicherheit zu verbessern, bevor Schwachstellen von Cyberkriminellen ausgenutzt werden können.
Wir empfehlen daher, regelmäßige Assessments durchzuführen und auch neue Systeme direkt mit der Einführung testen zu lassen, um die Effektivität der Incident Response und Prozesse sicherzustellen.

Suchst du Informationen über Angriffssimulationen zur Erkennung von Schwachstellen in deinem Unternehmen?

Hier findest du eine Übersicht über unsere Leistungen im Bereich Offensive Security

Betreiber kritischer Infrastrukturen (KRITIS) müssen Informationssicherheit strukturiert umsetzen. Wir wurden von einem führenden Lebensmittelversorger, der als kritische Infrastruktur gilt, beauftragt, die Implementierung der KRITIS-Anforderungen zu begleiten.
Diese Case Study beleuchtet den Weg des Unternehmens von den ersten Schritten bis zur finalen Umsetzung der KRITIS-Anforderungen.

Deshalb legten sie den Fokus zunächst auf die Erfüllung des KRITIS-Anforderungskatalogs und dem Nachweis der KRITIS-Fähigkeit. Eine mögliche Zertifizierung nach ISO 27001 wurde für die Zukunft aber nicht ausgeschlossen. Ein Vorteil von KRITIS: Die Anforderungen sind im Vergleich zu anderen IT Security Frameworks wie die ISO 27001 oder der BSI IT-Grundschutz weniger umfangreich und können daher schneller umgesetzt werden. Gleichzeitig stellt die KRITIS-Fähigkeit einen wesentlichen Schritt in Richtung einer ISO 27001-Zertifizierung dar.

Die Herausforderung

Unsere Kollegen stellten sich dabei zwei großen Herausforderungen:

• Die Erstellung und Dokumentation der für das ISMS notwendigen Unterlagen
• Die Definition und Umsetzung von notwendigen Prozessen

Die Mitarbeitenden unseres Kunden hatten häufig wenig Zeit und kein ausreichendes Gesamtverständnis für die Beschreibung und Umsetzung der Prozesse. Dies betraf neben der im Fokus stehenden IT-Abteilung auch verschiedene andere Organisationsbereiche wie z.B. das Facility Management, Personal und den Einkauf.

Zudem gibt es im Unternehmen einen kritischen Fachkräftemangel, der den Projektfortschritt beeinträchtigen konnte. Unsere Kollegen, die zunächst nur beratend tätig sein sollten, wurden daher mit konkreten Aufgaben in das Projekt eingebunden, um das Unternehmen auch operativ zu unterstützen.

So haben wir die KRITIS-Anforderungen umgesetzt

Aufbau des ISMS und Dokumentation:

Unsere Berater haben gemeinsam mit dem Unternehmen ein ISMS aufgebaut und alle notwendigen Dokumentationen erstellt, abgestimmt und nach Freigabe für die Kommunikation im Unternehmen gesorgt. Dabei definierten wir die notwendigen Leitlinien und Richtlinien, um die Anforderungen des KRITIS-Katalogs zu erfüllen.

Beratung und Prozessimplementierung:

Till Bormann übernahm als kommissarischer Informationssicherheitsbeauftragter (ISB) und Projektleiter für die KRITIS-Nachweisführung die Verantwortung für die Umsetzung des ISMS. Er bereitete das Unternehmen auf das anstehende Assessment vor und führte simulierte Prüfungen durch, um die Mitarbeitenden zu schulen und Unsicherheiten auszuräumen.

Dokumentation und Unterstützung der IT-Mitarbeitenden:

Dennis Miara verantwortete die Dokumentation der Prozesse. Er half den IT-Mitarbeitenden, den Kontext der Anforderungen besser zu verstehen, Pain Points zu identifizieren und die notwendigen Anpassungen vorzunehmen. Zudem haben unsere Kollegen das IT-Betriebshandbuch (BHB) von Grund auf neu gestaltet und umfassend ergänzt. Insbesondere wurden wesentliche Verbesserungspotenziale der Informationstechnik identifiziert und für die anstehende Prüfung vorbereitet.

Aktive Einbindung und Wissenstransfer:

Ein wesentlicher Bestandteil unserer Arbeit war die aktive Einbindung der Mitarbeitenden in den Umsetzungsprozess. Durch kontinuierliche Beratung und Schulung konnten wir das Verständnis für die Relevanz der einzelnen Aktivitäten und Anforderungen verbessern. Zudem führten unsere Kollegen Workshops zu übergreifenden Themen wie beispielsweise Risikomanagement oder Incident Management durch.

Erfolge und Ausblick

Durch die enge Zusammenarbeit und unsere operative Unterstützung konnten wir unseren Kunden erfolgreich zur KRITIS-Fähigkeit führen. Die Einführung des ISMS und die Erfüllung des KRITIS-Anforderungskatalogs bilden nun eine solide Grundlage für die spätere ISO 27001-Zertifizierung oder die Umsetzung weiterer regulatorische Vorgaben wie NIS-2, das KRITIS-Dachgesetz oder andere Resilienz-Anforderungen.

Lessons Learned

Zeitmanagement:

Die Einführung eines ISMS benötigt Zeit und Ressourcen. Die frühzeitige Einbindung, das Coaching sowie die konsequente Zielausrichtung mit der notwendigen Priorisierung der Mitarbeitenden sind entscheidend für den Erfolg.

Fachkräftemangel:

Der Einsatz von externen Expert:innen kann kritische Engpässe überbrücken und den Wissenstransfer sicherstellen. Mittelfristig ist es für Unternehmen sinnvoll, mit Hilfe unserer Consultants interne Ansprechpartner:innen zu schulen und aufzubauen.

Prozesse und Dokumentation:

Zur Erfüllung der KRITIS-Anforderungen sind klar definierte Prozesse und eine umfassende Dokumentation unerlässlich. Dieser Punkt stellt häufig eine besondere Herausforderung dar, da im Unternehmen neben der Zeit auch nicht selten auch das Verständnis für die Prozessbeschreibung fehlt.

Fazit

Der Weg von „Zero to Hero“ in der IT-Sicherheit erfordert von Unternehmen eine sorgfältige Planung, umfassende Dokumentation, kontinuierliche Projektunterstützung und konsequente Arbeit an der Umsetzung sowie die aktive Einbindung der Mitarbeiter. Unser Ansatz, die KRITIS-Anforderungen als Vorstufe zur ISO 27001-Zertifizierung zu nutzen, hat sich bewährt und bietet eine praktikable Lösung für Unternehmen, die ihre IT-Sicherheitsmaßnahmen effizient und zielgerichtet umsetzen wollen.

Suchst du Informationen zur Umsetzung von KRITIS oder dem Aufbau eines ISMS in deinem Unternehmen?

Hier findest du eine Übersicht über unsere Leistungen im Bereich IT-GRC