SECCRIT – Sichere Cloud für kritische Infrastrukturen

Es ist eine Frage, die uns in Österreich immer häufiger gestellt wird: Ist die Cloud für kritische Infrastruktur überhaupt geeignet? Unsere Antwort darauf ist so klar wie einfach – ja, sie ist es. Und zwar nicht, weil die Cloud bequem ist, sondern weil sie für viele Betreiber längst Realität ist. Energieversorger, Wasserversorger, Verkehrsbetriebe und Gesundheitseinrichtungen nutzen Cloud-Dienste heute selbstverständlich. Die eigentliche Frage lautet daher nicht mehr, ob kritische Infrastruktur in die Cloud gehört, sondern wie wir sie dort sicher betreiben. Genau an diesem Punkt setzt SECCRIT an. Denn Sicherheit ist kein Hindernis auf dem Weg in die Cloud – sie ist die Grundlage, auf der eine vertrauenswürdige Cloud-Transformation überhaupt erst möglich wird. In diesem Beitrag zeigen wir, warum Cloud-Sicherheit für kritische Infrastruktur in Österreich unverzichtbar ist, wie Anomalieerkennung als Frühwarnsystem wirkt, wie resiliente Cloud-Architekturen im Ernstfall bestehen und was die NIS2-Richtlinie sowie das österreichische NISG 2024 konkret von Betreibern verlangen.

Warum Cloud-Sicherheit für kritische Infrastruktur in Österreich unverzichtbar ist

Wenn wir mit österreichischen Betreibern kritischer Infrastruktur sprechen, hören wir zwei Sätze besonders oft. Der erste lautet: „Wir können unsere Systeme doch nicht einfach in die Cloud geben.“ Der zweite lautet: „Eigentlich sind wir schon längst dort.“ Beide Sätze stimmen – und genau darin liegt die Spannung, die den gesamten Diskurs über Cloud-Sicherheit prägt. Die Digitalisierung macht auch vor jenen Sektoren nicht halt, deren Ausfall unsere Gesellschaft unmittelbar treffen würde. Stromnetze werden intelligenter gesteuert, Bahninfrastruktur wird datengetrieben überwacht, Wasserversorgung wird über verteilte Sensoren überwacht. All das erzeugt Datenmengen, die sich ohne Cloud kaum noch wirtschaftlich verarbeiten lassen.

Gleichzeitig bedeutet diese Entwicklung, dass die Angriffsfläche wächst. Ein erfolgreicher Cyberangriff auf einen Energieversorger ist kein IT-Problem mehr, sondern ein gesellschaftliches. Deshalb ist Cloud-Sicherheit für kritische Infrastruktur in Österreich keine Option, sondern eine Überlebensfrage. Wir verstehen darunter weit mehr als Firewalls und Verschlüsselung. Es geht um die Fähigkeit, Angriffe früh zu erkennen, Systeme rasch wiederherzustellen und regulatorische Anforderungen nachweisbar zu erfüllen. Genau diese drei Fähigkeiten – Erkennung, Resilienz und Compliance – bilden den Kern unserer Arbeit.

Kritische Infrastruktur in Österreich: Sektoren und Betreiber

Was in Österreich als kritische Infrastruktur gilt, ist gesetzlich definiert und umfasst eine Reihe von Sektoren, deren Störung erhebliche Auswirkungen auf die öffentliche Sicherheit, die Versorgung oder das Funktionieren des Gemeinwesens hätte. Zu den zentralen Bereichen zählen Energie, Wasser, Verkehr, Gesundheit, Finanzwesen, digitale Infrastruktur sowie staatliche Verwaltung. Die Bandbreite der Betreiber ist groß – von kleinen regionalen Wassergenossenschaften bis zu großen, national bedeutsamen Unternehmen.

Zwei Beispiele, die wir in unserer täglichen Arbeit immer wieder nennen, machen die Dimension deutlich. Die Wiener Linien betreiben das Rückgrat des öffentlichen Nahverkehrs in der Bundeshauptstadt. Ein Ausfall von Leitsystemen, Fahrgastinformation oder Ticketing hätte unmittelbare Folgen für Hunderttausende Menschen pro Tag. Die ÖBB wiederum steuern als größtes Verkehrsunternehmen des Landes Bahninfrastruktur, Signaltechnik und Fahrgastinformationssysteme, deren Störung weit über Österreich hinaus wirken kann. Beide Organisationen sind Beispiele dafür, wie eng betriebliche Effizienz heute mit digitaler Infrastruktur verwoben ist – und wie sehr diese Infrastruktur auf Cloud-Dienste angewiesen ist.

