Bundesamt für (Un)Sicherheit in der Informationstechnik? Und was taugt der Grundschutz?

• Worum geht es?
• Beispiele
  • Eduroam
  • VMware ESXi
  • Reverse-Proxies und Web-Application-Firewalls
• Was wünsche ich mir?
• Testen oder Pentesten?
• Auskunft, Akteneinsicht, Beschwerde
• Anfragen

Worum geht es?

Seit März 2021 beschäftige ich mich intensiv mit dem BSI Grundschutz oder Kompendium. Der ist nach meinem Verständnis mehr eine Arbeitsbeschaffungsmaßnahme denn eine Hilfe, denn es gibt ganz viele Bausteine ohne dass – abgesehen von den Gefahren – ein roter Faden erkennbar ist, und viele Bausteine bleiben ganz klar hinter meinen Erwartungen zurück, weil sie Fallstricke gar nicht adressieren. Mit anderen Worten: man kann alle Bausteine umsetzen und vom BSI zertifiziert werden und trotzdem unsicher sein. Das gibt das BSI in der Stellungnahme vom 20.01.2022 im Rahmen der Vermittlung durch den Bundesbeauftragten für den Datenschutz und die Informationsfreiheit (BfDI) von sogar zu. Was soll das? Unsicherheit wird akzeptiert? Das verstößt in meinem Augen nicht nur ganz klar gegen Artikel 32 DSGVO sondern auch gegen das Gesetz über das Bundesamt für Sicherheit in der Informationstechnik (BSI-Gesetz – BSIG):

Beim besten Willen – von Gewährleistung der Vertraulichkeit kann ich da nichts erkennen.

Und außerdem verbrennen Sie viel Zeit und damit Geld, denn der rote Faden fehlt. Was den roten Faden angeht, kann ich sogar helfen und habe das auch bei BSI-Kunden schon gemacht oder versucht. Meine Sicherheitsanforderungen bestehen nicht aus geschätzt 60 System-Bausteinen mit ungezählten Detailanforderungen und in der Edition 2022 900 Seiten, sondern aus 15 + 1 Anforderungen. Einige davon – der Block Eingabevalidierung und Ausgabeaufbereitung – ergeben nur Sinn, wenn man Software entwickelt oder testet, aber alle anderen kann ich auch auf vorhandene Produkte und Infrastruktur anwenden und als Abnahmekriterium verwenden. Anforderungen für Gebäude und Prozessanforderungen habe ich da bisher nicht drin – nicht meine Kernkompetenz und die müssen ja auch zur jeweiligen Organisation passen. Dafür ist die + 1 – die Anforderung "alle Sicherheitsanforderungen können und sollen automatisch getestet werden" ganz wichtig, dazu unten mehr.

Ich habe das für meine eigene Infrastruktur gemacht, das Ergebnis finden Sie unter IT-Sicherheit@Lindenberg – gerade mal sechs Seiten Papier statt vielen hunderten. Und im Unterschied zum BSI und seinen Kunden, traue ich mich das öffentlich zu machen, denn Angreifer sind sowieso besser informiert als wir, und nur Kritik und offene Diskussion bringt einen weiter – siehe Security by Obscurity. Hunderte Seiten? Leider kein Witz. Habe ich bei Kunden gesehen, einschließlich der Defizite. In meinen Augen noch fataler, vor allem bei Software: die Autoren des Konzepts, die Entwickler oder Betreiber sind dann oft verschieden und reden zu wenig miteinander, damit sind selbst bei brauchbarem Konzept Umsetzungsfehler wahrscheinlich bis garantiert.

Wegen der vielen Mängel im Kompendium und auch aus anderen Gründen habe ich Fragen ans BSI gerichtet, aber keine einzige hat das BSI bisher ernsthaft beantwortet. Ist das BSI so ignorant und versteht nicht was es tut oder was es tun müsste, oder ist es so arrogant, dass es sich mit Fragen oder Vorschlägen gar nicht auseinandersetzen will? Immerhin hat es in der schon genannten Stellungname vom 20.01.2022 zugegeben, dass Einrichtungen nach Grundschutz unsicher sind. Mir sind noch einige weitere Mängel in Bausteinen bekannt, aber wenn ich die auch noch in Fragen gieße, unterstütze ich ja nur Angreifer (und zwar die schlechteren, die guten brauchen das nicht). Ich kenne auch nicht alle Bausteine im Detail – wer kann das schon bei 900 Seiten?

