Die NIS-2 Richtlinie – was Unternehmen beachten müssen

Die NIS-2 Richtlinie – was Unternehmen beachten müssen

Von Dominik Weyand

Einleitung

Die Europäische Union hat eine überarbeitete Version ihrer Richtlinie zur Netz- und Informationssicherheit (NIS-2) verabschiedet, die Unternehmen dazu verpflichtet, ihre digitalen Systeme und Dienste besser zu schützen. Der deutsche Gesetzgeber muss daher bis zum 17. Oktober 2024 diese Richtlinie in den deutschen Rechtsrahmen einbinden. Aufgrund zunehmender Cyberbedrohungen und dem stetig wachsenden Risiko von Cyberangriffen auf kritische Infrastrukturen ist diese Aktualisierung notwendig. Im Folgenden werden die wichtigsten Anforderungen der NIS-2 Richtlinie erläutert. Im Anschluss wird dargestellt, welche Maßnahmen die betroffenen Unternehmen umsetzen müssen.

Die NIS-2-Richtlinie

Die NIS-2-Richtlinie erweitert den Anwendungsbereich auf eine Vielzahl unterschiedlicher Unternehmen und Dienstleistungsanbietern. Sowohl Unternehmen im Bereich der kritischen Infrastrukturen als auch digitale Dienstleister wie Cloud-Computing-Anbieter fallen unter diese Richtlinie. Die folgenden 18 verschiedenen Industrie- und Dienstleistungssektoren fallen in den Geltungsbereich, sofern sie mehr als 50 Mitarbeiter haben und einen Jahresumsatz von mindestens 10 Mio. € erwirtschaften:

Unternehmen, die gegen die Bestimmungen von NIS-2 verstoßen, können mit finanziellen Sanktionen belegt werden. Es ist daher entscheidend, dass Unternehmen die Anforderungen der Richtlinie ernst nehmen und angemessene Maßnahmen ergreifen, um die Sicherheit ihrer digitalen Infrastruktur zu gewährleisten.

Anforderungen an Betreiber kritischer Infrastrukturen

