IT-Sicherheit ist kein Bürostuhl

Der Bund hat am 17. Juli 2023 einen Brief an seine Informatikdienstleister verschickt. Die Forderungen reichen von selbstverständlich bis fragwürdig. Wir haben sie aus IT-Sicherheitssicht analysiert und mit Hinweisen für alle IT-Verantwortlichen versehen, egal ob öffentliche Hand oder Privatwirtschaft.

IT-Sicherheit geht alle an

Die allermeisten heutigen Unternehmen sind von einer funktionierenden Informatikinfrastruktur abhängig. Manche sind sich das sehr bewusst; andere merken es erst, wenn Teile ihrer IT crasht, gehackt wurde, Geschäfts- und Personaldaten im Darknet auftauchen oder wenn ein Wassereinbruch bzw. Feuer die Rechner und Festplatten zerstört hat.

Deshalb vorweg ein paar grundlegende Punkte zur IT-Sicherheit:

1. In den meisten Unternehmen sind IT-Infrastruktur, Anwendungen, Daten und Prozesse zu divers, um sie alle über einen Kamm zu scheren. Es braucht immer eine auf die eigenen Geschäftsprozesse bezogene individuelle Risiko- und Bedrohungsanalyse. (Wenn geheime Pläne plötzlich öffentlich werden, ist das ein Desaster; beim Cafeteria-Menüplan gibt es aber im Gegenteil Ärger, wenn dieser plötzlich nicht mehr frei einsehbar ist.) Um die richtigen Entscheide fällen zu können, ist ein Inventar der IT-Infrastruktur, Anwendungen, Daten und Prozesse unabdingbar.
2. Jeder Versuch, ein Unternehmen auf Basis allgemeiner Checklisten sicher zu machen, ist deshalb zum Scheitern verurteilt: Ist die Liste kurz, werden wichtige Punkte übersehen. Ist die Liste lang, ist man genervt, entweder von ihrer Länge oder von Forderungen, die nicht in allen Fällen Sinn machen.
3. Wenn IT-Sicherheit in einem Unternehmen erfolgreich umgesetzt werden soll, müssen alle Beteiligten, insbesondere aber die Führungsetage, voll dahinter stehen und es vorleben. Sonst gehen Checklisten in Vergessenheit und teure Audits verkommen zu Papiertigern. (Auch Hauswart oder Reinigungspersonal sollten nicht vergessen gehen.)
4. IT-Sicherheit ist ein Prozess, kein Ziel, das man am Ende eines Projekts abhaken und schubladisieren kann. Wenn man ernsthaft IT-Sicherheit will, muss man sich regelmässig darum kümmern und kontinuierlich verbessern. Denn die Angreifer machen das auch.
5. IT-Infrastruktur, auf die das Unternehmen angewiesen ist, der man wichtige Daten anvertraut oder die in kritischen Prozessen unverzichtbar ist, darf nicht alleine gelassen werden. Das kann nicht durch Delegation auf einen Dienstleister erledigt werden und ist nicht durch Zahlung eines Wartungsvertrags gelöst; jedes Unternehmen muss selbst im Bild bleiben, was die beauftragten IT-Dienstleister eigentlich machen und ob das mit den eigenen Geschäftszielen und -risiken zusammenpasst. Dazu braucht es auch in-house IT-(Sicherheits-)Kompetenz.
6. Vorbeugen ist das A und O. Trotzdem sollte das “Heilen” (auch bekannt als Business Continuity Management) nicht vergessen gehen. Dazu gehören Pläne, wie man bei einem Server- oder Netzwerkausfall, nach einem Ransomwareangriff, einem verlorenen USB-Stick mit sensiblen Inhalten, dem Defekt einer Festplatte oder auch dem Ausfall/Konkurs eines Cloud-Dienstleisters umgehen will. (Diese Pläne helfen frühzeitig Probleme aufzuzeigen. Sie helfen auch, im Ereignisfall Ruhe zu bewahren, auch wenn eine Katastrophe nie perfekt vorbereitet werden kann.)