Beispiele

Drei Beispiele: Eduroam, VMware Esxi, Reverse Proxies oder Web-Application-Firewalls. Interessanterweise alle ein Problem, weil Authentifizierung und Verschlüsselung im Grundschutz vernachlässigt werden können. Über Verschlüsselung habe ich mich in Ist Verschlüsselung Pflicht? schon ausgelassen. Also betrachten wir an dieser Stelle mal Authentifizierung im Detail:

Eduroam

Das BSI schreibt ja, Eduroam sei bekannt, und Eduroam ging schon vor einigen Jahren durch die Presse. Insider und Hacker kennen die Technik und das Problem natürlich auch, schon deutlich länger – ich seit gut zehn Jahren. Das Problem ist leider nicht auf Hochschulen beschränkt, viele Unternehmen verwenden genau die gleiche Technik, nur dass sie keine Benutzer anderer Organisationen unterstützen. Das folgende Bild zeigt die typischen Komponenten für WPA-Enterprise (und ist nahezu identisch mit einem Bild aus einer Aufgabensammlung des Sicherheitskurses den ich mit IT-Nachwuchs eines DAX-Konzerns im September 2021 hatte):

Im Grundschutz findet sich dazu leider nur die Gefahr – keine Anforderung wie man die Gefahr beseitigt:

Das Problem ist die immer fehlende Authentifizierung des Access Points und die oft fehlende Authentifizierung des Authentication Servers durch den Client. Weder OPR.4 noch NET.2 verlangen diese Authentifizierung ausdrücklich. Meine Sicherheitsanforderungen besagen "Verwende X.509 Zertifikate oder Kerberos zur Authentifizierung von Systemen oder Services (Server und Client)". Hier prüft der Client typischerweise nur den Namen des Netzes und den kennt ja jeder. Wenn Sie jetzt in der Tabelle auf Bedrohungsmodellierung nachsehen, dann stehen da schon die Gefahren Spoofing – in diesem Kontext auch Fake- oder Rogue-Access-Point – und Denial-Of-Service – über den Fake kommen Sie meist nicht in Ihr Netzwerk. Wenn Sie sich noch klar machen, dass Berechtigungen Authentifizierung erfordert, haben Sie das volle Desaster, einschließlich der Datenpanne. Machen Sie sich klar, dass der Client die Credentials – Ihre Kronjuwelen – einem System anvertraut, das er nicht authentifiziert hat – danach ist alles möglich.

Natürlich kann man je nach verwendetem (P)EAP-Verfahren den Client richtig konfigurieren und eine Prüfung des Zertifikats des Authentication Servers konfigurieren, aber Eduroam zeigt, dass die Anwender damit überfordert sind, und es auch gerne in den sowieso nicht gelesenen Anleitungen fehlt. Wenn Sie nicht wissen wofür (P)EAP steht oder wie Zertifikate genau funktionieren, dann sind Sie in guter Gesellschaft. Also erreichen Sie Sicherheit nur dann, wenn Sie verhindern, dass Ihre Domänen-Passwörter dafür verwendet werden.

Alternativen

Welche Alternativen – ohne Anspruch auf Vollständigkeit – gibt es?

