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

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):

§3 BSIG
(1)
Das Bundesamt fördert die Sicherheit in der Informationstechnik mit dem Ziel, die Verfügbarkeit, Integrität und Vertraulichkeit von Informationen und deren Verarbeitung zu gewährleisten. ...
...
 

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:

BausteinTitel/Anforderung
ORP.4 Identitäts- und Berechtigungsmanagement
Einleitung
Benutzer und IT-Komponenten müssen zweifelsfrei identifiziert und authentisiert werden.
Leider ist der Begriff IT-Komponente im Grundschutz nicht definiert und damit unklar für was die Erfüllung dieser "versteckten" Anforderung erwartet wird. Auch sind alle konkreten Anforderungen zusammen schwächer als dieser eine (richtige) Satz.
A9 Identifikation und Authentisierung [IT-Betrieb] (B)
Der Zugriff auf alle IT-Systeme und Dienste MUSS durch eine angemessene Identifikation und Authentisierung der zugreifenden Benutzer, Dienste oder IT-Systeme abgesichert sein. Vorkonfigurierte Authentisierungsmittel MÜSSEN vor dem produktiven Einsatz geändert werden.
Anmerkung: warum nur der zugreifenden Benutzer, Dienste oder IT-Systeme und nicht auch des Dienstes oder IT-Systems, auf das zugegriffen wird?
A12 Entwicklung eines Authentisierungskonzeptes für IT-Systeme und Anwendungen [IT-Betrieb] (S)
Es SOLLTE ein Authentisierungskonzept erstellt werden. Darin SOLLTE für jedes IT-System und jede Anwendung definiert werden, welche Funktions- und Sicherheitsanforderungen an die Authentisierung gestellt werden. Authentisierungsinformationen MÜSSEN kryptografisch sicher gespeichert werden. Authentisierungsinformationen DÜRFEN NICHT unverschlüsselt über unsichere Netze übertragen werden.
Anmerkung: auf sichere Netze zu vertrauen ist in meinen Augen grob fahrlässig. Mehr zur Netzwerksicherheit in Ist Verschlüsselung Pflicht – Defense-in-Depth?
A13 Geeignete Auswahl von Authentisierungsmechanismen [IT-Betrieb] (S)
Es SOLLTEN dem Schutzbedarf angemessene Identifikations- und Authentisierungsmechanismen verwendet werden. Authentisierungsdaten SOLLTEN durch das IT-System bzw. die IT-Anwendungen bei der Verarbeitung jederzeit gegen Ausspähung, Veränderung und Zerstörung geschützt werden. Das IT-System bzw. die IT-Anwendung SOLLTE nach jedem erfolglosen Authentisierungsversuch weitere Anmeldeversuche zunehmend verzögern (Time Delay). Die Gesamtdauer eines Anmeldeversuchs SOLLTE begrenzt werden können. Nach Überschreitung der vorgegebenen Anzahl erfolgloser Authentisierungsversuche SOLLTE das IT-System bzw. die IT-Anwendung die Benutzerkennung sperren.
Anmerkung: ich halte nichts davon, Benutzerkennungen zu sperren, denn das ermöglicht Denial-Of-Service-Angriffe auf Benutzerkennungen. Sinnvoller ist es, die IP-Adresse oder das Netzwerk von dem die gescheiterte Anmeldung kam vorübergehend zu blockieren. Eine schöne Darstellung zu Für und Wider in Bruteforce-Protection und warum das gar nicht so leicht ist.

 

Runtime Error

Server Error in '/' Application.

Runtime Error

Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.

Details: To enable the details of this specific error message to be viewable on remote machines, please create a <customErrors> tag within a "web.config" configuration file located in the root directory of the current web application. This <customErrors> tag should then have its "mode" attribute set to "Off".


<!-- Web.Config Configuration File -->

<configuration>
    <system.web>
        <customErrors mode="Off"/>
    </system.web>
</configuration>

Notes: The current error page you are seeing can be replaced by a custom error page by modifying the "defaultRedirect" attribute of the application's <customErrors> configuration tag to point to a custom error page URL.


<!-- Web.Config Configuration File -->

<configuration>
    <system.web>
        <customErrors mode="RemoteOnly" defaultRedirect="mycustompage.htm"/>
    </system.web>
</configuration>