Kurz: Die Beschaffung und der Betrieb von IT-Lösungen—insbesondere, wenn diese nicht von der Stange kommen—funktioniert anders als die Beschaffung von Büromaterial oder Möbeln. Vor allem das Zusammenarbeitsmodell ist ein anderes, egal, ob der Auftraggeber Bund oder Privatwirtschaft ist.

Der Brief des BBL

Der Brief des Bundesamtes für Bauten und Logistik stellt eine gute Basis dar. Weniger, um ihn unreflektiert 1:1 umzusetzen, aber sehr wohl als Diskussionsgrundlage, wie man IT-Sicherheit implementieren sollte. Das liegt sicher zu einem Teil an der Komplexität der Materie, an der Kürze des Briefs und der vermutlichen Hektik bei seiner Vorbereitung.

Einleitung

Bevor wir uns den fünf Hauptthemen annehmen, hier ein paar Sätze aus dem einleitenden Fliesstext, die mir besonders ins Auge gesprungen sind:

Sie erhalten das vorliegende Informationsschreiben, da Ihr Unternehmen Informatikdienstleistungen für die Bundesverwaltung erbringt.

Hier ist das erste Indiz, dass der Bund alle seine Dienstleister über einen Kamm schert (Punkt 1 aus der einführenden Liste). Dieser Brief geht an alle. Und das dürfte vermutlich eine riesige Bandbreite abdecken: Ob die Firmen nun Software entwickeln, Hardware liefern, Dienste betreiben, Consulting anbieten oder Handbücher übersetzen.

Wir gehen davon aus, dass Ihr Unternehmen die vertraglichen Pflichten einhält und sich regelmässig über aktuelle Cyberbedrohungen und entsprechende Gegenmassnahmen informiert.

Dieser Satz wirkt so, als ob der Bund sich erst jetzt bewusst geworden ist, dass er seine IT-Dienstleister alleine gelassen hat (Punkt 5). Und das obwohl schon im alten Datenschutzgesetz steht: «Der Auftraggeber muss sich insbesondere vergewissern, dass der Dritte die Datensicherheit gewährleistet» (im nDSG muss man sich nur noch vergewissern, dass der Auftragsbearbeiter dazu «in der Lage ist»).

Die nächsten fünf Untertitel umfassen den gesamten Text der fünf “wichtigen Sicherheitsanforderungen”:

* Zugangs­daten/Authenti­sierung

Eine Multifaktor-Authentisierung auf allen Systemen und Anwendungen ist unverzichtbar.

Auf allen Systemen? Auch auf dem Saugroboter und der vernetzten Kaffeemaschine? Oder etwas näher an der klassischen IT: Wessen Drucker unterstützt 2FA? Wohl keiner.

Grundsätzlich eine frommer, unterstützenswerter Wunsch, aber auch hier zeigt sich, dass man nicht alles in denselben Topf werfen und mit fixen Checklisten abarbeiten kann (Punkte 1 und 2; ich erwähne sie zukünftig nicht mehr).

Ferner dürfen keine Passwörter unverschlüsselt abgelegt werden.

Passwörter sollten möglichst überhaupt nicht abgelegt werden und wenn, dann (auf der Senderseite) gut verschlüsselt oder (zur Überprüfung) sicher gesalzen und gehasht. Noch besser aber wäre die Nutzung von Single-Sign-On-Verfahren bzw. digitalen Signaturen und Zertifikaten, wie sie beispielsweise bei USB-Keys oder neu mit FIDO2 und Passkeys eingesetzt werden.

Aber auch hier ist es bei gewisser Software oder einigen automatisierten Prozessen der gute Wunsch nicht in die Tat umzusetzen. Wenn hinter diesem Passwort keine wichtigen Daten und kein kritischer Prozess stehen, kann dies durchaus eine akzeptable Lösung sein.

Viel wichtiger wäre es, darauf hinzuwirken, dass Passwörter möglichst nicht geteilt werden sollten und deshalb überall entsprechende Rechteverwaltung mit Gruppenberechtigungen oder Delegationsmöglichkeiten vorhanden sein sollten.

* Infor­mations­management

Auf Systemen darf es keine nicht anonymisierten Produktivdaten von Verwaltungseinheiten des Bundes haben.