Betreiber kritischer Infrastrukturen müssen eine Reihe von Sicherheitsanforderungen erfüllen, um ein hohes Sicherheitsniveau zu erreichen. Die genauen Anforderungen können je nach nationaler Umsetzung der Richtlinie und der Art des Unternehmens variieren. Die folgenden Anforderungen sind jedoch unerlässlich und es wird Zeit brauchen, diese umzusetzen. Zu beachten ist hierbei die begrenzte Anzahl an Know-how Trägern, wodurch es besonders im dritten und vierten Quartal 2024 zu Engpässen kommen kann. Wer später nicht in Zeitdruck geraten möchte, nimmt die folgenden Themen besser schon heute auf die Agenda.
Im ersten Schritt sollten betroffene Unternehmen ihre aktuellen Sicherheitsmaßnahmen und -richtlinien überprüfen, um sicherzustellen, dass sie den Anforderungen von NIS-2 entsprechen. Gegebenenfalls müssen die Prozesse aktualisiert oder erweitert werden, um den neuen Anforderungen gerecht zu werden. Im nächsten Schritt ist es unerlässlich eine Risikobewertung durchzuführen, denn diese identifiziert die Schwachstellen in den digitalen Systemen und Diensten eines Unternehmens. Basierend auf der Risikobewertung können geeignete Sicherheitsmaßnahmen entwickelt und implementiert werden. Eine Besonderheit bei NIS-2 ist, dass Geschäftsführer bzw. Vorstände die Umsetzung überwachen müssen und für eventuelle Verstöße des Unternehmens nach nationalem Recht haftbar gemacht werden können.
Neben den Anforderungen an die Cybersecurity Governance, ist die Prävention ein ebenfalls entscheidender Faktor. Hierbei müssen Unternehmen angemessene technische und organisatorische Maßnahmen (TOM) nach dem “Stand der Technik” ergreifen, um die Sicherheit ihrer Netz- und Informationssysteme zu gewährleisten. Die Unternehmen können zur Orientierung beispielsweise auf die ISO 27001:2022 zurückgreifen.   
Die Anforderungen an das Business Continuity Management (BCM) sind in NIS-2 konkret beschrieben. Für ein konformes BCM sind Maßnahmen zur Aufrechterhaltung des Geschäftsbetriebs notwendig, wozu beispielsweise das Backup-Management, das Krisenmanagement oder das Recoverymanagement gehören. Darüber hinaus ist die Sicherheit in den Lieferketten zu gewährleisten. Dies bedeutet, dass sowohl die Netz- und Informationssicherheitssysteme als auch deren physische Umwelt zu berücksichtigen sind. Zu beachten sind die hieraus entstehenden Folgen für Unternehmen, die lediglich als Lieferanten tätig sind, also nicht direkt der Regulierung unterliegen. Die Folge für beispielsweise IT-Dienstleister und andere Zulieferer ist, dass sie Lieferantenaudits unterzogen werden, in denen die Robustheit ihrer Informationstechnik geprüft wird.       
Ebenfalls unerlässlich ist ein klar definierter Incident Response Plan, um im Falle eines Sicherheitsvorfalls schnell und angemessen reagieren zu können. Unternehmen sollten sicherstellen, dass alle relevanten Mitarbeiter mit dem Plan vertraut sind und regelmäßige Übungen durchführen, um die Wirksamkeit des Plans zu testen. Hinzu kommt, dass Unternehmen dazu verpflichtet sind, ernsthafte Sicherheitsvorfälle den nationalen Behörden zu melden. Dies umfasst nicht nur tatsächliche Angriffe, sondern auch Versuche von Cyberangriffen oder andere sicherheitsrelevante Ereignisse, die Auswirkungen auf ihre Dienste haben könnten. Eine Frühwarnung muss binnen 24 Stunden und die tatsächliche Meldung des Sicherheitsvorfalls spätestens innerhalb von 72 Stunden an die zuständigen Behörden übermittelt werden. Als „erheblich“ wird ein Sicherheitsvorfall eingestuft, wenn er zu schwerwiegenden Betriebsstörungen der Dienste oder zu finanziellen Verlusten für die betroffene Einrichtung führt oder führen kann. Gleiches gilt, wenn eine natürliche oder juristische Person durch einen solchen Vorfall erheblichen materiellen oder immateriellen Schaden erfährt oder erfahren könnte.

Fazit

Insgesamt erfordert die Umsetzung der NIS-2-Richtlinie ein proaktives und ganzheitliches Herangehen an das Thema Cybersicherheit. Unternehmen, die die Anforderungen der Richtlinie erfüllen und ihre digitalen Systeme und Dienste effektiv schützen, können nicht nur das Vertrauen ihrer Kunden stärken, sondern auch das Risiko von schwerwiegenden Cyberangriffen minimieren. Unternehmen, welche sich bereits mit dem IT-Sicherheitsgesetz 2.0 auseinandergesetzt haben, werden in den Anforderungen aus NIS 2 wenig neues entdecken. Die nicht unerhebliche Ausweitung des Anwendungsbereichs wird jedoch dazu führen, dass viele Unternehmen, die bisher nicht betroffen waren, sich frühzeitig mit der Umsetzung der geforderten Maßnahmen auseinandersetzen müssen. Für ein besseres Verständnis der Richtlinie und deren Umsetzung bietet sich eine externe Beratung an. Diese unterstützt Sie bei der Umsetzung der geforderten Maßnahmen und hilft der Geschäftsführung die Haftungsrisiken zu minimieren.       
Unsere Experten helfen Ihnen gerne weiter und stehen für offene Fragen jederzeit zur Verfügung. Durch unsere jahrelange Erfahrung aus verschiedenen Branchen helfen wir Ihnen nicht nur bei aktuellen Problemen, sondern sorgen für ein nachhaltig hohes Sicherheitsniveau in Ihrem Unternehmen.

Security & The Doorman Fallacy: Why Security Teams (Need To) Do More

Security & The Doorman Fallacy: Why Security Teams (Need To) Do More

by Michael Helwig