Für uns bedeutet das: Wenn wir über Cloud-Sicherheit sprechen, sprechen wir nicht über abstrakte IT-Themen. Wir sprechen über jene Systeme, die dafür sorgen, dass in Wien die U-Bahn fährt, dass in Linz die Produktionsbetriebe Strom haben und dass in Graz die Wasserversorgung stabil bleibt. Diese Verantwortung prägt jede Empfehlung, die wir aussprechen.

Cloud-Nutzung vs. Souveränität: Warum österreichische Unternehmen umdenken

Lange Zeit galt die Cloud in sicherheitskritischen Branchen als riskant. Man fürchtete den Verlust der Kontrolle, die Abhängigkeit von ausländischen Anbietern und rechtliche Unsicherheiten. Diese Sorgen sind berechtigt, und wir nehmen sie ernst. Gleichzeitig beobachten wir ein Umdenken, das wir für überfällig und richtig halten. Denn Souveränität entsteht heute nicht dadurch, dass man Daten in einem eigenen Keller einschließt. Souveränität entsteht durch Architektur, Vertragsgestaltung und technische Kontrolle.

Österreichische Unternehmen erkennen zunehmend, dass sie ihre Souveränität stärken können, indem sie bewusst entscheiden, wo welche Daten liegen, welche Anbieter welche Rolle spielen und wie sie ihre Systeme gestalten. Eine hybride Cloud-Strategie kann durchaus souveräner sein als ein veraltetes lokales Rechenzentrum, das seit Jahren nicht mehr gepflegt wurde. Entscheidend ist nicht der Standort allein, sondern die Frage, wer wann welche Kontrolle über welche Daten und Prozesse hat.

Wir raten Betreibern daher, Souveränität nicht als geografisches, sondern als organisatorisches und technisches Ziel zu verstehen. Dazu gehören klare Datenklassifizierungen, vertragliche Garantien, Verschlüsselungskonzepte und – ganz wesentlich – die Fähigkeit, Anomalien in der eigenen Cloud-Landschaft selbst zu erkennen. Wer seine Umgebung nicht durchschaut, kann sie nicht schützen, egal wo sie steht.

NIS2 und NISG 2024: Neue Pflichten für Cloud-Sicherheit

Die NIS2-Richtlinie der Europäischen Union hat den regulatorischen Rahmen für Cybersicherheit in kritischen Sektoren deutlich verschärft. In Österreich wurde sie mit dem Netz- und Informationssystemsicherheitsgesetz 2024, kurz NISG 2024, umgesetzt. Für Betreiber kritischer Infrastruktur bedeutet das eine Reihe neuer Pflichten, die unmittelbar auf die Cloud-Sicherheit einzahlen.

Wir fassen die wichtigsten Anforderungen so zusammen, wie wir sie in Projekten erleben:

• Ein umfassendes Risikomanagement für IT- und Netzwerksysteme, das auch Cloud-Dienste und Lieferanten umfasst.
• Technische Maßnahmen wie Verschlüsselung, Zugriffskontrolle, Angriffserkennung und Notfallmanagement.
• Meldepflichten bei erheblichen Sicherheitsvorfällen mit klaren Fristen gegenüber den zuständigen Behörden.
• Verantwortung für die Sicherheit in der Lieferkette, insbesondere gegenüber Cloud-Anbietern.
• Regelmäßige Schulungen und Bewusstseinsbildung für Mitarbeitende und Führungskräfte.

Für uns ist entscheidend, dass diese Pflichten nicht als bürokratische Last missverstanden werden. Sie sind der regulatorische Ausdruck dessen, was ohnehin gute Praxis ist. Wer Cloud-Sicherheit ernst nimmt, erfüllt einen Großteil der NISG-Anforderungen fast automatisch. Wer sie nur auf dem Papier erfüllt, wird spätestens im Ernstfall erkennen, dass Compliance allein nicht schützt.

Von der Compliance zur Resilienz: Warum reine Checklisten nicht reichen

Wir erleben in vielen Organisationen ein Muster, das uns Sorge bereitet: Sicherheit wird als Projekt verstanden, das man abschließt. Einmal im Jahr wird ein Audit durchgeführt, ein Bericht erstellt, eine Checkliste abgehakt. Danach kehrt der Alltag zurück, und das Thema verschwindet von der Agenda, bis der nächste Prüftermin naht. Dieses Vorgehen mag regulatorische Anforderungen erfüllen, doch es schafft keine Resilienz.