• EAP-TLS und Zertifikate für Client und Server – so steht es in meinen Anforderungen, weil mit zertifikatsbasierter Authentifizierung geben Sie Schlüssel nie aus der Hand sondern beweisen nur dass Sie ihn haben. Das Problem ist, dass Sie einen Prozess für die Verteilung des Client-Zertifikats brauchen – es gibt kommerzielle, leider nicht ganz billige Lösungen dafür.
• offenes WLAN – wenn Sie Sicherheit sonst ernst nehmen, dann verschlüsseln Sie jede Kommunikation, auch jede interne Kommunikation, mit TLS, https, oder anderen hinreichend guten Protokollen. Dann kommt es auf die WLAN-Verschlüsselung nicht wirklich an, oder nur um DNS privat und zuverlässig zu bekommen, aber dafür gibt es auch andere Möglichkeiten. Fragt sich aber, ob Sie dann zum öffentlichen Telekommunikationsnetzanbieter werden.
• Preshared Key – immer anrüchig, weil die Sicherheit nur so gut wie die schwächste Stelle ist. Sie müssten formal auch jedesmal wenn ein Mitarbeiter die Firma verlässt den Key ändern, und das machen zu wenige Organisationen.
• separates Directory (Benutzerverzeichnis) – das vermeidet die Probleme der obigen Alternativen. Habe ich bisher bei nur einer Firma und bei mir selbst gesehen.

Und warum habe ich dieses Beispiel vertieft? Weil selbstverständlich nicht überall Sicherheitsanforderungen ideal umgesetzt werden können, aber wenn eben nicht, dann müssen Sie nach Alternativen suchen, die das Risiko auf ein vertretbares Maß reduzieren. Als ich bei der Dualen Hochschule angefangen habe zu unterrichten und man mir schrieb, die Zugangsdaten gelten auch für Eduroam, hab ich gleich zurückgefragt, ob die Risiken bekannt sind. Antwort ja. Andere kennen nicht einmal das Risiko. Im Kompendium steht das Risiko, aber weder klare Anforderungen noch eine Musterlösung. Warum nicht?

VMware ESXi

VMware ESXi unterstützt leider keine Verschlüsselung der beteiligten Server. Die Sicherheit einer VMware Installation hängt damit ausschließlich an der Netzwerksicherheit (ESXi Networking Security Recommendations: Isolation of network traffic is essential to a secure ESXi environment.) und damit an der Qualität der Netzwerkkomponenten und der Gebäudesicherheit – und wie ich in Ist Verschlüsselung Pflicht – Defense-in-Depth geschrieben habe, ins Gebäude kommt man immer, und damit auch an das Netzwerk, und manche Hersteller von Netzwerkinfrastruktur nehmen Qualität auch nicht sehr ernst.

Ohne Verschlüsselung als Basisschutz der Server ist das Betriebssystem unzureichend vor Manipulationen geschützt, die Verwendung von Secure-Boot bei VMware also weitgehend sinnlos, denn Secure-Boot prüft zwar die Signaturen der Boot- und einiger Betriebssystemkomponenten, verhindert aber nicht andere Manipulationen des gestarteten Betriebssystems – das übernimmt bei Windows Servern die Bitlocker-Verschlüsselung. Und damit ist auch völlig unklar, wo man bei VMware ESXi irgendwelche Passwörter, Zertifikate oder andere Credentials sicher gespeichert werden sollen, mit denen sich ein Server bei anderen IT-Komponenten anmelden könnte. Auch nützt es wenig, entsprechend SYS.1.5 die virtuellen Maschinen zu verschlüsseln, denn eine virtuelle Maschine kann sich nicht sinnvoll vor Angriffen auf dem Host schützen.

Ohne Verschlüsselung erfüllt VMware auch ORP.4.A12 nicht. Oder vielleicht doch? Denn VMware selbst speichert ja gar keine Authentifizierungsinformationen, das findet dann erst in virtuellen Maschinen statt, und die soll man nach SYS.1.5 bei hohem Schutzbedarf verschlüsseln. Nur dass das auch bedeutet, dass jegliche Kommunikation in VMware ESXi nicht authentifiziert ist, und damit selbst wenn verschlüsselt wird unklar ist, ob man mit dem richtigen Partner kommuniziert – erkennen Sie jetzt warum die Einleitung in ORP.4 eine Basisanforderung sein müsste? Unabhängig davon, dass man Verschlüsselung wegen ORP.4.A12 schon bei normalem Schutzbedarf bräuchte, ergibt das wenig Sinn, sondern es erweckt bei mir den Eindruck, dass man im Grundschutz konsequente Authentifizierung und Verschlüsselung im Rechenzentrum nicht einfordert, weil man sonst den Einsatz von VMware ESXi verbieten müsste.

