secunet Technische Analyse und Konzeptprüfung des beA Abschlussbericht - Version: 1.0 Stand:   30.05.2018

Sicherheitsanalyse secunet Copyright© 2018 by secunet Security Networks AG Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenzeichen usw. in die- sem Dokument berechtigt auch ohne besondere Kennzeichnung nicht zu der An- nahme, dass solche Namen im Sinne der Warenzeichen- und l\Aarkenschutz- Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt wer- den dürfen. Alle l\Aarken und Produktnamen sind Warenzeichen oder eingetragene Warenzeichen der jeweiligen Zeichenhalter. Version : 1.0                  Stand: 30 .05 .2018                                       1 Seite 2

Sicherheitsanalyse secunet Inhaltsverzeichnis Technische Analyse und Konzeptprüfung des beA. „ ....................................................... „ ....... 1 Abschlussbericht ........................................................................................................................ 1 Inhaltsverzeichnis ................................................................................................... ..... .. ............. 3 1     rv1anagement Summary .............. „„„ ......................... „ ............ „ ........... „ ....... ... „ .... „ .......... 5 1.1      Zielsetzung und Abgrenzung des Betrachtungsgegenstandes ... „ „ .. „ .....„ „„ ... „ ... 5 1.2      Ergebnisse Penetrationstests ..... „ ..........................„„ ................................ „„ ........ 6 1.3      Ergebnisse Quelltextanalyse ....... „„„ „ ..... „„„. „ ..... „„„.„. „ „ ..... „ ....... „ „ „ „ „ „ .... „ .. 8 1.4      Ergebnisse konzeptionelle Analyse „„„„ ........................ „„ .................. „„„„ ... „ .. „. 8 1.5      Resümee und Empfehlung .......... „„„„„„„„„„„ ..... „„„ .... „„„„.„ ............... „„„ .... 10 2     Konventionen im Dokument ............................................................................................. 12 3     Penetrationstests ............................ „ „ ............ „ ................ „ .... „ .......................... ..... „„ ..... 14 3.1      Rahmenbedingungen ... „„ ......................................... „„ „ ............... „„ .......... „„ ..... 14 3.1.1     Abgrenzung ....... „ „ „ .... „ ............. „ ......... „ ................... „ ... „.„„ „ „ „ ..„ „ ..... 14 3.1.2     Beschreibung des Analysegegenstandes ........ „ „ „ „ „ „ „ „ ........ „ .. „„„ .. .. 15 3.1.3     Vorgehensweise und In halte der Untersuchung „„ .............. „„„„„„„.„. 16 3.2      Identifizierte betriebsverhindernde Schwachstellen .„ .... „ ............ „ ....„„ ... „„„„.„ 16 3.2.1     Autorisierungmechanismen: Umgehen des Autorisierungsschemas .... 17 3.2.2     Autorisierungsmechanismen: Path-Traversal bei Dateiupload .... „„„ .. „ 18 3.2.3     Session-rv1anagement: Parametrisierung der Session-Cookies „„„„„ .. 19 3.2.4     Verschlüsselungsmechanismen der Kommunikationskanäle „ ... „„„„.„ 19 3.2.5     lnformationssam mlung: Applikationsarchitektur ......„ „ .„ „ „ .. „ „ ....„„„ .... 19 3.2.6     Identitätsmanagement: Umgehung des Authentisierungsschemas„ ..... 20 3.3      Identifizierte betriebsbehindernde Schwachstellen .......... „.„„„„.„„ .. „„„„„„„ .... 21 3.4      Verifikation der Behebung gefundener Schwachstellen.„„„„„„„„ .... „ .. „„„„.„ ... 22 3.5      Verifikation der Behebung vorab bekannter Schwachstellen.„„ ....... „ .„„ .. „„„„ .. 22 4     Quelltextanalysen ... „„ ............. „ .......................... „ ............ „ ..... „ ................. ........... „ ........ 26 4.1      Rahmenbedingungen ...... „ ... .. ............................................ „„ ......... „. „ ... ...... „ ...... 26 4.1 .1    Allgemeines ......„ .. „„„„„ ...... „„„.„„„„„„ ............. „.„ ....... „„„ „ ...... „„ ... „ 26 4.1 .2    Beschreibung des Analysegegenstandes ....... „„„.„ ...... „ ............ „ .. „ .... 26 4.1.3     Vorgehensweise und Inhalt der Untersuchung „„ ............... „„ ...... „„ ..... 27 4.2      Identifizierte Schwachstellen .............................. .. ........ „ .......... „ .......... „ ............... 28 4.2.1     Anfällige Java-Bibliotheken .... „„„„ „„„.„ ..„„„„.„„„ ...... „„„„„„„„.„„ .... 28 4.2.2     Mögliche Ausführung von Schadcode (JSON) „„„„„ .............. „„„„„„ .„ 29 4.2.3     Mögliche Ausführung von Schadcode (XML) .„„„„„„ ........ „ .. „„„ .... „„„ 30 Version : 1.0                     Stand: 30.05.2018                                                                                  1 Seite 3