Resilienz bedeutet, dass eine Organisation auch dann handlungsfähig bleibt, wenn etwas schiefgeht. Sie bedeutet, dass Angriffe erkannt werden, bevor Schaden entsteht, dass Systeme rasch wiederhergestellt werden können und dass Menschen wissen, was im Ernstfall zu tun ist. Resilienz ist kein Zustand, den man erreicht, sondern eine Fähigkeit, die man kontinuierlich weiterentwickelt. Genau deshalb betrachten wir Cloud-Sicherheit als laufenden Prozess und nicht als einmalige Maßnahme.

Für österreichische Betreiber kritischer Infrastruktur heißt das: Es reicht nicht, die NISG-Vorgaben zu erfüllen. Es geht darum, eine Sicherheitskultur zu etablieren, die im Alltag gelebt wird. Dazu gehören technische Werkzeuge ebenso wie geschulte Menschen und klare Verantwortlichkeiten. In den folgenden Abschnitten zeigen wir, wie wir diese Kultur mit unseren Kunden aufbauen.

Anomalieerkennung als Frühwarnsystem für Cloud-Infrastrukturen

Stellen Sie sich vor, ein Angreifer verschafft sich Zugang zu einem Cloud-Konto eines Energieversorgers. Er bewegt sich vorsichtig, nutzt gültige Zugangsdaten, verhält sich beinahe wie ein normaler Benutzer. Klassische Sicherheitssysteme, die auf bekannten Signaturen basieren, erkennen ihn nicht. Genau hier kommt Anomalieerkennung ins Spiel. Sie sucht nicht nach bekannten Mustern, sondern nach Abweichungen vom Normalverhalten. Und sie erkennt einen Angriff oft, bevor Schaden entsteht.

Für uns ist Anomalieerkennung das Herzstück moderner Cloud-Sicherheit. Sie verwandelt eine passive Verteidigung in ein aktives Frühwarnsystem. Statt darauf zu warten, dass ein Vorfall gemeldet wird, erkennen wir ihn, während er sich entfaltet. Das macht den entscheidenden Unterschied zwischen einem kontrollierten Zwischenfall und einer Katastrophe.

Wie Anomalieerkennung in der Cloud funktioniert

Moderne Anomalieerkennung basiert auf KI und Machine Learning. Das Prinzip ist einfach, die Umsetzung anspruchsvoll. Zunächst wird ein Modell des Normalverhaltens erlernt. Es erfasst, welche Benutzer wann auf welche Ressourcen zugreifen, welche Datenmengen üblich sind, welche Netzwerkverbindungen typisch sind und welche Prozesse regelmäßig ablaufen. Aus diesen Beobachtungen entsteht ein Profil, das den Alltag der Umgebung abbildet.

Sobald dieses Profil steht, wird jede neue Aktivität damit verglichen. Weicht sie deutlich ab, entsteht ein Alarm. Ein Benutzer, der plötzlich um drei Uhr früh große Datenmengen aus einer Datenbank abzieht, ist eine Anomalie. Ein Cloud-Dienst, der unerwartet Verbindungen zu einem unbekannten Server im Ausland aufbaut, ist eine Anomalie. Ein Dienstkonto, das plötzlich administrative Rechte nutzt, ist eine Anomalie. Je mehr Kontext das System hat, desto präziser werden diese Alarme.

In der Praxis kombinieren wir mehrere Verfahren. Verhaltensbasierte Erkennung für Benutzer und Dienste, statistische Verfahren für Netzwerkverkehr und regelbasierte Erkennung für bekannte Gefahren. Erst diese Kombination liefert jene Treffsicherheit, die im Betrieb wirklich hilft. Reine KI ohne Regeln erzeugt zu viele Fehlalarme, reine Regeln ohne KI übersehen zu viel. Die Kunst liegt in der Balance.

Werkzeuge und Plattformen: Microsoft Sentinel, Splunk, Elastic Security

Bei der Auswahl der Werkzeuge orientieren wir uns an den Anforderungen unserer Kunden und an der Frage, welche Plattform sich in die bestehende Landschaft sinnvoll integriert. Drei Werkzeuge begegnen uns in Projekten besonders häufig.

• Microsoft Sentinel ist eine cloudnative SIEM-Lösung, die sich nahtlos in Azure- und Microsoft-365-Umgebungen einfügt. Sie bietet integrierte Anomalieerkennung, automatisierte Reaktion und umfangreiche Konnektoren für hybride Umgebungen.
• Splunk ist eine etablierte Plattform für Sicherheitsanalyse und Betriebsdaten. Sie eignet sich besonders für Organisationen, die große Mengen heterogener Daten aus unterschiedlichen Quellen korrelieren wollen.
• Elastic Security kombiniert Suche, Analyse und Endpoint-Sicherheit in einer offenen Plattform. Sie ist attraktiv für Teams, die Wert auf Flexibilität und Kostentransparenz legen.