Natürlich ist mir bekannt, dass viele öffentliche Einrichtungen VMware einsetzen, und ich nehme die Projektangebote auf Plattformen wie freelance.de Suche für einen Kunden im öffentlichen Bereich einen VMware-Spezialisten mit Schrecken wahr. VMware scheint es billig – ich schreibe bewusst nicht preiswert – im Kaufhaus des Bundes zu geben, aber dann hat das Kaufhaus auch eine Nachfragemacht gegenüber VMware und könnte Verbesserungen einfordern.

Alternativen

So ziemlich alle modernen Betriebssysteme bieten Verschlüsselung an, und bei Windows-Clients ist auch im öffentlichen Bereich Bitlocker mit Pre-Boot-Authentication weit verbreitet. Problematisch ist Verschlüsselung allenfalls bei selbststartenden Systemen, denn niemand will im Rechenzentrum nach einem Ausfall oder sonstigem Neustart manuell einen Schlüssel oder Passwort eingeben. Zumal den ja dann mehrere Mitarbeiter kennen müssten und er damit als kompromittiert anzusehen wäre.

Windows Server bzw. Hyper-V unterstützt Bitlocker und zusammen mit Bitlocker Network Unlock kann man Verschlüsselung auch für selbststartende Systeme realisieren. Da ich das selbst einsetze findet sich mehr Dokumentation dazu in meinem Sicherheitskonzept.

Bei Linux kann man Clevis und Tang einsetzen – damit habe ich bisher keine eigene Erfahrung.

Reverse-Proxies und Web-Application-Firewalls

Zunächst muss ich klarstellen, dass ich hier Reverse-Proxies auf http-Ebene meine, denn der Begriff Proxy ist überladen. Reverse-Proxies auf http-Ebene terminieren genau wie Web-Application-Firewalls den http-Verkehr und leiten ihn dann an die eigentliche Web-Anwendung oder http-basierte Dienste weiter. Und dann werden meist alle möglichen Sicherheitsfunktionen beworben, die in der Praxis nur selten realisiert werden können. Tatsächlich haben viele Firmen eine Web-Application-Firewall im Einsatz, um bei entsprechenden Checklisten gut auszusehen, die Filter-Regeln der Web-Application-Firewall sind aber fast immer leer. Und selbst wenn da etwas drin steht, dann selten etwas was einen Angreifer ernsthaft abhält.

Etwas besser ist es, wenn die Regeln nicht eine Blacklist sondern eine Whitelist realisieren, nur muss die oft bei Änderungen der Web-Anwendung nachgepflegt werden – fast immer ein Aufwand der unterschätzt wird und im Einsatz zu Fehlfunktionen führt. Das hat Eingang ins Kompendium gefunden:

In der Praxis führt das meist dazu, dass nach kurzer Zeit alle Filterfunktionen deaktiviert werden, als ob die WAF gar nicht da wäre.

Ist sie aber doch, nur dass sie sich jetzt wie ein Reverse-Proxy verhält. Das große Sicherheitsproblem ist, dass Reverse-Proxies und also auch Web-Application-Firewalls die verschlüsselte Verbindung terminieren – als Man-In-The-Middle. Für die Nicht-Fachleute: das ist ein Ende der verschlüsselten Verbindung, d.h. auf dem Proxy oder der WAF sind die Daten nicht verschlüsselt, und ob danach, zur eigentlichen Anwendung verschlüsselt wird bleibt offen – der Grundschutz verlangt es nicht, und dementsprechend selten wird es gemacht. Ein Proxy ist also auch eine Stelle an der die echten Daten – oft einschließlich Anmeldeinformationen – abgegriffen, protokolliert, aber auch manipuliert werden können – oft unbemerkt vom Verantwortlichen der eigentlichen Webanwendung. Damit ist ein zentraler Reverse-Proxy oder eine zentrale WAF in meinen Augen sogar ein prädestinierter Angriffspunkt, und verstößt damit meiner Meinung nach gegen den 1. und 2. Satz von ORP.4.A13 (s.o.). Und auch wenn der Grundschutz in NET.3.2.A21 Temporäre Entschlüsselung des Datenverkehrs (S) fordert – ich halte nichts davon, denn es erhöht das Risiko eher als es zu senken.

