IT-Sicherheitsgesetz [Teil 2]

Im letzten Artikel schrieb ich darüber, was das IT-Sicherheitsgesetz ist und wer betroffen ist. Nun möchte ich mich den eigentlichen Anforderungen zuwenden, bzw. welche Konsequenzen drohen, wenn diese nicht umgesetzt werden.

Ich habe ja nun schon öfter diese ominösen "Mindeststandards" erwähnt bzw. diese Lieblingsphrase der Juristen, wenn es um Technik geht ("Stand der Technik"). Das heißt so erstmal Alles und Nichts. Insbesondere zu den Mindeststandards heißt es dann weiter (§ 8a Abs. 2 BSIG):

"Betreiber Kritischer Infrastrukturen und ihre Branchenverbände können branchenspezifische Sicherheitsstandards zur Gewährleistung der Anforderungen nach Absatz 1 vorschlagen. Das Bundesamt stellt auf Antrag fest, ob diese geeignet sind, die Anforderungen nach Absatz 1 zu gewährleisten."

Also wir stellen fest: Dazu gibt es derzeit nichts Konkretes und da wir keine klaren Regeln haben, müssen wir auch erstmal nichts machen. Aber ist das wirklich so?

Hier könnte man auch mal auf den Status Quo schauen, wo es durchaus diverse Standards und Good Practices gibt, beispielsweise ISO/IEC 27001 oder auch das vom BSI selbst herausgegebene IT-Grundschutzhandbuch. Das ist alles keine Rocket Science und die grundlegenden Prinzipien guter Praktiken beim Risikomanagement der Informationssicherheit werden sich auch durch fortschreitende technische Entwicklung nicht wesentlich ändern. Denn dies - und das wundert niemanden, der sich an der Front schon tatsächlich mit so etwas mal beschäftigen musste - ist eigentlich nicht wirklich ein technisches Problem, sondern geht im Kern um menschliches Handeln, die tagtäglichen kleinen und großen Entscheidungen und um die Incentivierung von erwartetem Verhalten.

"Ja, aber was ist mit Firewalls und Antivirus?", schallt es da wieder aus dem Publikum mit gefährlichem Halbwissen, "das ist doch Technik! Und davon verstehe ich nichts."