Wichtig ist uns: Das Werkzeug allein macht keine Sicherheit. Entscheidend sind die Datenqualität, die abgestimmten Regeln und die Menschen, die Alarme bewerten. Deshalb begleiten wir unsere Kunden nicht nur bei der Auswahl, sondern vor allem beim Betrieb.

Herausforderungen: False Positives und Alarmmüdigkeit

Eine der größten Herausforderungen in der Anomalieerkennung ist die schiere Menge an Alarmen. Wer täglich hunderte Warnungen erhält, von denen die meisten harmlos sind, entwickelt eine gefährliche Gleichgültigkeit. Diese sogenannte Alarmmüdigkeit führt dazu, dass echte Vorfälle übersehen werden. Wir haben Umgebungen gesehen, in denen das Sicherheitsteam Alarme schlicht ignorierte, weil die Flut nicht mehr zu bewältigen war.

Um das zu verhindern, setzen wir auf mehrere Maßnahmen. Erstens kalibrieren wir die Erkennung kontinuierlich, sodass sie sich an die reale Umgebung anpasst. Zweitens priorisieren wir Alarme nach Risiko, sodass kritische Ereignisse sofort sichtbar werden. Drittens automatisieren wir Routineprüfungen, damit sich das Team auf die wirklich relevanten Fälle konzentrieren kann. Und viertens schulen wir die Mitarbeitenden darin, Alarme richtig zu interpretieren.

Wir sagen unseren Kunden oft: Ein gutes Frühwarnsystem erkennt man nicht daran, dass es viele Alarme produziert, sondern daran, dass die wenigen Alarme, die es produziert, relevant sind. Diese Qualität ist wichtiger als jede Menge an Funktionen.

Integration in bestehende SOC-Prozesse in Österreich

Viele österreichische Betreiber kritischer Infrastruktur betreiben bereits ein Security Operations Center oder arbeiten mit einem externen Dienstleister zusammen. Unsere Aufgabe ist es dann, Anomalieerkennung in diese bestehenden Prozesse zu integrieren, statt sie daneben zu stellen. Das gelingt nur, wenn Technik, Prozesse und Menschen zusammen gedacht werden.

Konkret bedeutet das: Wir definieren gemeinsam, welche Alarme welche Reaktion auslösen, wer welche Entscheidungen treffen darf und wie Vorfälle dokumentiert und gemeldet werden. Wir stellen sicher, dass die Anomalieerkennung mit den bestehenden Ticketsystemen, Kommunikationswegen und Eskalationsstufen harmoniert. Und wir sorgen dafür, dass die gesetzlichen Meldepflichten aus dem NISG 2024 im Prozess abgebildet sind, sodass im Ernstfall keine wertvolle Zeit verloren geht.

Ein Praxisbeispiel aus einem österreichischen Rechenzentrum zeigt die Wirkung. Dort führte die Einführung verhaltensbasierter Anomalieerkennung dazu, dass ein kompromittiertes Dienstkonto innerhalb weniger Minuten erkannt wurde. Der Angreifer hatte versucht, über eine legitime API Zugriff auf sensible Daten zu erlangen. Klassische Signaturen hätten ihn nicht erfasst. Die Anomalieerkennung alarmierte, weil das Dienstkonto plötzlich auf Ressourcen zugriff, die es nie zuvor genutzt hatte. Der Zugriff wurde automatisch unterbrochen, bevor Daten abfließen konnten.

Resilienz und Betriebssicherheit: Cloud-Architekturen für den Ernstfall

Sicherheit bedeutet nicht nur, Angriffe abzuwehren. Sie bedeutet auch, im Fall des Falles handlungsfähig zu bleiben. Resilienz ist die Fähigkeit, Störungen zu absorbieren, sich anzupassen und den Betrieb rasch wiederherzustellen. Für kritische Infrastruktur ist sie keine Kür, sondern Pflicht. Wir gestalten Cloud-Architekturen so, dass sie nicht nur im Normalbetrieb funktionieren, sondern auch dann, wenn etwas schiefgeht.

Dabei denken wir in Szenarien. Was passiert, wenn ein Rechenzentrum ausfällt? Was, wenn ein Cloud-Anbieter Probleme hat? Was, wenn ein Angriff Teile der Umgebung lahmlegt? Auf jede dieser Fragen braucht es eine Antwort, die vor dem Ernstfall entwickelt und getestet wurde. Resilienz entsteht nicht im Krisenmodus, sondern in der Vorbereitung.