A good security team is implicitly present in a multitude of aspects in an organization and its culture. However, often we see security teams proposing security requirements without taking care or even encouraging proper implementation of the proposed security concepts and requirements. But if security teams consider themselves as a mere function that is just setting the guardrails without business or users in mind, they will be reduced to that and will have no long-lasting effect on the overall security of an organization.

In traditional organizations, security teams often start with compliance, mainly defining standards, policies, and processes and expecting everyone to adhere to those. In smaller organizations, security activities might start on a technical level, trying to follow general best practices and avoiding issues in operation (incidents) that might result from a lack of secure configuration. In both cases, teams usually lack the perception of end-users who do not understand security well. Therefore security teams do not see the need to guide employees through a proper implementation and adoption of the proposed security best practices and requirements – leading to either frustration or ignorance on the part of the users. This neglect is to a degree understandable – a security specialist or sysadmin is not a project manager, nor can they be put in a spot where they must shoulder all the security responsibility for everyone else. In addition, the role of a security function can be severely limited by the amount of how much a business is willing to spend for its security capabilities. However, a security team not driving any projects and not feeling responsible for the actual state of security in an organization across all layers will likely fail in creating anything more than security on paper.

To form a successful security team, it is important to understand that security is more than a function. It is a living organism; it is water; it is a meme – it is whatever creeps into and influences every process, every design, every product of the organization increasing its resiliency in the best case – and what stays a bunch of documents no one wants to read and cumbersome processes no one wants to follow in the worst case.

Luckily, in recent years, certain areas of security – and especially product security – have transformed from a compliance role into an enabler role. The necessity of connecting security activities to business goals and thinking about user adoption has become more important. Their mission: Enable business to make business, to stay afloat by preventing hacks and incidents, and help product teams to deliver secure by default products with a reasonable effort which their users can use without getting frustrated by security processes. A good security team will look for ways to optimize processes and achieve security and compliance without spending endless time and resources on it. One key sentence formulated in CISA’s “Security by Design”  principles is that (software) manufacturers should take responsibility for customer security outcomes. This, we believe, is the key sentence for a successful product security program and potentially even for a whole enterprise security program in general. What it means is simple: Feel responsible for implementation and not just formulation or configuration of good security practice. Feel responsible for the outcome – that includes bad user passwords, insecure authentication choices, careless sharing of profile information, post-it notes with passwords on the computer screen, etc. Take ownership of these issues and consider and prevent them before they happen. The work of a good security team may start with the decision on adequate security controls, followed by implementation or configuration, but it does not end there. A security team needs to ensure the user is made aware of the implications of their security-related decisions, grasp the reasons why security processes benefit the company, and encourage decisions that will protect the user – internal or external – of a company’s products and services.

If we widen the perception of “user” a bit, we can take the sentence from the CISA paper as a key attitude also toward an organization’s employees: A security team should feel responsible for the phishing rates, for the hardcoded passwords, and that users might avoid your security tools because they are so difficult to use and no one ever cared to do a proper rollout or onboarding. If people don’t talk to you about security concerns because they are afraid you will cause them more work without resolving their concern, you are ultimately failing as a security team.

In the same way that product security is moving to an enabling culture and the clear understanding of shared responsibility, traditional enterprise security needs to move to care about implementation and culture. It is no secret that there usually is a big compliance gap: A company has their ISO 27001 / TISAX / NIST, etc., audit done, but the experts inside know that the technical security level is still lacking, and good security practices are limited to a small scope of the systems and processes. Documents and process definitions exist but they are not followed, and if they are followed, their outcome does not really contribute to a better security posture of the enterprise. This is what we see as the most dangerous form of a compliance gap: Not the gap between documents that an auditor requires and which a company might or might not have, but the gap that exists between the compliance stated on paper and the actual security of a company’s systems and processes. This is the gap that matters when you are talking about security and this gap might not even be properly reflected in your risk management activities, which are usually based on paper and checklists as well. And ultimately, this is a dangerous gap between a security team and its users. The paper is just a transport mechanism. If the ideas and concepts formulated in the security team fail to reach the company’s workforce, then there is no communication, and no actual security improvement will be achieved.