Ein Kollege bei SAP hat sehr treffend gesagt, alles was man auf einer WAF kann, kann man auch und meist besser in der Anwendung selbst realisieren. Oder mit den Worten von Gary McGraw in Software Security: Building Security In (2005): Basically, the dollars spent on network security and other perimeter solutions are not solving the security problem. We must build better software. Das muss man dann aber auch umsetzen. Bei SAP findet das statt, bei Dataport nicht – Dataport – kann man nur verpfeifen!. Die Netzwerkinfrastruktur alleine kann das jedenfalls nicht lösen, denn sie kann zwar einen SYN-Flood erkennen, nicht aber einen Angreifer der Passwörter durchprobiert.

Alternativen

Statt die Verbindung zu terminieren, kann man sie auch mit einem TCP-Proxy (z.B. nginx) weiterreichen und dabei z.B. mit Hilfe des Proxy-Protocols auch die IP-Adresse des Clients weiterreichen – sofern erforderlich. Viele Webserver und Anwendungen verstehen das Proxy-Protokoll oder können entsprechend geändert werden. Die einzige Ausnahme bei mir ist der Windows Internet Information Service. Notfalls installiert man einen dezentralen Reverse-Proxy direkt vor der Anwendung möglichst auf dem gleichen System oder in einem Container im gleichen Docker-Compose oder im gleichen Kubernetes-Pod, dann ist sichergestellt, dass die Administratoren und die Uhrzeit der Logs zusammenpassen.

Und dann sollten Anwendungen oder Dienste sicherheitsrelevante Ereignisse protokollieren und an eine zentrale Infrastruktur melden um beim Verdacht auf einen Angriff die Firewall zu instrumentieren. Auch das ist im Grundschutz eigentlich nicht vorgesehen, denn NET.3.2.A2 erlaubt nur eine Whitelist und keine Blacklist, aber mir ist völlig unklar, wie man eine (D)DOS-Attacke eines Botnets aus Zugangsnetzen normaler Provider anders verhindern soll als durch eine sukzessive aufgebaute Blacklist. Und nur damit keine Missverständnisse auftreten: auch ich bin Anhänger von White-List-Ansätzen, aber hier ist mir keine sinnvolle Alternative bekannt.

Was wünsche ich mir?

Wenn ich drei Wünsche frei hätte:

• Reduziert die Anforderungen auf so wenige wie irgend möglich, damit man den roten Faden erkennen kann. Diese allgemeinen Anforderungen sind gleichzeitig die, die in kundenspezifischer Software verwendet werden sollen. Als Vorschlag der erweitert werden kann, können meine Sicherheitsanforderungen herangezogen werden.
• Wenn die Anforderungen gleich sind, kann man in den einzelnen Bausteinen aufzeigen, wie die generischen Anforderungen bei konkreten Systemen, Technologien oder Anwendungen umgesetzt werden sollen, und welche Ausnahmen oder Alternativen vielleicht erlaubt sind und welche Risiken damit einhergehen.
• Und wenn die Anforderungen, Alternativen, und die Musterlösungen bekannt sind, dann ist auch standardisierbar wie man es testet. Testen, am besten automatisch. Dazu unten weiter.

Kommt Ihnen bekannt vor? Dann haben Sie vermutlich meinen Artikel Bedrohungsmodellierung und dieses Bild in Erinnerung:

Testen oder Pentesten?