Auch hier grundsätzlich ein guter Ansatz. Wenn etwas anonymisiert werden kann, dann waren es vorher wahrscheinlich personenbezogene Daten. Und diese sollten immer mit besonderer Sorgfalt behandelt werden und wenn immer möglich anonymisiert oder dann zumindest verschlüsselt gespeichert und übertragen werden.

Es stellt sich aber automatisch die Frage: Was ist, wenn es genau die Aufgabe des Dienstleisters ist, diese Daten für den Bund zu verarbeiten? Muss er dann seine Daten löschen? Wohl kaum.

Es ist ein Löschverfahren für Testdaten nach deren Gebrauch zu implementieren und anzuwenden.

Diesem Punkt kann ich vorbehaltlos zustimmen.

Das ist wohl der Hinweis auf das Leck bei Xplain: Datenanalyse, das angestammte Kerngeschäft des Dienstleisters, gegen den nach dem Ransomwareangriff jetzt eine Untersuchung des EDÖB läuft, benötigt Daten. Ganz besonders viele Daten braucht es, wenn nach Auffälligkeiten in den Daten gesucht werden soll.

Klassifizierte Informationen müssen verschlüsselt oder vor Zugriff gesichert gelagert werden und sind bei Ende Gebrauch sicher zu löschen.

Hier würde ich das “oder” sogar durch ein “und” ersetzen: Diese besonders sensiblen Daten sollten nicht nur (a) auf dem Server mit Passwort vor einem Zugriff gesichert werden oder (b) als USB-Stick im Rollcontainer eingeschlossen werden, sondern sie sollten auf alle Fälle auch verschlüsselt werden. Dies vereinfacht dann auch das sichere Löschen; ganz besonders, wenn der Datenträger nicht mehr normal gelöscht werden kann, weil er z.B. defekt oder gestohlen ist.

* Netzwerk­sicherheit

Ihr Netzwerk sollte segmentiert sein, so dass der Angreifer nicht sofort zu den zentralsten Elementen der IT-Umgebung vordringen können.

Je besser die einzelnen vernetzten Geräte voneinander isoliert sind, um so höher sind die Hürden für einen Angreifer, alle Geräte unter seine Kontrolle zu bringen.

Die Vorstellung, dass es wenige zentrale Elemente gäbe, die es zu schützen gäbe und dass man deshalb alleine mit einer oder zwei Firewalls das Netzwerk vom bösen “Draussen” abschotten könne, muss aber als überholt gelten. Ganz besonders im Zeitalter der Nutzung des Internets und der Cloud.

«Defense in depth» und «zero (implicit) trust» sind daher die Leitlinien für vernetzte IT-Sicherheit.

Ein- und ausgehender Netzwerkverkehr ist zu überwachen. Remote arbeitende Personen müssen auf eine VPN-Verbindung forciert werden, damit auch in diesem Bereich die Netzwerksicherheit eingehalten ist.

Was ist für eine Person, die hauptsächlich in der Cloud arbeitet, “drinnen”, was “draussen”? Und welches KMU schafft es, seinen Netzwerkverkehr besser zu überwachen, als es die grossen Cloudprovider bei ihren eigenen Diensten tun? Auch diese beiden Sätze klingen nach einem veralteten Netzwerksicherheitsbild.

Ihr Mehrwert ist fragwürdig und verleitet die Dienstleister möglicherweise sogar dazu, die Netzwerksicherheit aus dem falschen Blickwinkel her anzugehen.

* System­sicherheit

Es sollte ein zentrales Logging auf Systemen und Anwendungen implementiert sein und die Log-Dateien müssen regelmässig ausgewertet werden.

Zwei gute Punkte, die aber definitiv erst gegen den Schluss kommen sollten. So besteht beispielsweise das NIST Cybersecurity Framework aus fünf Funktionen:

1. Identify: Wie sieht eigentlich die Burg aus? Welche Systeme (Hardware, Software, Prozesse, Daten, …) gibt es eigentlich zu schützen und welche Risiken gibt es dabei?
2. Protect: Schütze diese Systeme u.a. durch Reduktion der Einfallstore (keine unnötigen Dienste, keine veralteten Systeme, keine unnötigen Rechte, keine ungebremsten automatisierte Angriffe, …).
3. Detect: Eine Suche nach Fingerabdrücken und das Horchen nach quietschenden Türangeln macht erst Sinn, wenn man weiss, wo die Türen sind und diese vom Angreifer auch geöffnet werden müssen.
4. Respond: Jetzt kommen die Palastwachen und werfen den Angreifer hinaus.
5. Recover: Der Schlüsseldienst tauscht die Schlösser und die Handwerker beheben die angerichteten Schäden. Es wird nach den gestohlenen Juwelen gefahndet.

Also: Man sollte zuerst wissen, was man hat, und dieses schützen, bevor man den Schutz überwacht. Ansonsten geht man in einer Flut von Logmeldungen unter und übersieht die Stecknadel im Heuhaufen.

Entwickler-Arbeitsplätze dürfen nicht direkt mit dem Internet kommunizieren.

Wahrscheinlich ist mit “nicht direkt” das Dazwischenschalten einer Firewall gemeint und nicht, dass Entwickler für jede einzelne Internetrecherche das Sekretariat per Fax beauftragen müssen. Dies ist aber eigentlich bereits durch “Ihr Netzwerk sollte segmentiert sein” und “Netzwerkverkehr ist zu überwachen” geregelt und betrifft eigentlich schon alle Arbeitsplätze.

Wieso diese Massnahmen jetzt für Entwickler gesondert aufgelistet werden (und z.B. nicht auch für Systemadministratoren gelten sollten) bleibt schleierhaft.

[Neu 2023-08-03, danke an Günter Meierhofer] Der starke Fokus auf Entwicklerarbeitsplätze, Segmentierung, VPN und Testdaten wird plausibel, wenn man annimmt, dass die Ermittlungen von folgendem Szenario ausgehen: Der Rechner eines Remote-Entwicklers wurde angegriffen; darauf befanden sich Testdaten, die aktuell aber eigentlich gar nicht mehr benötigt wurden.

* Organisa­torische Sicherheit

Es sollte ein Incident-Response-Prozess mit klaren Verantwortlichkeiten aufgebaut sein.

Ja, richtig und wichtig. Siehe “Respond” oben.

Sind bei einem Vorfall potenziell Verwaltungseinheiten des Bundes betroffen, sind diese umgehend zu informieren.

Auch das ist nicht falsch. Aber das sollte nicht nur den Bund betreffen, sondern alle Betroffenen.

Ausklang

Falls Ihr Unternehmen die obengenannten Sicherheits­anforderungen nur teilweise einhält […] informieren Sie umgehend Ihre Vertragspartner in der Bundesverwaltung und kontaktieren Sie das Nationale Zentrum für Cybersicherheit (NCSC).

Wohl kaum ein Dienstleister erfüllt alle Vorgaben vollständig. Einige Punkte sind unklar, zu umfassend oder fragwürdig. Ich wüsste gerne, ob sich jetzt alle Anbieter melden oder einfach das eine oder andere Auge zudrücken.

Anmeldungen [zum IT-Sicherheits-Informations- und Austauschplattform] nimmt das NCSC unter folgender Adresse entgegen: [Email-Adresse]

Wieso erfolgt die Anmeldung nicht direkt über die Plattform? (Wenigstens nicht per Fax…)

• Weitere Informationen können Sie auch der Webseite des NCSC betr. «IKT Grundschutz in der Bundesverwaltung» entnehmen: www.bk.admin.ch > Digitale Transformation und IKT-Lenkung > Vorgaben > Sicherheit.

Ja genau: Im per A-Post versandten ausgedruckten Brief sind Links enthalten. Über eine Seite, welche Ausdruck der Digitalen Transformation beim Bund ist. Auf eine Seite, auf der nur steht, dass die eigentlichen Informationen beim NCSC zu finden seien (mit Link).

Schluss­fol­ge­rungen