Coming back to the title of this paper, the Doorman Fallacy. The Doorman Fallacy, as mentioned by Rory Sutherland, is this:

Business, technology and, to a great extent, government have spent the last several decades engaged in an unrelenting quest for measurable gains in efficiency. However, what they have never asked, is whether people like efficiency as much as economic theory believes they do.

The ‘doorman fallacy’, as I call it, is what happens when your strategy becomes synonymous with cost-saving and efficiency; first you define a hotel doorman’s role as ‘opening the door’, then you replace his role with an automatic door-opening mechanism.

The problem arises because opening the door is only the notional role of a doorman; his other, less definable sources of value lie in a multiplicity of other functions, in addition to door-opening: taxi-hailing, security, vagrant discouragement, customer recognition, as well as in signalling the status of the hotel. The doorman may actually increase what you can charge for a night’s stay in your hotel.

Alchemy: The Dark Art and Curious Science of Creating Magic in Brands, Business and Life, Rory Sutherland, p. 126 f.

The Doorman fallacy is not only relevant from a business perspective (e.g. a company investing in tools to save costs on it’s security team); it is also relevant from a security team’s perspective. A good security team is like the doorman in a hotel: They guard people on their journey to use the hotel’s services. They recognize customer needs, are helpful, provide useful guidance and pathways. They need to be concerned about the end-to-end service the Hotel provides. Their notional function might be to take care of systems, policies, or standards or do proper system configuration. But if they stop there, they are not only missing out on opportunities to show the value of their work but run into the danger that they will never have a real impact on the security of their organization. Taking care of the end-to-end process, security can become a business advantage instead of a mere cost driver. If a security team and the organization start to understand that the security team’s work is not only about formulating requirements, documenting and following processes, but that they are part of a business context and that their users matter – then we will see significant improvements in the security of an organization, the breaking of “security silos” and the start of a real security culture with security as a doorman and its own, valuable contributions to the business.


Die neuen Controls der ISO IEC 27001 im Detail Teil 2

Die neuen Controls der ISO IEC 27001 im Detail Teil 2

von Dominik Weyand

Rückblick

Wie bereits im ersten Teil erläutert werden durch den neuen Aufbau der Controls die Attribute stärker spezifiziert und die Notwendigkeit stärker hervorgehoben. Des Weiteren wurden die neuen organisatorischen sowie physischen Controls erläutert. Der zweite Teil befasst sich mit den neuen technologischen Controls.

8.9 Konfigurationsmanagement

Das Control Konfigurationsmanagement fordert, dass die Unternehmen den gesamten Zyklus der Sicherheitskonfiguration für die Technologie der Organisation verwaltet, um ein angemessenes Sicherheitsniveau zu gewährleisten und unautorisierte Änderungen zu vermeiden. Dies beinhaltet die Definition, Implementierung, Überwachung und Überprüfung der Konfiguration. Neben der Richtlinie für das Konfigurationsmanagement soll zusätzlich ein Prozess für die Überprüfung sowie die Genehmigung von Sicherheitskonfigurationen und Prozessen erstellt werden.

8.10 Löschung von Informationen

Dieses Control beinhaltet die Anforderungen zur Datenspeicherung im Hinblick auf DSGVO. Darüber hinaus sollen Informationen, die in Informationssystemen, Geräten oder auf anderen Speichermedien gespeichert sind, gelöscht werden, sobald diese nicht mehr benötigt werden. Daher sollen die Unternehmen einen Prozess einrichten, der zum einen festlegt, welche Daten zu welchem Zeitpunkt gelöscht werden müssen, und zum anderen die Verantwortlichkeiten und Methoden für die Löschung definiert. Zudem sollte eine Richtlinie zur Informationsvernichtung erstellt und innerhalb des Unternehmens kommuniziert werden.

8.11 Datenmaskierung