Multi-Cloud und Hybrid-Cloud: Risiken verteilen

Eine bewährte Strategie zur Steigerung der Resilienz ist die Verteilung von Risiken über mehrere Umgebungen. Multi-Cloud bedeutet, dass Dienste auf mehreren Cloud-Anbietern betrieben werden. Hybrid-Cloud kombiniert öffentliche Cloud mit lokaler Infrastruktur. Beide Ansätze verfolgen dasselbe Ziel: die Abhängigkeit von einem einzigen Anbieter oder Standort zu reduzieren.

Wir raten unseren Kunden, diese Strategien bewusst und selektiv einzusetzen. Nicht jede Anwendung muss über mehrere Wolken verteilt werden. Aber jene Dienste, deren Ausfall kritisch wäre, sollten so gestaltet sein, dass ein Ausfall eines Anbieters nicht zum Totalausfall führt. Dazu gehören klare Architekturentscheidungen, standardisierte Schnittstellen und automatisierte Bereitstellungsprozesse.

Gleichzeitig warnen wir vor übertriebener Komplexität. Wer zu viele Umgebungen parallel betreibt, ohne sie zu beherrschen, schafft neue Risiken. Multi-Cloud ist kein Selbstzweck, sondern ein Werkzeug. Es muss zur Organisation, zur Bedrohungslage und zu den regulatorischen Anforderungen passen.

Georedundanz in Österreich: Rechenzentren in Wien, Linz und Graz

Georedundanz bedeutet, dass Daten und Dienste an mehreren geografisch getrennten Standorten vorgehalten werden. Fällt ein Standort aus, übernimmt ein anderer. Für österreichische Betreiber kritischer Infrastruktur ist das besonders relevant, weil sie einerseits hohe Verfügbarkeitsanforderungen erfüllen müssen und andererseits Wert auf Datenhaltung im eigenen Land legen.

Österreich bietet dafür gute Voraussetzungen. Rechenzentren in Wien, Linz und Graz ermöglichen es, georedundante Architekturen innerhalb des Landes aufzubauen. Wien als größter Standort bietet breite Konnektivität und eine hohe Dichte an Anbietern. Linz punktet mit industrieller Nähe und starker Anbindung an produzierende Betriebe. Graz ergänzt das Bild mit einer geografisch südlichen Position und einer lebendigen Technologie- und Forschungsszene.

Wir helfen unseren Kunden, Standorte so zu kombinieren, dass geografische Risiken gestreut werden, ohne die Latenz oder die rechtlichen Anforderungen zu verletzen. Dabei berücksichtigen wir nicht nur die geografische Distanz, sondern auch die Unabhängigkeit der Stromversorgung, der Netzwerkanbindung und des Betriebspersonals. Echte Georedundanz endet nicht bei der Adresse.

Notfall- und Wiederherstellungspläne nach ISO 22301

Resilienz braucht einen Plan. Der internationale Standard ISO 22301 für Business Continuity Management bietet dafür einen bewährten Rahmen. Er beschreibt, wie Organisationen ihre kritischen Prozesse identifizieren, Risiken bewerten und Maßnahmen entwickeln, um im Störfall handlungsfähig zu bleiben. Für Betreiber kritischer Infrastruktur ist ISO 22301 eine hervorragende Grundlage, um die Anforderungen des NISG 2024 mit Leben zu füllen.

In Projekten gehen wir typischerweise in mehreren Schritten vor. Zuerst identifizieren wir die kritischen Dienste und ihre Abhängigkeiten – von der Anwendung über die Daten bis zur Infrastruktur. Dann bewerten wir die Auswirkungen eines Ausfalls und leiten daraus Schutzziele ab. Anschließend entwickeln wir Notfallpläne, definieren Verantwortlichkeiten und üben die Abläufe regelmäßig. Denn ein Plan, der nie getestet wurde, ist im Ernstfall wenig wert.

Wir legen großen Wert darauf, dass diese Pläne nicht in einem Ordner verstauben, sondern Teil der täglichen Arbeit werden. Dazu gehören klare Kommunikationswege, regelmäßige Übungen und eine Kultur, in der Fehler offen angesprochen werden. Nur so entsteht echte Widerstandsfähigkeit.

RTO und RPO: Was kritische Dienste wirklich brauchen

Zwei Kennzahlen sind in der Resilienzplanung besonders wichtig: Recovery Time Objective (RTO) und Recovery Point Objective (RPO). Der RTO beschreibt, wie lange ein Dienst nach einem Ausfall höchstens nicht verfügbar sein darf. Der RPO beschreibt, wie viel Datenverlust maximal akzeptabel ist – gemessen in Zeit.

