Umsetzungsleitfaden ISO 27001:2022 (1)

Startseite » Blog » Umsetzungsleitfaden ISO 27001:2022 (1)

Wie können Startups und KMU die neuen Anforderungen der ISO 27001:2022 pragmatisch umsetzen? (Teil 1)

Einleitung

In diesem Blogbeitrag gehen wir auf die neuen Anforderungen der ISO 27001:2022 ein und diskutieren, wie Start-ups und kleine und mittlere Unternehmen (KMU) diese pragmatisch umsetzen können. Mit der neuesten Version wurde insbesondere der Anhang A des ISO Standards stark überarbeitet und neue Anforderungen / Controls aufgenommen. In diesem Beitrag werden wir uns auf die 11 neuen Anforderungen konzentrieren und erläutern, wie diese umgesetzt werden können, ohne die Ressourcen und das Budget des Unternehmens zu überstrapazieren. In Teil 1 werden die folgenden Anforderungen behandelt:

  • A.5.7 Threat Intelligence
  • A.5.23 Information security for use of cloud services
  • A.5.30 ICT readiness for business continuity
  • A.7.4 Physical security monitoring
  • A.8.9 Configuration management

A.5.7 Threat Intelligence

Beschreibung

Threat Intelligence (TI) bezeichnet die Sammlung, Analyse und Bewertung von Informationen über Bedrohungen. Das systematische Analysieren der Bedrohungslage trägt zum proaktiven Schutz von Informationen und IT-Systemen bei und ist somit Teil der kontinuierlichen Verbesserung der Informationssicherheit. Threat Intelligence kann extern oder intern generiert werden. Dafür sind die folgenden Schritte zu befolgen:

  1. Ein aktives Sammeln von Informationen über Bedrohungen aus verschiedenen Quellen

  2. Eine Analyse dieser Informationen, um Muster und Trends zu erkennen

  3. Die Bereitstellung der Erkenntnisse an diejenigen, die sie verwenden können, um entsprechende Gegenmaßnahmen zu ergreifen.

Umsetzungshinweise

Es ist nicht immer notwendig, in zusätzliche Tools zu investieren. Um sich über Bedrohungen zu informieren, stehen im Internet verschiedene Quellen (“Threat Intelligence Feeds”) zur Verfügung. Wichtig ist, die verfügbaren Informationen regelmäßig auszuwerten und daraus Schlüsse zu ziehen.

Bedrohungsinformationen können in drei Ebenen unterteilt werden: Strategische Bedrohungsinformationen, taktische Bedrohungsinformationen und operative Bedrohungsinformationen. Operative Bedrohungsinformationen haben in der Regel einen sehr kurzen Lebenszyklus, da viele Indikatoren für eine Kompromittierung (Indicators of Compromise – IoCs) schnell veralten. Die Verarbeitung dieser Informationen erfolgt meist vollautomatisch in den eingesetzten Sicherheitslösungen (z.B. Antivirus, Firewalls oder Mail-Gateways). Für die Erfüllung dieses Controls sollte daher der Fokus insbesondere auf strategische und taktische Bedrohungsinformationen gelegt werden. Typische Informationsquellen für diese Art von Informationen sind Meldungen der Hersteller, vertrauenswürdige Webseiten wie z.B. Heise Security, Security Whitepaper oder der jährliche Lagebericht des BSI. Hier geht es nun darum, nachweisen zu können, dass Bedrohungsinformationen regelmäßig gesichtet und an die entsprechenden Stellen (Administratoren, ISO, Geschäftsführung) weitergeleitet werden, damit entsprechende Gegenmaßnahmen ergriffen werden können. Dies kann z.B. in Form eines internen Threat Intelligence Reports erfolgen, in dem gesichtete Quellen, Erkenntnisse und mögliche Gegenmaßnahmen aufgelistet werden.

A.5.23 Information security for use of cloud services

Beschreibung

Die Anforderungen der ISO 27001:2022 betreffen auch den sicheren Gebrauch von Cloud-Diensten. Unter Cloud-Dienste fallen jedoch nicht nur dir großen Cloud-Anbieter wie AWS, Azure oder GCP. Vielmehr sind alle Cloud Service-Modelle (IaaS, Paas, SaaS) zu betrachten und damit auch Cloud basierte Software wie z.B. Atlassian Confluence, Hubspot und Notion.