Bei der Datenmaskierung geht es zusammengefasst um die Beschränkung, Anonymisierung sowie Pseudonymisierung von Daten. Das Control verlangt von den Unternehmen mit Hilfe der Datenmaskierung die Offenlegung sensibler Informationen zu begrenzen. Damit sind in erster Linie personenbezogene Daten gemeint, da diese durch Datenschutzbestimmungen stark reguliert werden. Zusätzlich können auch andere Kategorien sensibler Daten einbezogen werden. Die Datenmaskierung sollte in Übereinstimmung mit der themenspezifischen Richtlinie der Organisation zur Zugriffskontrolle sowie den geschäftlichen Anforderungen unter Berücksichtigung der geltenden Rechtsvorschriften erfolgen.
Die Erstellung einer Informationsschutzpolitik ist zwar nach der Norm optional, allerdings sollen durch das Unternehmen Prozesse eingerichtet werden, die festlegen, welche Daten maskiert werden müssen, wer auf welche Art von Daten zugreifen darf und welche Methoden zur Maskierung der Daten verwendet werden.

8.12 Verhinderung von Datenverlusten

Hierbei wird von den Unternehmen verlangt, dass verschiedene Maßnahmen festgelegt werden, die Datenlecks verhindern sollen, um die unbefugte Offenlegung sensibler Informationen zu verhindern. Zusätzlich sollen durch diese Sicherheitsmaßnahmen solche Vorfälle frühzeitig erkannt werden. Die Maßnahmen sollen auf Systeme, Netzwerke und alle anderen Geräte angewendet werden, die sensible Informationen verarbeiten, speichern oder übertragen.
In der Umsetzung bedeutet dies für die Unternehmen, dass Prozesse eingerichtet werden müssen, die die Sensibilität der Daten bestimmen, die Risiken verschiedener Technologien bewerten und Kanäle mit dem Potenzial für Datenlecks überwachen und festlegen. Ziel der Prozesse soll es sein die Offenlegung sensibler Daten zu verhindern. Eine zusätzliche Informationsschutzpolitik ist für dieses Control nicht zwingend erforderlich.

8.16 Überwachungstätigkeiten

Dieses Control verlangt, die Systeme des Unternehmens sowie abweichende Aktivitäten proaktiv zu überwachen, um diese frühzeitig zu erkennen und gegebenenfalls entsprechend auf den Vorfall zu reagieren. Durch die geeigneten Maßnahmen sollen potenzielle Informationssicherheitsvorfälle besser erkannt und bewertet werden.

Für eine konforme Dokumentation ist eine Protokollierungs- und Überwachungsrichtlinie notwendig. Zudem ist ein Prozess erforderlich, der festlegt welche Systeme überwacht werden und wer für die Überwachung Zuständig ist. Des Weiteren müssen Methoden für die Überwachung, die Erstellung sowie die Meldung von Ereignissen und Vorfällen bestimmt werden.

8.23 Web-Filterung

In diesem Control sollen Maßnahme festgelegt werden, die den Zugriff zu gefährlichen Webseiten verhindern, die Malware verbreiten oder aber unbefugt Daten auslesen. Daher muss das Unternehmen die Zugriffsrechte der Mitarbeiter verwalten, um die Systeme und Vermögenswerte zu schützen. Auf diese Weise kann verhindert werden, dass die Systeme kompromittiert und Illegale Inhalte aus dem Internet verwendet werden.
Die Erstellung einer Netzwerksicherheitspolitik ist dem Unternehmen selbst überlassen. Dennoch sollen Prozesse eingerichtet werden, welche die nicht erlaubten Webseiten sowie die notwendigen Web-Filter-Tools, inklusive des Überprüfungszeitraums, bestimmen.

8.28 Sichere Kodierung

Bei der Softwareentwicklung sollten die Grundsätze der sicheren Kodierung angewandt werden, um Sicherheitsschwachstellen in der Software zu verringern. Dies umfasst sowohl die Aktivitäten vor der Kodierung als auch während und danach.
Hierfür ist auch eine Richtlinie für die sichere Entwicklung und die sichere Kodierung notwendig. Zudem muss ein Prozess zur Definition der Mindestanforderungen an die sichere Kodierung eingerichtet werden, welcher sowohl für die interne als auch die externe Softwareentwicklung gilt. Darüber hinaus müssen Verfahren zur Überwachung neu auftretender Bedrohungen, zur Beratung über sichere Kodierung und zur Entscheidung über die verwendeten externen Tools und Bibliotheken festgelegt werden.

Fazit

Abschließend muss berücksichtigt werden, dass lediglich vier Controls inhaltlich komplett identisch geblieben sind. Dies hat zur Folge, dass es nicht ausreicht die neuen Controls in das Risikomanagement und die SoA (Statement of Applicability) einzupflegen sowie zu bewerten. Die Anforderungen bei bestehenden oder zusammengefassten Controls wurden zum einen spezifiziert und zum anderen hinzugefügt. Daraus resultierend stehen Unternehmen vor der großen Herausforderung über 800 neue oder geänderte Anforderungen umzusetzen. Darüber hinaus ist zu beachten, dass die tatsächlichen Auswirkungen der Revision auf Unternehmen von verschiedenen Faktoren abhängig sind. Daher wird empfohlen, sich mit einem Experten für Informationssicherheit Verbindung zu setzen, um die genauen Auswirkungen der ISO 27001:2022 auf Ihr Unternehmen zu ermitteln und geeignete Maßnahmen umzusetzen.

Die neuen Controls der ISO IEC 27001 im Detail Teil 1

Die neuen Controls der ISO IEC 27001 im Detail Teil 1

von Dominik Weyand

Einleitung

Durch die Revision der ISO 27001 sowie der ISO 27002 wurde die Norm auf den aktuellen Stand der Technik gebracht. Neben den Änderungen der Gliederung sowie kleiner inhaltlichen Anpassungen innerhalb der Norm liegt der Fokus auf den Controls im Anhang. Im Folgenden wird der Aufbau der Controls näher betrachtet und die neuen organisatorischen sowie physischen Controls kurz erläutert.

Aufbau der Controls

In der Version 2022 wurde jedes Control durch zwei neue Elemente erweitert. Diese hinzugefügten Elemente erleichtern es Informationen zu finden, das Control zu verstehen und die Anforderungen zu analysieren. Das erste Element ist eine Tabelle mit Attributen, welche ermöglicht die einzelnen Controls nach bestimmten Kriterien zu sortieren und zu filtern. Hierfür wurden fünf übergeordnete Merkmale festgelegt, welche jeweils durch Attribute spezifiziert werden:

Merkmale Attribute
Kontrolltypen Präventiv, Korrigierend, Aufdeckend
Informationssicherheitsmerkmale Vertraulichkeit, Integrität, Verfügbarkeit
Cybersecurity Konzepte Identifizieren, Schützen, Erkennen, Reagieren, Wiederherstellen
Operative Möglichkeiten Unternehmensführung, Verwaltung der Vermögenswerte, Informationssicherheit, Personalsicherheit, sichere Konfigurierung, Identitäts- und Zugriffsmanagement, Bedrohungs- und Schwachstellenmanagement, Kontinuität, Sicherheit der Lieferantenbeziehungen, Compliance, Verwaltung von Informationssicherheitsereignissen, Sicherstellung der Informationssicherheit
Sicherheitsbereiche Governance und Ökosystem, Schutz, Verteidigung, Widerstandsfähigkeit

Das zweite hinzugefügte Element ist die Erläuterung des Zwecks, wodurch die Notwendigkeit der Umsetzung besser erklärt und die Angemessenheit zur Behandlung einfacher bewertet werden.

5.07 Bedrohungsintelligenz

In dem neuen Control der Bedrohungsintelligenz sollen Informationen über Bedrohungen der Informationssicherheit gesammelt und analysiert werden, um Schutzmaßnahmen zu bestimmen. Dabei können die gesammelten Informationen bestimmte Angriffe, Methoden und Technologien der Angreifer oder auch Angriffstrends beinhalten. Die Unternehmen sollen diese Informationen sowohl intern als auch extern durch beispielsweise Bekanntmachungen von Regierungsbehörden oder Herstellerberichten einholen.

Eine Richtlinie für Bedrohungsintelligenz ist laut der Norm optional und nicht verpflichtend. Allerdings muss das Unternehmen Prozesse festlegen, mit denen die Informationen über Bedrohungen gesammelt und verwendet werden, um präventive Kontrollen in den IT-Systemen der Organisation einzuführen, die Risikobewertung zu verbessern und neue Methoden für Sicherheitstests einzuführen.

5.23 Informationssicherheit für die Nutzung von Cloud-Diensten

Das Control stellt an die Unternehmen die Anforderung, dass ein Prozess für den Erwerb, die Nutzung, die Verwaltung und den Ausstieg aus Cloud-Diensten festgelegt wird, welcher mit den eigenen Informationssicherheitsanforderungen übereinstimmt. Darüber hinaus soll der Prozess Kriterien sowie Sicherheitsanforderungen für die Auswahl und akzeptable Nutzung eines Cloud-Anbieters enthalten. Hierdurch soll ein besserer Schutz der Unternehmensdaten in der Cloud gewährleistet werden.
Ebenso wie im vorherigen Control wird eine Richtlinie für Cloud-Dienste empfohlen, ist allerdings nicht verpflichtend.

5.30 IKT[1]-Bereitschaft für Geschäftskontinuität

Dieses Control beinhaltet Anforderungen an Wiederherstellungsmaßnahmen, wobei der neue Fokus auf den technischen Maßnahmen liegt. Die IKT-Bereitschaft sollte auf der Grundlage von Geschäftskontinuitätszielen und IKT-Kontinuitätsanforderungen geplant, implementiert, aufrechterhalten und geprüft werden. Unternehmen müssen also sicherstellen, dass die IKT auf potenzielle Störungen vorbereitet ist, damit die benötigten Vermögenswerte und Informationen bei Bedarf verfügbar sind. Ebenso wird gefordert, dass ein Wartungsprozess für die eingesetzte Technologie sowie ein Disaster Recovery Plan mit Maßnahmen und Anweisungen erstellt wird. Der Disaster Recovery Plan umfasst dabei verschiedene Szenarien wie beispielsweise Naturkatastrophen oder Cyber-Angriffe. Die Erstellung einer Richtlinie gemäß der IKT-Bereitschaft für die Geschäftskontinuität ist optional.

7.4 Überwachung der physischen Sicherheit

Dieses Control fordert Überwachungsmaßnahmen zur Abschreckung vor unbefugtem Zugriff sowie dem Schutz von sensiblen Bereichen. Zu diesen Bereichen können Büros, Produktionsanlagen, Läger oder auch andere Räumlichkeiten gehören. Wichtig ist hierbei, dass die sensiblen Bereiche kontinuierlich auf unbefugten physischen Zugang überwacht werden. Aus diesem Grund fordert die Norm auch ein Dokument, welches die physische Sicherheitspolitik des Unternehmens erläutert. Zudem soll ein Verfahren festgelegt werden, welches die Verantwortlichkeiten der Überwachung sowie die Kommunikation bei einem Vorfall regelt. Mögliche Überwachungsmaßnahmen bzw. -systeme sind beispielsweise Bewegungsmelder, Wachpersonal oder eine Videoüberwachung.

Zwischenfazit

Durch die Erweiterung des Aufbaus der jeweiligen Controls werden zum einen die Attribute stärker spezifiziert und zum anderen die Notwendigkeit stärker hervorgehoben. Darüber hinaus werden durch die Betrachtung der Bedrohungsintelligenz und die Nutzung von Cloud-Diensten aktuelle Themen in den organisatorischen Controls betrachtet. Für die Umsetzung der neuen Controls wird empfohlen, sich mit einem Experten für Informationssicherheit in Verbindung zu setzen, um die spezifischen Auswirkungen der ISO 27001:2022 auf ihr Unternehmen zu ermitteln und geeignete Maßnahmen umzusetzen. Im zweiten Teil werden die neuen technologischen Controls näher betrachtet und die Auswirkungen der Änderungen in einem Fazit abschließend bewertet.

[1] Informations- und Kommunikationstechnologien