Für kritische Dienste sind diese Werte oft sehr streng. Ein Leitsystem für den Bahnverkehr kann einen RTO von wenigen Minuten haben. Ein Abrechnungssystem für Energieversorger kann einen RPO von wenigen Sekunden erfordern. Solche Anforderungen haben unmittelbare Auswirkungen auf die Architektur, die Kosten und die Betriebsprozesse.

Wir helfen unseren Kunden, realistische und zugleich anspruchsvolle RTO- und RPO-Werte zu definieren. Dabei geht es nicht darum, jeden Dienst maximal abzusichern, sondern die richtige Balance zwischen Schutzbedarf und Wirtschaftlichkeit zu finden. Ein Dienst, der einen RTO von 24 Stunden akzeptiert, braucht eine andere Architektur als einer mit einem RTO von fünf Minuten. Wer diese Unterschiede kennt, kann Ressourcen gezielt einsetzen.

NIS2 in der Praxis: Was österreichische Betreiber jetzt umsetzen müssen

Die NIS2-Richtlinie und ihre österreichische Umsetzung im NISG 2024 sind keine abstrakten Vorgaben aus Brüssel. Sie betreffen konkrete Organisationen, konkrete Prozesse und konkrete Fristen. In unseren Projekten erleben wir, dass viele Betreiber die grundsätzliche Richtung verstehen, aber unsicher sind, was wann zu tun ist. Wir fassen deshalb die wichtigsten Pflichten zusammen und zeigen, wie wir sie in der Praxis umsetzen.

Risikomanagement und technische Maßnahmen nach NIS2

Das Herzstück der NIS2-Anforderungen ist ein umfassendes Risikomanagement. Betreiber müssen Risiken für ihre IT- und Netzwerksysteme systematisch erfassen, bewerten und behandeln. Das umfasst nicht nur die eigene Infrastruktur, sondern auch Cloud-Dienste und Lieferanten. Die Maßnahmen müssen verhältnismäßig sein – also dem Risiko und der Bedeutung des Dienstes entsprechen.

Zu den geforderten technischen Maßnahmen gehören unter anderem:

• Verschlüsselung von Daten in Übertragung und Speicherung.
• Zugriffskontrolle mit dem Prinzip der minimalen Berechtigung.
• Kontinuierliche Überwachung und Angriffserkennung.
• Notfall- und Wiederherstellungsmanagement.
• Sichere Konfiguration und Schwachstellenmanagement.

Wir begleiten unsere Kunden dabei, diese Maßnahmen nicht isoliert, sondern als zusammenhängendes System zu implementieren. Denn erst im Zusammenspiel entfalten sie ihre Wirkung.

Meldepflichten: Fristen und Ablauf in Österreich

Ein zentraler Punkt der NIS2-Richtlinie sind die Meldepflichten bei erheblichen Sicherheitsvorfällen. In Österreich sind diese Pflichten im NISG 2024 geregelt. Betroffene Organisationen müssen Vorfälle innerhalb klar definierter Fristen an die zuständigen Behörden melden. Zu den zuständigen Stellen zählen unter anderem das Bundesministerium für Inneres (BMI) und das Bundeskanzleramt (BKA), je nach Sektor und Zuständigkeit.

Die Fristen sind bewusst kurz gewählt, um schnelle Reaktionen zu ermöglichen. In der Praxis bedeutet das, dass Organisationen ihre internen Abläufe so gestalten müssen, dass sie innerhalb weniger Stunden eine Erstmeldung abgeben können. Das erfordert vorbereitete Prozesse, klare Verantwortlichkeiten und eine funktionierende interne Kommunikation.

Wir unterstützen unsere Kunden dabei, Meldeprozesse zu etablieren, die im Ernstfall tatsächlich funktionieren. Dazu gehören Vorlagen, Eskalationswege und regelmäßige Übungen. Denn in der Krise zählt jede Minute, und wer dann erst zu überlegen beginnt, verliert wertvolle Zeit.

Lieferkettensicherheit: Anforderungen an Cloud-Anbieter

Die NIS2-Richtlinie macht deutlich, dass Sicherheit nicht an der eigenen Unternehmensgrenze endet. Betreiber kritischer Infrastruktur sind verantwortlich für die Sicherheit in ihrer Lieferkette – und das schließt Cloud-Anbieter ausdrücklich ein. Das bedeutet, dass Verträge, Garantien und technische Anforderungen an Dienstleister klar definiert und überprüfbar sein müssen.