Es wird gefordert, dass Informationssicherheitsanforderungen über den gesamten Lebenszyklus von eingesetzten Cloud-Diensten berücksichtig werden. Also bei der Beschaffung, der Nutzung, der Verwaltung sowie beim Exit aus Cloud-Diensten. In der Cloud sind der Cloud-Anbieter und der Cloud-Nutzer gemäß des “Modells der geteilten Verantwortung” (Shared Responsibility) gemeinsam für die Sicherheit verantwortlich. Wichtig ist, dass diese Verantwortlichkeiten festgelegt sind und überprüft wird ob der Cloud-Anbieter seiner Verantwortung gerecht wird, und für eine angemessene Sicherheit sorgt.

Umsetzungshinweise

Um die Anforderungen der Norm in Bezug auf Cloud-Dienste zu erfüllen, stehen zwei Themen im Vordergrund: Die Erstellung einer Cloud-Richtlinie und die Aufnahme von Cloud-Anbietern in eine zentrale Übersicht (Lieferantenmanagement).

In der Richtlinie sind insbesondere Punkte wie Verantwortlichkeiten, Freigabeprozesse, Sicherheit in Lieferantenverträgen und risikobasierte Sicherheitsanforderungen zu beschreiben.

Typische Sicherheitsanforderungen könnten z.B. sein

  • Einsatz von Multi-Faktor-Authentifizierung

  • Verschlüsselung von Informationen bei Speicherung und Übertragung

  • Schwachstellen- und Patch-Management
  • Maßnahmen nach dem Stand der Technik zur Erkennung und Abwehr von netzwerkbasierten Angriffen.

Je nach gewähltem Cloud-Service-Modell gibt es Unterschiede, ob der Cloud-Anbieter oder der Cloud-Nutzer die einzelnen Anforderungen erfüllen bzw. umsetzen muss.

In einer zentralen Übersicht (häufig das Lieferantenmanagement oder ein eigenes Cloud Register) sollten alle genutzten Cloud Services aufgelistet und Verantwortlichkeiten zugeordnet werden.

A.5.30 ICT readiness for business continuity

Beschreibung

ICT steht für “Information and Communications Technology”. Bei dieser Anforderung geht es also darum, sicherzustellen, dass die IT- und Kommunikationssysteme im Störungsfall innerhalb einer akzeptablen Zeit wiederhergestellt werden können. Dies ist wichtig, damit die Unternehmensziele auch bei einem Ausfall der Systeme weiterhin erreicht werden können. Um auf Ausfallsituationen vorbereitet zu sein, sollten Pläne für relevante Notfallszenarien erstellt und darauf aufbauend Übungen durchgeführt werden.

Umsetzungshinweise

Grundsätzlich sollten für alle kritischen IT-Systeme, Anwendungen und IT-Infrastrukturen angemessene Redundanzen implementiert sein. Darüber hinaus sollte ein Plan vorhanden sein, der beschreibt, wie in Ausfallsituationen reagiert werden soll. Ein solcher Notfallplan sollte unter anderem folgende Punkte enthalten:

  • Beschreibung der betroffenen Werte (IT-Systeme, Applikationen oder IT-Infrastrukturen)
  • Beschreibung des Ausfallszenarios

  • Sofortmaßnahmen

  • Interne und externe Kontaktpersonen
  • Wiederherstellungspläne

Bleibt noch die Frage zu klären, was eigentlich als “kritisch” einzustufen ist. Dazu definiert man am besten die maximal tolerierbare Ausfallzeit (MTA) für IT-Systeme, Anwendungen und IT-Infrastrukturen. Beispielsweise könnte festgelegt werden, dass für alle Systeme, bei denen die MTA 24 Stunden beträgt, Redundanzen aufgebaut werden müssen und ein Notfallplan vorhanden sein muss.

Dokumentierte Übungen runden das Bild ab und liefern den notwendigen Nachweis im Audit.

A.7.4 Physical security monitoring

Beschreibung

A.7.4 Physical security monitoring beschreibt die Anforderungen an die Überwachung der physischen Sicherheit von Informationssystemen. Dies betrifft insbesondere die Zugänge zu Gebäuden, in denen kritische Systeme untergebracht sind. Hier muss eine kontinuierliche Überwachung stattfinden. Dies kann z.B. durch Videoüberwachung oder einen Wachdienst gewährleistet werden. Weniger aufwändige Möglichkeiten sind z.B. die Installation von Kontakt-, Schall- oder Bewegungsmeldern.

Umsetzungshinweise

Spätestens wenn es um den Betrieb eines Server- oder Technikraumes in den eigenen Räumlichkeiten geht, kommt man in den meisten Fällen nicht um eine Überwachung mittels Kamerasystemen herum, um unbefugten Zutritt oder verdächtiges Verhalten schnellstmöglich zu erkennen.

Die für eine Videoüberwachung notwendigen zentralen Technikkomponenten sollten in einer geeigneten Umgebung geschützt aufgestellt werden. Es sollte regelmäßig überprüft werden, ob die Videoüberwachungsanlage ordnungsgemäß funktioniert und ob die datenschutzkonformen Blickwinkel eingehalten werden.

Wenn eine kontinuierliche Überwachung der Räumlichkeiten als nicht durchführbar oder nicht erforderlich erachtet wird, sollte dies in einem Risiko festgehalten und bewertet werden. Dies kann z. B. der Fall sein, wenn im Gebäude keine kritische IT-Infrastruktur betrieben wird und keine sensiblen Daten in größerem Umfang verarbeitet werden.

A.8.9 Configuration management

Beschreibung

Der sichere IT-Betrieb basiert im Wesentlichen auf der sicheren Konfiguration von Hardware, Software, Diensten und Netzwerken. Daher sollten für wichtige Systemgruppen sichere Standardkonfigurationen definiert werden. Bei der Erstellung dieser Konfigurationen sind u.a. eigene Richtlinien, Herstellervorgaben und andere Best Practices zu berücksichtigen.

Zum Konfigurationsmanagement gehört natürlich nicht nur die Erstellung, sondern auch die Überwachung, ob Standardkonfigurationen verwendet oder verändert wurden.

Auch die Systemhärtung ist ein typischer Bestandteil des Konfigurationsmanagements.

Umsetzungshinweise

Für Systeme oder Gruppen von Systemen, die sensible Informationen verarbeiten oder für kritische Geschäftsprozesse erforderlich sind, sollte eine Standardkonfiguration (Baseline) auf der Grundlage bewährter Best Practices festgelegt und verwendet werden. Die Standardkonfiguration sollte z.B. folgende Aspekte berücksichtigen

  • Die Anzahl der Benutzer mit privilegierten oder administrativen Zugriffsrechten sollte auf ein Minimum beschränkt werden.
  • Unnötige, ungenutzte oder unsichere Benutzer sollten deaktiviert werden.
  • Unnötige Funktionen und Dienste sollten deaktiviert werden, um die Angriffsfläche zu minimieren (Härtung).
  • Standard-Authentifizierungsinformationen (z.B. Standardpasswörter) sollten unmittelbar nach der Installation geändert werden.
  • Einrichtung von “Timeouts”, um Benutzer nach einer bestimmten Zeit der Inaktivität automatisch abzumelden.

Wo immer möglich, sollte Automatisierung eingesetzt werden, um sicherzustellen, dass IT-Systeme einheitlich und sicher konfiguriert sind und Änderungen erkannt und dokumentiert werden. Tools für diesen Zweck sind beispielsweise Ansible, HashiCorp Terraform, Chef, Puppet, AWS Config, AWS Cloudformation, Microsoft Endpoint Manager und Jamf.

Teil 2 beschäftigt sich mit den folgenden Anforderungen der neuen ISO 27001:2022 und gibt hilfreiche Umsetzungstipps.

  • A.8.10 Information deletion
  • A.8.11 Data masking
  • A.8.12 Data leakage prevention
  • A.8.16 Monitoring activities
  • A.8.23 Web filtering
  • A.8.28 Secure coding

Du hast noch Fragen?

Kontaktiere uns gerne.