Sicherheitsanalyse secunet 4.2.4      IVöglicherweise unsicherer Quelltext - Zufallszahlengenerator ............. 30 4.2.5     TLS-Zertifikate-Validierung ..................................................................... 31 4.2.6      Log-Ausgaben ......................................................................................... 31 4.2.7      Unfertiger bzw. system-spezifischer Quelltext ....................................... 32 4.2.8      Eventuelle Ausführung von Datenbankbefehlen (SQUJPQL injection). 33 4.2.9      Unsichere Generierung von Initialisierungsvektoren .............................. 33 4.2.10     Unsicheres Auffüllen von Daten bei Verschlüsselung ............................ 34 4.3    Durch den CCC gemeldete Schwachstellen ........................................................ 34 4.3.1     CCC 1: SSL-Zertifikat für bealocalhost.de kompromittiert ..................... 34 4.3.2     CCC 2: beA-Client-Security startet unsicheren Webserver und Websocket. ............................................................................................................ 34 4.3.3     CCC 3: beA-Client-Security nimmt serialisierte Java-Objekte via Websocket entgegen und führt sie aus ................................................................ 35 4.3.4     CCC 4: Unterstützte Betriebssysteme sind veraltet ............................... 35 4.3.5     CCC 5: Client besteht aus stark veralteten Paketen (zum Teil aus 2011/2013) ................................................................ ..... ....................................... 35 4.3.6     CCC 6: XSS-Sct'Mlachstelle in der beA-Webanwendung .... .................. 35 5     Konzeptionellen Analyse .................................................................................................. 36 5.1    Rahmenbedingungen ............................................................................................ 36 5.1.1     Beschreibung des Analysegegenstandes ........ „ ... „ ............... . ••.•••••••..... 36 5.1.2     Inhalte der Untersuchung „ ........ „ •.... „ .. „ ...........• „ .....•..............••••• • •••.•..•. 36 5.1 .3    Vorgehensweise ...................................................................................... 36 5.1.4     Anmerkungen zu Betriebs- und Sicherheitskonzepten ......... .. ............... 43 5.2    Identifizierte Schwachstellen in der Konzeption ................................................... 44 5.2.1     BNotK kann Ursprung der Zertifikatsanträge aus HSM nicht erkennen 44 5.2.2     Berechtigungen können nicht entzogen werden ....................... „ ..• „ .. „ .. 45 5.2.3     Signatur für Rechteweitergabe enthält nicht die Postfach-ID „ •........... „ 46 5.2.4     Verwendung von Javascript beim beA_Client ........................................ 46 5.2.5     EGVP-Bürger-Verzeichniseinträge im SAFE können irreführend sein .. 47 5.2.6     Client prüft Postfachzertifikate nicht ......... „ .........•••••••••••.......•.••••••••••••• •• 48 5.2. 7    HS M-Schlüssel existieren außerhalb des HS M ..................................... 49 Version: 1.0                   Stand : 30.05.2018                                                                                1 Seite 4