Wir helfen unseren Kunden, Cloud-Anbieter systematisch zu bewerten. Dazu gehören Fragen wie: Wo werden Daten gespeichert und verarbeitet? Welche Zertifizierungen liegen vor? Wie werden Sicherheitsvorfälle gemeldet? Welche Rechte hat der Betreiber im Fall einer Kündigung? Welche Transparenz gibt es über Subunternehmer?

Unsere Erfahrung zeigt, dass viele Organisationen diese Fragen erst dann stellen, wenn ein Vorfall eingetreten ist. Das ist zu spät. Lieferkettensicherheit muss vor dem Vertragsabschluss beginnen und während der gesamten Laufzeit überprüft werden.

Schulungen und Bewusstseinsbildung für Mitarbeitende

Technik allein schützt nicht. Ein großer Teil erfolgreicher Angriffe beginnt mit menschlichem Fehlverhalten – einem Klick auf einen manipulierten Link, einer schwachen Passphrase, einem unbedachten Umgang mit Zugangsdaten. Deshalb fordert NIS2 ausdrücklich regelmäßige Schulungen und Bewusstseinsbildung.

Wir entwickeln für unsere Kunden Schulungsprogramme, die auf ihre konkrete Umgebung zugeschnitten sind. Statt allgemeiner Vorträge setzen wir auf praxisnahe Szenarien, konkrete Beispiele und wiederkehrende Übungen. Wir schulen nicht nur die IT-Abteilung, sondern auch Führungskräfte, Betriebspersonal und externe Dienstleister.

Besonders wichtig ist uns eine Kultur, in der Sicherheit nicht als Hindernis, sondern als gemeinsame Verantwortung verstanden wird. Wer versteht, warum eine Maßnahme sinnvoll ist, hält sich eher daran. Wer nur Regeln befolgt, weil sie vorgeschrieben sind, wird sie im entscheidenden Moment vergessen.

Unser Ansatz: SECCRIT als Begleiter für sichere Cloud-Transformation

Wir haben SECCRIT gegründet, weil wir überzeugt sind, dass kritische Infrastruktur und Cloud zusammengehören – aber nur, wenn Sicherheit von Anfang an mitgedacht wird. Unser Ansatz ist es, österreichische Betreiber kritischer Infrastruktur auf ihrem gesamten Weg zu begleiten: von der ersten Analyse über die Implementierung bis zum laufenden Betrieb. Wir verstehen uns nicht als Zulieferer, sondern als Partner.

Unsere Erfahrung umfasst Projekte mit Behörden, Energieversorgern und Gesundheitsdiensten. Wir kennen die spezifischen Anforderungen dieser Umgebungen, die regulatorischen Rahmenbedingungen und die praktischen Herausforderungen des Alltags. Diese Erfahrung bringen wir in jedes Projekt ein – und wir lernen mit jedem Kunden dazu.

Analyse und Reifegradbewertung: Wo steht Ihre Cloud-Sicherheit?

Am Anfang steht immer die Frage: Wo stehen Sie heute? Wir führen eine strukturierte Analyse Ihrer Cloud-Landschaft durch. Wir erfassen, welche Dienste in welcher Cloud laufen, welche Daten verarbeitet werden, welche Abhängigkeiten bestehen und welche Sicherheitsmaßnahmen bereits implementiert sind. Auf dieser Basis erstellen wir eine Reifegradbewertung, die Stärken und Lücken sichtbar macht.

Diese Bewertung ist kein Selbstzweck. Sie bildet die Grundlage für alle weiteren Schritte und ermöglicht es, Ressourcen gezielt einzusetzen. Wir priorisieren Maßnahmen nach Risiko und Wirkung, sodass Sie dort ansetzen, wo der größte Nutzen entsteht.

Implementierung: Anomalieerkennung, Resilienz und NIS2-Compliance

Auf Basis der Analyse begleiten wir die Umsetzung. Das kann die Einführung einer Anomalieerkennung mit Werkzeugen wie Microsoft Sentinel, Splunk oder Elastic Security umfassen. Es kann die Neugestaltung von Architekturen für Georedundanz über Rechenzentren in Wien, Linz und Graz bedeuten. Und es kann die Anpassung von Prozessen und Verträgen zur Erfüllung der NISG-2024-Anforderungen beinhalten.

Wir arbeiten dabei eng mit Ihren Teams zusammen. Wir liefern nicht einfach Konzepte, sondern setzen mit Ihnen gemeinsam um. Das stellt sicher, dass die Lösungen zu Ihrer Organisation passen und im Alltag funktionieren.

Betrieb und Monitoring: Laufende Sicherheit statt Einmalprojekt