Also mal davon abgesehen, dass das mal wieder schöne Beispiele für Security-Theater sind, ist doch auch die Tatsache, ob und auf welche Art und Weise solche Security-Technologien verbaut sind, im Kern eine menschliche Entscheidung der jeweils Verantwortlichen, die sich in einer kontinuierlichen Gemengelage von konkurrierenden und sich häufig gegenseitig ausschließenden Zielen und Verpflichtungen befinden ("das Projekt soll schnell, günstig und in guter Qualität geliefert werden).

Die Krux, Herausforderung und Kunst liegt bei einem Thema wie dem unseren, diese richtige und optimale Balance zwischen den verschiedenen Zwängen zu finden und herzustellen.

Es gibt zunächst eine zweijährige Übergangsfrist, bis zu der man das als betroffene Organisation erreichen und nachweisen muss. Danach darf man die Übung dann auch regelmäßig alle zwei Jahre wiederholen. Dies entspricht eigentlich nur einer Festschreibung längst üblicher guter Praktiken (beispielsweise ISO/IEC 27001 Zertifizierung).

Ein Hinweis noch für Telemedienanbieter: Neben der nun erweiterten rechtlichen Risiken bei Data Breaches und DoS-Attacken, gab es auch einige Kommentare während der Entwurfsphase des Gesetzes, dass auch insbesondere solche Fälle damit gemeint sind, in denen eine Web-Seite kompromittiert wird und anschließend über diesen Weg Schadsoftware an alle Nutzer verbreitet wird ("Drive-By-Download" Angriff). Bedenken Sie hier auch, wie viele Bausteine Sie von Drittanbietern auf Ihren Webseiten eingebunden haben (beispielsweise Werbebanner, Tracking Code), für die Sie aber jetzt auch verantwortlich gemacht werden können.

Kontakt- und Meldepflichten

Meldepflichten zu Sicherheitsvorfällen gibt es im Datenschutzbereich bereits seit einigen Jahren im BDSG (§ 42a) und TKG (§ 109a). Diese werden nun neben den Vorfällen mit personenbezogenen Daten erweitert um weitere Meldepflichten an das BSI bzw. die BNetzA bei weiteren Sicherheitsvorfällen mit Beeinträchtigungen von Verfügbarkeit und Integrität, ein an sich konsequenter Schritt, da Sicherheit eben entgegen der landläufigen Meinung nicht nur mit Vertraulichkeit zu tun hat.

Die Schwierigkeit ergibt sich hier jedoch aus der Verpflichtung nicht nur tatsächliche Vorfälle, sondern auch potenzielle zu melden, die zu keinen Beeinträchtigungen geführt haben. Dies wurde etwas abgemildert, so dass Letztere anonym gemeldet werden können.

Wenn man das jetzt mal ins logische Extrem weiter denkt, müsste man da am besten gleich einen automatisierten Alert-Feed aus dem eigenen SIEM zum BSI einrichten.

Das Kommunikationsgebot geht jedoch auch in die umgekehrte Richtung. Die betroffenen Organisationen oder deren Branchenverbände müssen Kontaktstellen einrichten, die 24/7 für das BSI erreichbar sind. Hier möchte ich mal eine Lanze brechen: Wenn jemand eine kritische Infrastruktur betreibt, deren Dienste ich 24/7 nutze und von denen möglicherweise auch mein Überleben abhängt, möchte ich aber bitte auch, dass dieser Betreiber ein 24/7 Security Operations Center hat. Das gehört doch mal wirklich inzwischen zum guten Ton.

Die Mitwirkungspflicht von Produktherstellern habe ich schon erwähnt. Ist dies nun ein erster zaghafter Schritt in die sicherheitsbezogene Produkthaftung? Zur Sinnhaftigkeit einer solchen gibt es naturgemäß unterschiedliche Meinungen, aber es bleibt eine unbestreitbare Tatsache, dass es sich beim derzeitigen Zustand, um eine ökonomische Externalität handelt: Die Hersteller müssen die Konsequenzen ihrer Entscheidungen nicht tragen und entscheiden daher selbstverständlich anders, als wenn sie es tun müssten.

Eine interessante Neuerung für Telekommunikationsanbieter, die wirklich das Zeug dazu hat, die Welt zu einem besseren Ort zu machen: Wenn diese Kenntnisse von Sicherheitsproblemen bei ihren Kunden erlangen (beispielsweise Network Intrusion Detection Alerts, die auf Botnet-Traffic hinweisen beziehungsweise Kommunikation mit bekannten Bad-IP-Adressen), so sind sie verpflichtet, diese darüber aufzuklären und dabei zu helfen, wie die Betroffenen sich wieder säubern können.

Dies passiert zum Teil auch schon jetzt in der Praxis, jedoch noch viel zu wenig. Und den Kampf gegen die Botnetz-Plage am Endpunkt muss man eigentlich als verloren ansehen. Bei Organisationen mit höherem Security-Monitoring- und -Detection Reifegrad hat sich schon seit einer Weile bewährt, fortgeschrittene Malware durch Sandbox-Simulationen (beispielsweise Fireeye oder Palo Alto Wildfire) und Kommunikationsverbindungen zu vermuteten Command & Control Servern zu identifizieren (dazu gibt es auch div. Threat Intelligence Services oder auch Monitoring von Botnetz Traffic durch Einschmuggeln in das Botnetz-interne C&C Netz). Es wird Zeit, dass diese Verfahren auch für den gemeinen Endbenutzer zum Einsatz kommen und endlich, endlich die alte Legende von der Effektivität von klassischem "Anti-Virus" begraben wird.

Welche Konsequenzen hat es, wenn ich das nicht tue?

Echte "Zähne" hat ein Gesetz erst, wenn die Nichtbefolgung mit bußgeldbewehrten Ordnungswidrigkeiten (OWi) oder strafrechtlich geahndet wird.

Strafrechtlich kommt nun durch das IT-Sicherheitsgesetz nichts Neues hinzu – aber doch diverse OWis im Bereich 50.000 EUR:

• Bei Nichtbeachtung der Mindeststandards;
• Nicht-Übertragung der gesamten Audit Ergebnisse wenn Sicherheitsmängel gefunden wurden;
• 24/7 Kontaktstelle nicht rechtzeitig genannt;
• nicht ausreichende Meldung von Sicherheitsvorfällen (gar nicht, unrichtig, unvollständig, zu spät). Dabei ist anzumerken, dass im TKG bereits jetzt Bußgelder von 100.000 EUR bei unzureichenden Meldungen von Data Breaches verhängt werden können. Im BDSG sogar 300.000 EUR in bestimmten Fällen.
• Unzureichende TOMs bei Telemedienanbietern (zur Erinnerung: das ist jetzt der Unterschied zum bisherigen TMG und BDSG: Da gab es nämlich keine OWi für die TOMs);
• Unzureichende Meldung bei Telekommunikationsanbietern: 50.000 EUR (galt vorher schon: Sicherheitskonzept nicht rechtzeitig vorgelegt oder Meldung bei Datenschutzvorfällen: 100.000 EUR);

Daneben gibt es auch OWis mit 100.000 EUR Bußgeld, wenn das BSI zur Beseitigung von spezifischen Sicherheitsmängeln auffordert und dem nicht Folge geleistet wird. Interessanterweise konnte ich jedoch in den Ergänzungen des Atom- und Energiewirtschafts-Gesetzes keine neuen OWis finden. War da etwa die Lobby stärker als in anderen Branchen?

Lesen Sie im dritten Teil dieser Serie, was das IT-Sicherheitsgesetz meiner Ansicht nach zunächst erreichen wird und was nicht. Außerdem möchte ich Ihnen ein paar pragmatische Tipps geben, was Sie jetzt schon tun können ohne auf die weiteren Rechtsverordnungen zu warten.

Autor:

Stefan Sulistyo, Co-Founder & CCO of Alyne, 10+ year InfoSec & GRC veteran.

IT-Sicherheitsgesetz [Teil 1]: Kritische Infrastrukturen sicher machen