Wie ITSM die NIS2 Compliance unterstützt 

Mit der Einführung der NIS2-Richtlinie, die eine Umsetzung in nationales Recht bis zum 18.10.2024 vorsieht, werden Unternehmen dazu verpflichtet, angemessene Maßnahmen zur Gewährleistung der Cybersicherheit zu ergreifen. Im Rahmen des IT Service Managements (ITSM) sind verschiedene Aspekte von NIS2 von Bedeutung, um die Compliance sicherzustellen und die Cybersicherheit zu stärken. 

Die Umsetzung der EU-Richtlinie in deutsches Recht wird aktuell immer weiter verschoben. Im aktuell öffentlichen Entwurf des deutschen NIS2-Umsetzungsgesetzes steht zwar weiterhin der 01.10.2024 als Beginn der Umsetzungspflicht, aber aktuelle Gerüchte weisen darauf hin, dass die Verabschiedung des Gesetzes sich auch über dieses Datum hinaus verzögern könnte.  

Über drei Jahrzehnte Erfahrung von HiSolutions in der IT-Management- und Informationssicherheitsberatung zeigen, dass die in NIS2 geforderten Maßnahmen und deren wirksame Umsetzung sehr zeitaufwändig sein können. Unsere Empfehlung bleibt deshalb, sofort auf Basis der bereits jetzt verfügbaren Informationen wie den jetzigen EU-Vorgaben, dem aktuellen Entwurf des deutschen Umsetzungsgesetzes sowie gängigen Standards und BSI-Vorgaben zu handeln. 


Mit diesem Übersichtsartikel bauen wir einen Leitfaden auf. Dieser soll auch Unternehmen, die zum ersten Mal regulatorisch erfasst werden, eine Einführung in die Best Practices im IT Service Management bieten. Zukünftige Artikel zur Vertiefung behandeln folgende NIS2-relevante Handlungsfelder: 

  1. Behandlung von Sicherheitsvorfällen 

Unternehmen müssen Prozesse zur Erkennung, Meldung und Behandlung von Sicherheitsvorfällen implementieren. NIS2 legt fest, dass Organisationen Sicherheitsvorfälle innerhalb bestimmter Fristen melden und angemessene Maßnahmen zur Eindämmung und Behebung ergreifen müssen. Daher müssen Unternehmen entsprechende Incident Management Prozesse etablieren, um Sicherheitsvorfälle effektiv zu bearbeiten und die Auswirkungen auf ihre IT-Dienste zu minimieren.  

Aus Sicht des IT-Service Managements sind hier der Service Desk, bei dem Endanwender mit Meldungen zu Sicherheitsvorfällen ankommen, der Incident Management Prozess, der eng mit dem Security Incident Prozess verzahnt sein sollte sowie die Maßnahmen rund um das Logging und Monitoring von Systemen involviert. 

  1. Business Continuity 

NIS2 fordert von Unternehmen die Entwicklung von Business-Continuity-Plänen, um die Verfügbarkeit kritischer Dienste auch während und nach Sicherheitsvorfällen sicherzustellen. Im IT Service Management werden aus dem Business Continuity Management (BCM) die entsprechenden IT Service Continuity Management (ITSCM) Maßnahmen abgeleitet. Das ITSCM ist wiederum eng mit dem Availability und dem Capacity Management verbunden. Um ein ITSCM effektiv zu gestalten, sind Grundlagen aus dem Service Configuration Management notwendig. 

  1. Auslagerungsmanagement 

Unternehmen, die kritische Dienste an externe Dienstleister auslagern, müssen sicherstellen, dass diese Dienstleister angemessene Sicherheitsmaßnahmen implementieren. NIS2 legt fest, dass Unternehmen die Verantwortung für die Sicherheit ihrer ausgelagerten Dienste nicht delegieren können. Im ITSM bedeutet dies, dass Unternehmen geeignete Mechanismen für das Auslagerungsmanagement etablieren müssen, um sicherzustellen, dass externe Dienstleister die Anforderungen an die Cybersicherheit erfüllen. Die entsprechenden Maßnahmen werden im Supplier sowie im Service Level Management definiert. 

  1. Security Awareness 

Die Sensibilisierung der Mitarbeiter für Cybersicherheit ist ein zentraler Bestandteil der NIS2-Compliance. Unternehmen müssen Schulungsprogramme zur Sicherheitsaufklärung durchführen, um das Bewusstsein und Verständnis für Sicherheitsrisiken zu fördern. Im ITSM ist es wichtig, Security Awareness Trainings in die laufenden Schulungsaktivitäten zu integrieren, um sicherzustellen, dass Mitarbeiter die Bedeutung von Cybersicherheit verstehen und entsprechend handeln. Dabei hat der Service Desk eine Nähe zu den Anwendern und das Relationship Management zu den Kunden, was für die Etablierung und Durchführung von Security Awareness Maßnahmen genutzt werden kann. 

  1. Risikoanalyse 

Eine kontinuierliche Risikoanalyse ist entscheidend für die Identifizierung und Bewertung von Sicherheitsrisiken gemäß den NIS2-Anforderungen. Unternehmen müssen Risikomanagementprozesse implementieren, um potenzielle Bedrohungen zu erkennen und geeignete Gegenmaßnahmen zu ergreifen. Im ITSM sollten Unternehmen regelmäßige Risikobewertungen durchführen und angemessene Sicherheitskontrollen implementieren, um Risiken zu minimieren und die Compliance sicherzustellen. Dies geschieht im Bereich Risk Management

  1. Übergreifende Practices 

NIS2 hat weitreichende Auswirkungen auf verschiedene Aspekte des ITSM und erfordert eine integrierte Herangehensweise an die Cybersicherheit. Dies geschieht durch die Best Practices im Information Security Management und wird durch das Infrastructure and Plattform Management gestützt. Unternehmen müssen sicherstellen, dass ihre ITSM-Prozesse und -Praktiken die Anforderungen von NIS2 erfüllen und eng mit anderen Compliance-Richtlinien und -Standards wie z. B. ISO 27001 abgestimmt sind. Durch eine ganzheitliche Herangehensweise können Unternehmen die Cybersicherheit stärken und die Einhaltung der Vorschriften im IT Asset/Deployment Management sicherstellen. Das dafür notwendige Change Management wiederum bezieht sich auf bewährte Prozesse und Methoden zur systematischen Planung, Steuerung und Umsetzung von Veränderungen in IT Systemen und Services. Ziel ist es, Änderungen kontrolliert und effektiv zu verwalten, um Risiken zu reduzieren und die Zuverlässigkeit der IT Services zu erhöhen. 

NIS kommt: Wir unterstützen Sie bei der Umsetzung. 
Der neue NIS2-Kompass von HiSolutions zeigt Ihnen in einer schnellen Selbstauskunft, ob Ihre Organisation von NIS2 betroffen ist und was Sie tun müssen.

Die Backdoor, die das Internet bedrohte

Am 28. März 2024 konnte ein Kollaps in der Open Source-Infrastruktur, verursacht durch eine Backdoor in der weitverbreiteten Kompressionssoftware xz, verhindert werden. Zu danken ist dies der Aufmerksamkeit von Andres Freund, einem Entwickler von PostgreSQL und Principal Software Engineer bei Microsoft.

Freund bemerkte ungewöhnliche Verzögerungen bei der SSH-Anmeldung, die ihn schließlich zu einer intensiven Fehlersuche und Analyse der Software-Abhängigkeiten seines Systems führten. Seine Untersuchungen deckten eine Backdoor in der Bibliothek liblzma auf, einem Bestandteil des Kompressionstools xz, die auf Änderungen im Build-Prozess durch den GitHub-Account „Jia Tan“ zurückzuführen war.

„Jia Tan“, der seit Anfang 2021 etwa 700 Änderungen am xz-Quellcode vorgenommen hatte, war ebenfalls in die Entwicklung anderer kritischer Open-Source-Projekte involviert. Diese Entdeckung veranschaulicht nicht nur die Bedeutung von gründlichen Überprüfungen in der Open-Source-Softwareentwicklung, um die Sicherheit und Integrität zu gewährleisten, sondern auch die Rolle, die erfolgreiches Social-Engineering in Angriffen spielen kann.

In unserem Research-Blog ist ein detaillierter Deep Dive zu den Hintergründen des Angriffs und der Funktionsweise der Backdoor durch unsere Kollegen Folker Schmidt und Justus Tartz erschienen. https://research.hisolutions.com/2024/04/xz-backdoor-eine-aufarbeitung/

Aktuelle Version der Cyber-Sicherheitswarnung des BSI: https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2024/2024-223608-1032.pdf?__blob=publicationFile

HiSolutions Research

Vom Berater bis zum Angreifer: Computer übernehmen die Jobs

Ende November gab die Firma OpenAI den Prototypen ihres Chatbots ChatGPT zum Ausprobieren durch die Community frei und die nutzte die Adventszeit für viele spannende und teils erschreckende Experimente. Was ist ChatGPT eigentlich? Tatsächlich, wie der Name sagt, ein Chatbot, den man mit Fragen zu recht komplexen Antworten bringen kann. Wie in einem Fachgespräch üblich, kann man ihn durch weitere Fragen oder Änderungswünsche die Antworten ergänzen und verbessern lassen. Der Chatbot kann nicht nur Texte schreiben, sondern auch einfache Programme entwickeln.

Vorsicht ist jedoch angesagt, damit der Bot seine Ergebnisse nicht zu sehr nach den vermeintlichen Wünschen des Fragestellers ausrichtet. Bei Tests mit typischen Beratungsfragen, also den Fragen, die ohne Kontext immer mit „Es kommt darauf an“ beantwortet werden, konnte ChatPGT sehr überzeugend beide Sichten begründen – allerdings ohne auf die jeweils andere Option einzugehen. Fragt man beispielsweise, wie mit schwachen SSL-Cipher-Einstellungen umgegangen werden soll, bekommt man je nach Fragestellung diese Antworten:

Für die Einordnung der Ergebnisse der künstlichen Intelligenz ist dann doch wieder Fachwissen nötig.

ChatGPT kann aus einer kurzen Beschreibung heraus auch ein passendes Programm entwickeln. Das interessiert natürlich auch potenzielle Malware-Autoren. Die Kollegen von Check-Point haben in Foren erste Hinweise in Foren gefunden, dass mit Malware aus ChatGPT-generiertem Code experimentiert wurde. Ob sich das Entwicklungsmodell bei den Malware-Autoren durchsetzt oder diese Malware am Ende sogar leichter erkennbar sind, wird die Zukunft zeigen.

https://www.heise.de/news/ChatGPT-Maechtige-Waffe-in-Haenden-von-Skriptkiddies-7452741.html

OWASP – Mehr als die Top 10 Sicherheitsrisiken für Webanwendungen

Vielen werden die “OWASP Top 10” der Inbegriff der kritischsten Bedrohungen für Webanwendungen sein.

Dabei hat das Open Web Application Security Project mit einer ganzen Reihe verschiedener Open-Source-Projekte im Bereich der Anwendungssicherheit noch weitaus mehr zu bieten.

Hier ein Überblick über die wichtigsten Projekte von OWASP, die sogenannten Flagship-Projekte:

OWASP Amass

Amass dient der DNS Enumeration, also der Zusammenstellung aller DNS-Datensätze eines Unternehmens, um so die Angriffsfläche von Netzwerken bestimmen zu können. Hierzu werden laut OWASP quelloffene Informationen gesammelt und aktive Aufklärungstechniken benutzt.

OWASP Application Security Verification Standard (ASVS)

Der ASVS bietet eine Grundlage, um die technischen Sicherheitskontrollen einer Webanwendung zu testen, und stellt Entwicklern gleichzeitig eine Liste mit Anforderungen für die sichere Entwicklung zur Verfügung. Dieser Standard kann etwa dazu benutzt werden, technische Sicherheitskontrollen auf Schwachstellen im Bereich des Cross-Site Scripting (XSS) und der SQL Injections zu überprüfen.

OWASP Cheat Sheet Series

Die OWASP Cheat Sheet Series wurde ins Leben gerufen, um insbesondere Anwendungsentwicklern eine Reihe von einfachen Good-Practice-Guides bereitzustellen. Hierbei wurde besonderen Wert auf Praktikabilität gelegt, sodass der Großteil der Entwickler diese Praktiken auch tatsächlich implementieren kann.

CSRFGuard

Bei CSRFGuard handelt es sich um eine Bibliothek, welche eine Variante des Synchronizer Token Patterns darstellt, um das Risiko von Angriffen via Cross-Site Request Forgery (CSRF) zu minimieren. Momentan arbeitet OWASP an der Version 4.0, die einige Schwachstellen der aktuellen Version beheben soll, bei der CSRFGuard durch XSS oder Session Hijacking umgangen werden kann.

OWASP Defectdojo

DefectDojo ist ein Schwachstellen-Management-Tool, das den Testprozess von Schwachstellen optimiert, indem es beispielsweise Templates, Generatoren für Berichte und Metriken zur Verfügung stellt. Hauptaugenmerk dieses Projekts liegt darauf, den Aufwand von Sicherheitsexperten zu minimieren, der mit dem Verwalten von Schwachstellen verbunden ist.

OWASP Dependency-Check

Der Dependency-Check ist ein Werkzeug zur Software Composition Analysis (SCA), das versucht, bereits bekannte Schwachstellen und Sicherheitslücken in den Komponenten eines Projekts aufzuspüren. Dies geschieht durch einen Abgleich mit dem Standard Common Platform Enumeration (CPE). Sofern es Treffer gibt, wird ein Bericht mit diesen generiert, wobei auf die entsprechenden Einträge im CPE verlinkt wird.

OWASP Dependency-Track

Dependency-Track versucht eine intelligente Plattform für die Komponenten-Analyse einer Organisation zu bieten, durch die Risiken in der Software-Lieferkette erkannt und minimiert werden können. Durch den Ansatz, dass das Potenzial der Software Bill of Materials (SBOM) ausgeschöpft wird, kann Dependency-Track Vorteile gegenüber anderen SCA-Lösungen haben.

OWASP Juice Shop

OWASP Juice Shop ist eine Webanwendung, welche für Security-Trainings, CTFs und Testzwecke verwendet werden kann. Juice Shop enthält verschiedene Hacking-Herausforderungen mit variierendem Schwierigkeitsgrad, alle OWASP Top Ten Schwachstellen und viele weitere Sicherheitslücken, die durch einen Gamification-Ansatz darauf warten, entdeckt und ausgenutzt zu werden.

OWASP Mobile Security Testing Guide

Der OWASP Mobile Security Testing Guide ist eine umfassende Anleitung zum Testen der Sicherheit mobiler Anwendungen und zum Reverse Engineering für iOS und Android.

OWASP Mobile Top 10

Die OWASP Mobile Top 10 sind (angelehnt an die bereits erwähnten Top 10 für Webanwendungen) die zehn größten Risiken für mobile Anwendungen.

OWASP ModSecurity Core Rule Set

Das OWASP ModSecurity Core Rule Set (CRS) ist eine Sammlung allgemeiner Regeln zum Aufspüren von Angriffen, die mit kompatiblen Firewalls für Webanwendungen (WAFs) genutzt werden kann. CRS zielt darauf ab, Webanwendungen vor einer Vielzahl von Angriffen zu schützen, wobei die Rate von Fehlalarmen so gering wie möglich gehalten werden soll.

OWASP OWTF

OWASP OWTF ist ein Projekt, das es sich zum Ziel gesetzt hat, Penetrationstests effizienter, umfangreicher und gleichzeitig kreativer und spaßiger zu gestalten, um so das Pensum an unkreativer Arbeit zu minimieren. Das Credo für dieses Projekt lautet, dass in weniger Zeit mehr getestet werden soll und das Projekt die Penetrationstester hierbei unterstützt, indem zum Beispiel das Schreiben von Berichten zeitsparender gestaltet wird.

OWASP SAMM

Das OWASP Software Assurance Maturity Model (SAMM) ist ein öffentliches Framework, das Unternehmen dabei hilft, eine Strategie zur Softwaresicherheit zu erarbeiten und zu implementieren, die auf die Risiken zurechtgeschnitten ist, mit denen das entsprechende Unternehmen konfrontiert ist.

OWASP Security Knowledge Framework

OWASP Security Knowledge Framework (SKF) ist eine Webanwendung, die die Prinzipien von sicherem Programmieren in verschiedenen Programmiersprachen erklärt. Dies wird anhand überschaubarer Entwicklungsprojekte und anhand von Laboren zum Üben von Sicherheitsprüfungen erreicht, um die Sicherheit von Anwendungen von Anfang an in den Entwicklungsprozess mit einzubinden.

OWASP Security Shepherd

Der OWASP Security Shepherd ist eine Sicherheitstrainings-Plattform, die es sowohl als Webversion als auch als mobile Anwendung gibt. Die Anwendung hat als Ziel, das Sicherheitsbewusstsein zu fördern, wobei die Anwendung für alle Erfahrungsstufen vom Anfänger bis zum erfahrenen AppSec Engineer vorgesehen ist.

OWASP Web Security Testing Guide

Der OWASP Web Security Testing Guide dient als erste Anlaufstelle für Webanwendungs-Entwickler und Sicherheitsexperten im Bereich Cybersecurity-Testing. Er bildet einen Guide zum Testen von Webanwendungen und Webservices.

OWASP ZAP

OWASP Zed Attack Proxy (ZAP) ist ein Werkzeug für Penetrationstests, das sowohl von Anfängern in der Anwendungssicherheit als auch von professionellen Penetrationstestern genutzt werden kann. Im Kern ist ZAP ein Person-in-the-Middle-Proxy, der die Kommunikation zwischen Browser und Webanwendung abfangen, inspizieren und wenn nötig verändern kann.

HiSolutions Research

Ruck ohne Hau – Corona-Warn-App kein Security-Albtraum

Es geht diese Tage ein Ruck durch das Neuland – und zwar kein Hau-Ruck, den viele gleichwohl befürchtet hatten, als sich abzuzeichnen drohte, dass auch die deutsche Corona-Warn-App bei Datenschützenden und anderen IT-Justice Warriors von Anfang an in Ungnade stehen würde. Nun staunt der Laie – und selbst der Chaos Computer Club und sein Umfeld wundern sich: Ist die Macht der Datenverbraucherschützer wirklich so groß geworden, dass Behörden sich wandeln und plötzlich agile Open Source produzieren (lassen)? Anscheinend haben das Schreiben offener Briefe und das Führen hitziger Diskussionen in den sozialen Medien diesmal zwei Großkonzerne und mehrere Behörden dazu gebracht, in entscheidenden (auch datenschutz- bzw. sicherheitskritischen) Fragen umzusteuern. Das sind wir nicht gewöhnt!

Gezeigt hat sich auf jeden Fall schon jetzt: Die frühzeitige und umfassende Einbindung, gerade auch kritischer Kunden- und Gesellschaftsgruppen hat der Verbreitung der App zumindest nicht geschadet. Ob dies auch massenhafte Nutzung garantiert, steht auf einem anderen Blatt. Aber in einer idealen Welt wird auch dieser Prozess wie alle anderen gesellschaftlich relevanten Veränderungen von einer informierten und kritisch-produktiven Öffentlichkeit begleitet und wenn notwendig in die richtige Richtung gestupst. Auch angesichts einiger anderer Meldungen in diesem Digest: Zu Tode gesiegt hat sich die digitale Bürgerrechtsbewegung noch lange nicht.

https://www.zdf.de/nachrichten/politik/corona-app-launch-100.html

HiSolutions Research

SHIFT LEFT – Linksruck im Neuland?

Linksruck in der IT? Was soll das bedeuten? Gewerkschaften bei Amazon? Google-style Walkouts bei SAP? Mindestlohn für Consultants bei Accenture und Co.? Keineswegs! Der aktuell „trendende“ Kampfruf „Shift Left“ spielt an auf die Bewegung nach links im Entwicklungszyklus von Software oder anderen IT-Produkten, also im SDLC (Software Development Life Cycle). Es mag merkwürdig anmuten, in Bezug auf einen Kreis(lauf) von „links“ und „rechts“ zu sprechen. Gemeint ist eine Bewegung hin zu den Tätigkeiten, die in der Entwicklung früh vorgenommen werden sollten.

Ein Penetrationstest setzt spät – „rechts“ – an und zieht dementsprechend große Aufwände nach sich, wenn grundsätzliche Dinge zu reparieren sind. Früher – „weiter links“ – wirkt sichere Softwareentwicklung. Und idealerweise wird die Security bereits „ganz links“, also in der Definition von Sicherheitsanforderungen, berücksichtigt.

Die Idee ist alles andere als neu. Doch scheint sie sich momentan aus ihrem Schattendasein als Elefant im Raum langsam in Richtung rosa Kaninchen auf der Tanzfläche zu bewegen. Immer mehr Organisationen umarmen das Konzept des „Linksrucks“ und greifen dafür in nicht unerheblichem Maße in althergebrachte Arbeitsweisen und Rollenverständnisse ein.

Der Hauptgrund dürfte – wie so oft bei der Umwälzung gesellschaftlicher oder technischer Verhältnisse – in der Veränderung der Produktionsbedingungen selbst liegen. Im Wasserfallmodell konnte man ans Ende der eh um 80 % überzogenen Entwicklungszeit und -budgets auch noch einen Penetrationstest „dranklatschen“, dessen Empfehlungen dann im Zweifel nicht umgesetzt wurden. In agilen Sprints mit DevOps-Prozessen und Hunderten von Microservices in Tausenden von Containern, die von Dutzenden Teams entwickelt und verantwortet werden, ist dies nicht mehr möglich. Wohl oder übel muss die Security ebenfalls agiler und mithin deutlich schneller werden – und das geht nur, indem sie früh im Entwicklungsmodell beginnt. Google etwa tanzt das aktuell mit dem Konzept BeyondProd (siehe Lesetipps) eindrucksvoll vor.

Bitte nicht falsch verstehen: Der klassische Penetrationstest hat weiterhin seine Daseinsberechtigung und ist in vielen Situationen (Legacy, Brownfield, Compliance …) das geeignete Mittel, um Schwachstellen zu identifizieren. Er muss allerdings zukünftig zu einem ganzheitlichen SDL (Security Development Lifecycle) ergänzt werden.

https://www.heise.de/developer/artikel/Shift-Left-Secure-by-Design-und-agile-Entwicklung-4613935.html