Sicherheit endet nicht mit der Implementierung. Sie beginnt dort erst richtig. Wir unterstützen unsere Kunden im laufenden Betrieb, überwachen die Umgebung, kalibrieren die Erkennung und reagieren auf Vorfälle. Dabei arbeiten wir entweder als Teil Ihres Teams oder als externer Partner, je nach Bedarf.

Unser Ziel ist es, dass Sie nicht nur im Audit gut aussehen, sondern im Ernstfall bestehen. Das erreichen wir durch kontinuierliche Verbesserung, regelmäßige Übungen und eine offene Kommunikation über Risiken und Vorfälle.

Schulung und Wissenstransfer für österreichische Teams

Wir sind überzeugt, dass Wissen geteilt werden muss. Deshalb legen wir großen Wert auf Schulung und Wissenstransfer. Wir bilden Ihre Teams darin aus, Alarme zu bewerten, Vorfälle zu behandeln und Sicherheitsmaßnahmen im Alltag zu leben. Wir stellen sicher, dass Sie nicht dauerhaft von uns abhängig sind, sondern selbst handlungsfähig werden.

Dieser Ansatz hat sich bewährt. Viele unserer Kunden übernehmen nach einer gemeinsamen Anfangsphase die Betriebsverantwortung selbst – mit unserer Unterstützung im Hintergrund, wenn sie gebraucht wird. So entsteht nachhaltige Sicherheit.

Wenn Sie wissen möchten, wo Ihre Cloud-Sicherheit heute steht und welche Schritte als Nächstes sinnvoll sind, laden wir Sie herzlich ein, mit uns zu sprechen. Wir analysieren Ihre Situation, zeigen Ihnen konkrete Handlungsoptionen und begleiten Sie auf dem Weg zu einer sicheren, resilienten und NIS2-konformen Cloud. Kontaktieren Sie uns noch heute – wir freuen uns auf das Gespräch.

Häufig gestellte Fragen (FAQ)

Was bedeutet NISG 2024 konkret für österreichische Cloud-Nutzer?

Das NISG 2024 setzt die NIS2-Richtlinie in österreichisches Recht um und verpflichtet Betreiber kritischer Infrastruktur zu umfassendem Risikomanagement, technischen Sicherheitsmaßnahmen, Meldepflichten bei erheblichen Vorfällen, Lieferkettensicherheit und regelmäßigen Schulungen. Auch Cloud-Dienste und deren Anbieter fallen ausdrücklich in den Geltungsbereich. Betreiber müssen nachweisen können, dass sie ihre Cloud-Umgebung angemessen schützen und Vorfälle fristgerecht melden.

Wie schnell muss ich einen Sicherheitsvorfall in Österreich melden?

Die genauen Fristen ergeben sich aus dem NISG 2024 und den Vorgaben der NIS2-Richtlinie. In der Praxis müssen erhebliche Vorfälle innerhalb weniger Stunden erstmals gem

Neueste Artikel

• 
  Sicherheitsrichtlinien technisch durchsetzen
  Sicherheitsrichtlinien technisch durchsetzen: Von der Policy zur gelebten Cloud-Sicherheit Es ist eine der frustrierendsten Realitäten in vielen österreichischen Unternehmen: Die Sicherheitsrichtlinie liegt… 
• 
  Risikoanalyse für Cloud-Migrationen
  Risikoanalyse für Cloud-Migrationen: Wie wir kritische Infrastruktur in Österreich absichern Wer die Stromversorgung für hunderttausende Haushalte oder die Patientenaufnahme im AKH Wien… 
• 
  Resilienz von Cloud-Diensten bewerten
  Resilienz von Cloud-Diensten bewerten: Unser praktischer Leitfaden Wir beginnen mit einer Frage, die in österreichischen Unternehmen und Behörden längst keine reine IT-Agenden-Frage… 
• 
  Rechtliche Fragen bei Cloud-Ausfällen
  Rechtliche Fragen bei Cloud-Ausfällen: Wer haftet, wenn die Cloud streikt? Stellen Sie sich vor, ein Cloud-Ausfall legt das Stromnetz oder das Krankenhaus-IT-System… 
• 
  NIS2 in Österreich: was Betreiber wissen müssen
  NIS2 in Österreich: Was Betreiber kritischer Infrastruktur jetzt wissen müssen Warum ist die NIS2-Richtlinie für österreichische Betreiber kritischer Infrastruktur kein reines IT-Thema,… 
• 
  Multi-Cloud und Ausfallsicherheit
  Multi-Cloud und Ausfallsicherheit: Wie wir kritische Infrastruktur in Österreich wirklich resilient machen Multi-Cloud ist in aller Munde – und trotzdem garantieren zwei…