Technisch ist nichts grob falsch, aber es ist ein Stückwerk aus Sinnvollem, Offensichtlichem, Unmöglichem, Fragwürdigem und Lücken. Die meiner Meinung nach grösste Lücke ist, dass gar nicht auf sichere Softwareentwicklung eingegangen wird. Es kann nicht Aufgabe des BBL sein, seinen Dienstleistern IT-Sicherheitskurse zu geben; trotzdem wäre für diesen Brief eine engere Zusammenarbeit mit dem BIT oder NCSC zu empfehlen gewesen.

Der Betreff des Briefes spricht von “Informationen und Empfehlungen zur Informationssicherheit”, der Mittelteil des Briefes kommt aber sehr verpflichtend daher. Möglicherweise hat dieser Brief am 28.6. als Empfehlung begonnen («bestehende Verträge mit Informatikdienstleistern des Bundes überprüfen […], dass die Cybersicherheit der Dienstleister verbessert wird») und erst durch die bisher nicht weiter ausgeführten Gründe hinter der Ausweitung der EDÖB-Untersuchung auf die Xplain AG am 13.7. wurde klar, dass bei den IT-Dienstleistern möglicherweise mehr im Argen liegt. Aber das sind reine Mutmassungen.

Unabhängig davon drängen sich als Grund für den Brief drei Optionen auf:

1. Der Bund hat keine Ahnung, wie es um seine Dienstleister bestellt ist.
2. Der Bund ist wirklich besorgt um die Qualität seiner Dienstleister und hat das erst jetzt bemerkt.
3. Der Bund ist wirklich besorgt um die Qualität seiner Dienstleister und weiss das schon seit Jahren.

Alle drei Optionen sind nicht wirklich beruhigend. In allen drei Fällen muss die öffentliche Hand sich aber auf die Fahne schreiben, die externen Dienstleister enger kompetent zu begleiten.

Handlungs­freiheit erhalten

Einer der Sorgenpunkte des Bundes ist, laut Pressemitteilungs-PDF, die «Wartung und Weiterentwicklung dieser [von Xplain erstellten] essentiellen Softwarekomponenten sicherzustellen».

Egal, wie die aktuelle Geschichte ausgeht: Fälle, in denen ein Dienstleister Probleme hat oder man sich von einem Dienstleister trennen will, wird es immer wieder geben. Entsprechend sollte der Bund zukünftig auch besser darauf vorbereitet sein, einen solchen Schritt möglichst schmerzlos gehen zu können.

Dabei könnte er sich beispielsweise an einigen klassischen Werkzeuge zur Reduktion von Lock-In orientieren:

1. Modularisierung bei den Projekten (einfach und eigenständig, Mut zur Lücke),
2. Nutzung von offenen, standardisierten APIs, [Neu 2023-08-02, danke an Stephan Neuhaus]
3. eine Two-Vendor-Strategie, auch wenn das im IT-Bereich nicht immer einfach ist und
4. Verpflichtung der IT-Dienstleister, den im Rahmen des Projekts erstellten Quellcode als Open Source zu veröffentlichen (Public Money, Public Code). Diesen Schritt halte ich für den Vielversprechendsten.

Weiter­führende Infor­mationen

• Martin Steiger und Marcel Waldvogel: IT-Sicherheit bei Dienstleistern des Bundes, Teil 1 (Datenschutz Plaudereien, 2022-08-02)
  Das Thema als Podcast aus leicht anderen Blickwinkeln.
• Reto Vogt: Exklusiv: Bund kontaktiert seine IT-Dienstleister wegen Security (Inside IT, 2022-07-19)
  Der Beitrag, der diesen ausgelöst hat und das gesamte Schreiben des Bundes enthält.
• Marcel Waldvogel: Was uns Ransomware zu Datenschutz und Datensicherheit lehrt (2022-12-05)
  IT-Sicherheit und ein paar einfache aber effektive Massnahmen einfach erklärt. Diese Checklisten können aber nicht mehr als der Anfang einer wundervolle Freundschaft mit der IT-Sicherheit sein.
• Marcel Waldvogel: Ransomware ist anders (2018-09-26)
  Wie Ransomware funktioniert und was man dagegen tun sollte (und was nicht).
• BSI: Forschrittliche Angriffe — dynamische Entwicklung.
  Hintergrund zu Ransomware und Cyber-Sicherheitsempfehlungen.