Sicherheitsanalyse secunet 1         Management Summary 1.1       Zielsetzung und Abgrenzung des Betrachtungsgegenstandes Die secunet Security Networks AG (secunet) wurde beauftragt, die Umsetzung des besonderen elektronischen Anwaltspostfachs (beA) hinsichtlich IT-Sicherheit zu analysieren und zu bewerten. Ziel der Analyse ist, bereits bekannte technische, or- ganisatorische und konzeptionelle Schwachstellen zu validieren und gegebenenfalls vorhandene neue Schwachstellen zu identifizieren und zu beurteilen. Im Rahmen der Untersuchungen wurden neben Penetrationstests ausgewählter beA- Komponenten und Schnittstellen ebenfalls Quelltextanalysen sowie eine konzeptio- nelle Analyse durchgeführt. Im Auftrag war die Erstellung eines Abschlussgutachtens vorgesehen, das mit die- sem Dokument an die Bundesrechtsanwaltskammer übergeben wird. Das hier vor- liegende Abschlussgutachten bildet den Stand der Untersuchungen zum Stichtag 28.05.2018 ab. Eine Vielzahl der im laufe der Analyse erkannten Schwachstellen wurde bereits im Projektverlauf zur Behebung an den Hersteller bzw. Betreiber des beA-Systems kommuniziert. Ein Teil der gemeldeten Schwachstellen konnte bereits vor Erstellung dieses Gutachtens behoben und einem erneuten Test durch secunet unterzogen werden. Zum Zeitpunkt der Gutachtenbereitstellung ist die Behebung von Schwachstellen durch den Betreiber noch nicht abgeschlossen. Dementspre- chend konnten nicht alle erfolgten Maßnahmen einem erneuten Test unterzogen werden . Der erneute Test der nach dem Stichtag für die Erstellung des Abschluss- gutachtens behobenen Schwachstellen ist beabsichtigt. Bei der Lektüre und Nutzung dieses Berichts sind unbedingt folgende Hinweise zu berücksichtigen: •  Bei allen durchgeführten Tests handelt es sich um stichprobenartige Über- prüfungen, in denen versucht wird, mit einem vertretbaren Aufwand mög- lichst viele Schwachstellen innerhalb des Betrachtungsbereichs zu identifizieren. •  Die vorliegenden Ergebnisse müssen stichtagsbezogen beziehungsweise bezogen auf einen speziellen Versionsstand aufgefasst werden und enthal- ten keine Aussagen über die Sicherheit der zukünftigen technischen und organisatorischen Anpassungen bzw. Lösungen. •  Im Rahmen der Analysen wurde lediglich der wesentliche Teil der für das beA erforderlichen technischen Komponenten, Schnittstellen oder Anwen- dungsfälle betrachtet. Es kann somit nicht vollständig ausgeschlossen wer- den, dass in anderen Teilen weitere nicht erkannte Schwachstellen vorhanden sind. Es kann auch nicht völlig ausgeschlossen werden, dass bereits behobene Schwachstellen in zukünftigen Versionen erneut auftre- ten oder in zukünftigen Versionen neue Schwachstellen implementiert wer- den. Exemplarisch ist auch zu berücksichtigen, dass die konzeptionelle Version: 1.0                   Stand : 30 .05.2018                                         1 Seite 5

Sicherheitsanalyse secunet Analyse sich auf die Sicherheitsziele ,,Vertraulichkeit" und „Authentizität" konzentriert hat und somit insbesondere eine Betrachtung der „Verfügbar- keit'' nur am Rande erfolgt ist. Innerhalb der technischen Analysen standen die beA-Client-Security, die beA-Anwendung und externe Schnittstellen im Fokus. •   Nicht alle der bis zum Stichtag gefundenen Schwachstellen wurden vollum- fänglich hinsichtlich ihrer Ausnutzbarkeit, deren Wahrscheinlichkeit und po- tenzieller eintretender Schäden bewertet. Beispielsweise fand keine vollständige Betrachtung der technischen und organisatorischen Gegeben- heiten innerhalb der produktiven Betriebsumgebung, z. B. innerhalb des Rechenzentrums, statt. Das Ausnutzen einzelner identifizierter Schwach- stellen kann eventuell durch geeignete technische und organisatorische l\/laßnahmen - seitens der BRAK oder des Betreibers - deutlich erschwert oder sogar vereitelt werden. Umgekehrt können aber auch Schäden durch fehlende bzw. ungeeignete technische und/oder organisatorische l\/laß- nahmen entstehen. Die vorgelegten grundlegenden Konzepte zur IT- Sicherheit (Sicherheitskonzept, Betriebskonzept etc.) ermöglichten keine abschließende Einschätzung. •   Darüber hinaus war es erforderlich, Annahmen zu treffen und Abgrenzun- gen des Betrachtungsgegenstandes vorzunehmen, damit der Aufwand ins- gesamt vertretbar blieb. Beispielsweise wurden der von einem Anwalt genutzte Rechner und dessen Einsatzumgebung als hinreichend abges i- chert angesehen. Die Absicherung des Anwaltsrechners sowie der Ein- satzumgebung war dementsprechend nicht Gegenstand der Untersuchung. •   Auch eine Analyse, ob die beA-Lösung alle rechtlichen und funktionalen Anforderungen erfüllt, war nicht Gegenstand der Betrachtung. Es ist möglich, dass einzelne identifizierte Schwachstellen von Dritten nachvollzo- gen und ausgenutzt werden können, auch wenn sie bereits behoben wurden, z. B. bei nicht erfolgter Deinstallation älterer Versionen der beA-Client-Security. Außer- dem könnten durch die Darstellung von detaillierten technischen Informationen Rechte Dritter verletzt werden, z.B. durch Angabe von Quellcode, oder schützens- werte Informationen aufgedeckt werden, wie z.B. IP-Adressen. Aus diesem Grund werden die Schwachstellen in diesem Gutachten ohne Angabe von detaillierten technischen Informationen dargestellt. Die detaillierten technischen und inhaltlichen Informationen zu den einzelnen Schwachstellen werden zu deren gezielter Behe- bung laufend an die BRAK übermittelt. Die Inhalte und Ergebnisse der bisherigen Analysen werden in den folgenden Un- terabschnitten 1.2 bis 1.5 überblicksweise dargestellt und in den Kapiteln 3 bis 5 ausführlicher erläutert. 1.2       Ergebnisse Penetrationstests Die secunet hat im Auftrag der Bundesrechtsanwaltskammer (BRAK) zwischen Feb- ruar und l\/lai 2018 Penetrationstests ausgewählter Systeme durchgeführt. Ziel die- Version: 1.0                    Stand: 30 .05 .2018                                           1 Seite 6

Sicherheitsanalyse secunet ser Tests war es, sicherheitsrelevante Schwachstellen zu identifizieren und zu be- werten. Die Analyse wurde angelehnt an den OWASP (Open Web Application Security Project) Testing-Guide durchgeführt. Darüber hinaus wurden systematisch weitere Aspekte analysiert, welche die OWASP-Testfälle in Bezug auf die jeweilige Anwendungsarchitektur erfahrungsgemäß sinnvoll ergänzen. Zunächst wurde die beA-Systemumgebung erfasst und in zwei Untersuchungsge- genstände separiert. Innerhalb der ersten Phase bis Ende März 2018 wurde die beA-Client-Security mitsamt den Kommunikationsendpunkten zur beA-Anwendung betrachtet. In der zweiten Phase wurden darüber hinaus externe Schnittstellen (Webservices, Webportale und eine weitere Client-Software) analysiert, die im Rahmen des beA-Betriebs bereitgestellt werden. In der ersten Analysephase konnten verschiedene Schwachstellen identifiziert wer- den, durch die das Rechtekonzept der beA-Anwendung umgangen werden und auf teilweise sensible Metadaten von Nachrichten-Anhängen Dritter zugegriffen werden kann. Für die Konfiguration der Transportsicherung wurde Verbesserungsbedarf er- kannt. Die Übernahme einer Benutzersitzung innerhalb der beA-Anwendung wird durch ein potenzielles Abspeichern der Sitzungsinformationen in Log-Dateien er- leichtert. Zudem konnte festgestellt werden, dass der beA-Anwendungsserver unau- torisiert als globale „Drop-Box" für beliebige Inhalte missbraucht werden kann. In der zweiten Analysephase konnten weitere Schwachstellen identifiziert werden. Die Implementierungen einiger Webservices zeigten sich anfällig für Signature- Wrapping-Schwachstellen, die einem Man-in-the-Mddle-Angreifer das Manipulieren der übertragenen Daten ermöglichen können. Das kann z . B. dazu führen, dass die Gültigkeit von qualifizierten Signaturen falsch angezeigt wird. Der RAK-Client, als auch der entsprechende Server bzw. Webservice, mit dem bidirektional Dateien ausgetauscht werden können, sind verwundbar für sogenannte Path-Traversal- Angriffe. Diese können es Angreifern durch Manipulation der innerhalb einer TLS- Verbindung übertragenen Parameter und Attachments erlauben, beliebige Dateien an beliebigen Speicherorten im Dateisystem des Clients oder des Servers abzule- gen. Dies erlaubt unter Umständen die Übernahme der Kontrolle über den Anwalt PC oder eine betroffenen Server im beA-System. Weiterhin wurde festgestellt, dass innerhalb der Kanzleisoftware-Schnittstelle die Namen von Dateianhängen unver- schlüsselt übertragen werden. Insgesamt wurden in beiden Analysephasen zehn betriebsverhindernde, achtzehn betriebsbehindernde und vierundzwanzig sonstige Schwachstellen identifiziert. Während der zweiten Phase wurden sechs betriebsverhindernde, sechs betriebsbe- hindernde und eine sonstige Schwachstelle behoben und deren Behebung verifi- ziert. Zwei betriebsbehindernde Schwachstellen und eine sonstige Schwachstelle wurden nur teilweise behoben. Eine Schwachstelle bezüglich der Härtung von TLS - Verbindungen wurde nach Rücksprache mit allen Beteiligten aufgrund der aktuellen Entwicklung technischer Standards nicht überprüft. Die weitere Überprüfung beho- bener Schwachstellen ist vorgesehen, wobei darunter mindestens zwei betriebsver- hindernde Schwachstellen offen sind. Version: 1.0                   Stand : 30.05 .2018                                          1 Seite 7

Sicherheitsanalyse secunet 1.3         Ergebnisse Quelltextanalyse Die beA-Anwendung, beA-Client-Security und die BRAV-Search wurden einer werk- zeuggestützten, statischen Quelltextanalyse-Analyse unterzogen. Für die beA- Client-Security wurde darüber hinaus ein Quelltext-Audit vorgenommen, bei dem der als kritisch identifizierte Teile der beA-Client-Security geprüft und der korrekte Programmablauf nachvollzogen wurde. Quelltext-Analyse und -Audit können Schwachstellen in Software erkennen, die mit Werkzeugen des Penetrationstests nicht entdeckt werden können. Die statische Quelltext-Analyse hat in der Summe folgende Treffer mit unterschiedli- chen Einstufungen erbracht: beA-Client-Security 337 Treffer, beA-Anwendung ca. 1000 Treffer und BRAV-SEARCH 85 Treffer. Die Anzahl der Treffer an sich erlaubt keinen Rückschluss auf die Quelltext-Qualität. Die Gewichtung der Treffer erstreckt sich von ,eher' kleineren Unsauberkeiten bis hin zu potentiell gravierend eingestuften f\llängeln. Eine Betrachtung wurde nur von den im verwendeten Analysetool höher eingestuften Treffern vorgenommen. Dabei wurden Schwachstellen gefunden, von denen drei als betriebsverhindernd eingestuft wurden, weil sie potentiellen Angreifer Angriffswege anbieten, die mit be- kannten Techniken ausnutzbar sind und dem Angreifer ermöglichen können, die Kontrolle über die angegriffenen Systeme zu übernehmen. Diese Schwachstellen wurden in der Zwischenzeit beseitigt. Detailliert beschrieben werden die gefundenen Schwachstellen in Kapitel 4. Im Rahmen der Quelltext-Analyse (teilweise unterstützt durch die Penetrationstests) wurden auch die vom Chaos Computer Club e. V. (CCC) bemängelten Schwach- stellen überprüft, die in der vorliegenden Fassung von beA-Client-Security und beA- Anwendung nicht mehr vorhanden sind. 1.4        Ergebnisse konzeptionelle Analyse Gegenstand der konzeptionellen Analyse waren wesentliche Sicherheitsfunktionen des beA, die dem Schutz von Vertraulichkeit und Authentizität der via beA über- mittelten Nachrichten dienen. Es wurde in der ersten Phase geprüft, ob der erforderliche Schutz der Vertraulich- keit der Nachrichten durch das implementierte Verschlüsselungskonzept erreicht wird, das ganz wesentlich darauf beruhen soll, dass alle kryptographischen Operati- onen zum Schutz der Vertraulichkeit von Nachrichten in HSM gekapselt sind und Nachrichten nicht außerhalb der HSM entschlüsselt werden können. Durchgeführt wurde eine Analyse nach Dokumentenlage, insbesondere durch Aus- wertung der relevanten UseCases (Ablaufbeschreibungen für bestimmte fachliche Vorgänge im beA). Des Weiteren wurden das Feinkonzept HSM und andere Fein- konzepte analysiert. Die Ergebnisse der Analyse wurden gemeinsam mit dem Be- treiber und der BRAK im Rahmen von Telefonkonferenzen erörtert und verifiziert. Version : 1.0                  Stand : 30.05 .2018                                             1 Seite 8

Sicherheitsanalyse secunet Durch die Analyse konnten sieben betriebsverhindernde Schwachstellen identifiziert werden, die ein Angreifer ausnutzen kann, um sich unbefugten Zugang zu Nachrich- ten zu verschaffen. Allen Schwachstellen ist gemeinsam, dass die HSM keinen oder keinen ausreichenden Schutz vor diesen Angriffen bieten, d.h. Nachrichten bei er- folgreichem Angriff auch außerhalb der HSM entschlüsselt werden können. Fast al- len konzeptionellen Schwachstellen ist allerdings auch gemeinsam, dass sie nur durch oder mit Hilfe von Innentätern, darunter auch Personen mit besonderer Ver- trauensstellung, durchgeführt werden können. Diese Eigenschaft beschränkt den Kreis potentieller Angreifer neben böswilligen Innentätern auf solche, die über aus- reichende Mttel verfügen, um Innentäter z . B. durch Bestechung zur Mthilfe zu be- wegen. Die Bedrohung ist daher zunächst gering, wächst aber stark, sobald das beA intensiv für den elektronischen Rechtsverkehr genutzt wird und dann viele sehr wertvolle Informationen transportiert und speichert, die einen Angriff mit erheblichen Investitionen bzw. Risiken für Innentäter rechtfertigen. Das mit Blick auf den Schutz der Vertraulichkeit von Nachrichten schwerwiegendste Ergebnis ist, dass alle kryptographischen Schlüssel, die in den HSM verwendet werden, auch außerhalb der HSM bei der BRAK vorliegen bzw. aus diesen Schlüs- seln abgeleitet werden können und dass nicht nachgewiesen wurde, dass dem Be- treiber, der die Schlüssel erzeugt, die Schlüssel nicht auch bekannt sind. Die Schlüssel sollen ausschließlich dazu dienen, bei höherer Last des beA-Systems o- der Ausfall eines HSM weitere HSM für das beA in Betrieb zu nehmen. Doch durch ihre Existenz außerhalb der HSM können sie Gegenstand von missbräuchlicher Nutzung werden, um alle im beA-System gespeicherten Nachrichten auch ohne HSM entschlüsseln zu können. Die Nutzer des beA müssen daher dem Betriebs- personal des beA und der BRAK dahingehend vertrauen , dass diese nicht von der Möglichkeit der Nachrichtenentschlüsselung Gebrauch machen, und müssen darauf vertrauen, dass physikalisch-organisatorische Schutzmaßnahmen hinreichend si- cher sind, um auch einen Mssbrauch durch Dritte auszuschließen . Bei Ende-zu- Ende-Sicherheit ist durch technische Maßnahmen (insbesondere Kryptographie) mit hinreichender Sicherheit ausgeschlossen, dass Dritte Einblick in die übertragenen Nachrichten nehmen können. Das ist beim beA-System nicht der Fall. Daher kann beim beA-System nicht von Ende-zu-Ende-Sicherheit gesprochen werden. Für die Details und die Beschreibung der weiteren konzeptionellen Schwachstellen wird auf den ausführlicheren Statusbericht zur konzeptionellen Analyse verwiesen . Alle Schwachstellen scheinen behebbar. In der zweiten Phase der konzeptionellen Analyse wurden vom Betreiber neu er- stellte Konzepte begutachtet, z. B. Kryptokonzept, Betriebshandbuch und verschie- dene Sicherheitskonzepte. Die vorgelegten Dokumente sind einzeln und in ihrer Gesamtheit nicht geeignet, die Sicherheit der beA-Anwendung nachzuweisen. Die Dokumentenlage wird als betriebsbehindernd eingeschätzt. Version: 1.0                  Stand : 30.05 .2018                                          1 Seite 9

Sicherheitsanalyse secunet 1.5         Resümee und Empfehlung Im Rahmen der Analyse wurden die wichtigsten Komponenten, Schnittstellen, An- wendungsfälle und vorliegenden Dokumente berücksichtigt. Die Bewertung der ge- fundenen Schwachstellen erfolgt, wie in der BRAK praktiziert, in den drei Stufen „betriebsverhindernd", „betriebsbehindernd" und „sonstige": A-Betriebsverhindernde Schwachstelle Die Behebung l.()r Wiederinbetriebnahme wird dringend empfohlen. B-Betriebsbehindernde Schwachstelle Die Behebung l.()r Wiederinbetriebnahme oder sehr zeitnah danach wird empfohlen. C-Sonstige Schwachstelle Lediglich unerhebliche Auswirkung auf den Betrieb, eine Behebung kann später erfolgen. Im Rahmen der Penetrationstests wurden insgesamt 52 Schwachstellen gefunden. Davon wurden zehn Schwachstellen als betriebsverhindemd und 18 als betriebsbe- hindernd klassifiziert. Davon konnten zum Zeitpunkt des Gutachtens fünf betriebs- verhindernde und vier betriebsbehindernde Schwachstellen nach Behandlung durch den Betreiber erneut getestet und als geschlossen festgestellt werden. Innerhalb der Quellcodeanalysen wurden insgesamt zehn Schwachstellen gefun- den. Davon wurden drei Schwachstellen als betriebsverhindemd und sechs als be- triebsbehindernd klassifiziert. Davon konnten zum Zeitpunkt des Gutachtens alle betriebsverhindernden Schwachstellen nach Behandlung durch den Betreiber er- neut getestet und als geschlossen festgestellt werden. Die konzeptionelle Analyse hat sieben betriebsbehindernde Schwachstellen aufge- zeigt. Zusätzlich hat sich die sicherheitsrelevante Dokumentation als unzureichend für die abschließende Beurteilung der IT-Sicherheit erwiesen. Insbesondere auf Grundlage der identifizierten betriebsverhindernden Schwachstel- len wird empfohlen, die beA-Anwendung erst nach deren vollständiger Beseitigung wieder in Betrieb zu nehmen. Darüber hinaus empfehlen wir ebenfalls, die als „betriebsbehindernd" eingestuften Schwachstellen vor Wiederinbetriebnahme bzw. recht zeitnah danach zu beheben. Dieser Empfehlung liegen folgende Überlegungen zugrunde: •    Insbesondere die im Rahmen der Penetrationstests und Quellcodeanaly- sen identifizierten Schwachstellen können auch durch außenstehende Drit- te identifiziert und ggf. ausgenutzt werden. •    Besonders einzelne konzeptionelle Schwachstellen, obwohl als betriebs- behindernd eingestuft sind unter dem Blickwinkel einer flächendeckenden, intensiven und ggf. zukünftig verpflichtenden Nutzung des beA und der damit einhergehenden vorübergehenden zentralen Speicherung sehr um- Version : 1.0                     Stand : 30.05.2018                                            1 Seite 10