Nochmal zu + 1 Testen. Wenn man nur Anforderungen definiert, sie aber nicht überprüft, dann können sich ganz leicht Fehler einschleichen. Eigentlich logisch, oder nicht? Diese Fehler sind dann im Idealfall Beute für den Pentester, im schlechtesten Fall nutzt ein Angreifer sie aus. Anforderungen manuell zu testen ist bei der Komplexität heutiger Software und Systeme nicht effektiv, das muss auf Ausnahmen beschränkt sein – ganz unabhängig davon ob es sich um eine funktionale oder nicht-funktionale Anforderung wie Sicherheit handelt. Je weniger Anforderungen sie haben, desto leichter finden Sie nicht nur Musterlösungen, sondern auch standardisierte Testansätze. Das ist z.B. bei der TR-03108 und den Verwaltungsportalen ganz offensichtlich schief gegangen, nur ist völlig unklar an welcher Stelle. War unklar, dass RFC 7672 oder TR-03108 relevant ist? Oder einen Schritt zurück: wenn man – siehe Anforderungen – Verschlüsselung und Authentifizierung bei Email erreichen will, dass man dann RFC 7672 oder TR-03108 braucht? Wie man das mit Standardprodukten umzusetzen kann (s.a. RFC 7672 mit Mailcow/Postfix)? Was die relevanten Anforderungen" im Sinne von OPS.1.1.6 sind, die getestet werden sollen? Oder wie man sie automatisch überprüft? Details auf Emailsicherheit – der Test und vielleicht irgendwann in Anfrage Sichere Email nach BSI TR-03108 – wenn das BSI auf die Frage antwortet, und ich dann vielleicht verstehe, ob es Unterschiede zwischen RFC 7672 und TR-03108 gibt.

Dass auf Test zu wenig Wert gelegt wird ist leider ein Muster im Grundschutz. In der oben schon verlinkten Edition 2022 taucht "test" an 391 Stellen auf, einschließlich Treffern von "spätestens", "älteste", "weitestgehend". Echte Treffer des Wortstamms test in Kombination mit MUSS gibt es in nur 12 Anforderungen. SOLL ist auch MUSS? Habe ich bei keinem Kunden erlebt. Die meisten Treffer – nein, nicht in OPS sondern in INF, 3 in INF.2, 1 in INF.14. OPS folgt tatsächlich mit 3 Treffern in OPS 1.1.6, aber die sind wieder so abstrakt, dass man gleich interpretieren kann, man darf´s auch lassen. Weiter je 1 Treffer in CON.3, CON.8, APP.3.4, SYS.3.1, und NET.3.2. Wenn ich einen übersehen haben sollte schicken Sie mir bitte eine Email. Den Rest müssen Sie also nicht testen. Mit anderen Worten, ohne die Pentester finden Sie nichts, aber die sind ja auch nur ein SOLL in OPS.1.1.6. Also selbst wenn Ihr Sicherheitskonzept gut ist, über die Umsetzung wissen Sie effektiv nichts, wenn Sie nicht testen. Machen Sie die Pentester arbeitslos indem Sie selber testen und die Tests möglichst automatisieren. Viel mehr verkauft Ihnen der Pentester heute auch nicht, der lässt meist viele Tests automatisch laufen, erst wenn er da etwas beobachtet geht er in die Tiefe.

Auskunft, Akteneinsicht, Beschwerde

Um Licht in die Frage Arroganz vs. Ignoranz zu bringen habe ich Auskunft und Akteneinsicht beantragt. Auch hier will man erstmal mauern – aber die Beschwerde läuft. Am 29.08.2022 will man mir Akteneinsicht gewähren und um mir die Zuzusenden will man ein Zertifikat. Da ich nichts von PGP und S/MIME halte, muss ein anderer Weg her. Und die Beschwerde habe ich erweitert, weil man das Zertifikat anscheinend auch per Email akzeptieren würde. Dass Schlüssel und Inhalte getrennt kommuniziert werden müssen – das BSI scheint so etwas nicht zu wissen. Stand 01.10.2022: Dann erhalte ich die elektronische Auskunft, kann die darin enthaltenen Dokumente aber nicht den Vorgängen zuordnen – auch das sehe ich als Verstoß gegen Artikel 5 – und für einige Dokumente braucht man den umstrittenen Acrobat Reader. Aufgrund meiner Auskunft beim BfDI habe ich inzwischen auch Teile der Kommunikation zwischen BfDI und BSI ergänzen können – so richtig verstanden und umgesetzt hat das BSI die DSGVO noch nicht.

Anfragen

Die Liste meiner Anfragen ans Bundesamt für (Un)Sicherheit in der Informationstechnik: