Technische Analyse und Konzeptprüfung des beA 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 geprüft, ob der erforderliche Schutz der Vertraulichkeit der Nachrichten durch das implementierte Verschlüsselungsverfahren erreicht wird, so dass alle kryptographischen Operationen zum Schutz der Vertraulichkeit von Nachrichten in HSM gekapselt sind und Nachrichten nicht außerhalb der HSM entschlüsselt wer- den können. Durchgeführt wurde eine Analyse nach Dokumentenlage, insbesondere durch Aus- wertung der relevanten Use-Cases (Ablaufbeschreibungen für bestimmte fachliche Vorgänge im beA). Des Weiteren wurden vorgelegte Feinkonzepte (vor allem zum Gesamtsystem, zur HSM-Verwendung und zur beA-Client-Security) analysiert. Die Ergebnisse der Analyse wurden gemeinsam mit dem Betreiber und dem Auftragge- ber im Rahmen von Telefonkonferenzen erörtert und verifiziert. Grundsätzlich ist das dem beA zugrundeliegende Verschlüsselungskonzept geeig- net, die Vertraulichkeit der Nachrichten während der Übertragung und Speicherung von Nachrichten durch das beA zu gewährleisten, auch gegenüber dem Betreiber des beA. Nachrichteninhalte liegen unverschlüsselt nur bei den Kommunikations- partnern vor. Die Umverschlüsselung ist in einem HSM gekapselt, schützt daher dort vorübergehend entstehende Schlüsselinformationen in einer besonderen mani- pulations- und ausspähsicheren Umgebung. Das erkennbare Ziel, die Sicherheit der Nachrichten ausschließlich durch Kryptographie zu schützen, ist aber nicht in vollem Umfang erreicht worden. An einigen Stellen verlässt sich das beA in seiner dem Gutachten zugrunde liegenden Realisierung auf organisatorisch-physikalischen Schutz wichtiger Systemkomponenten (HSM-Schlüssel, SAFE BRAK), was bei vol- ler Ausnutzung der kryptographischen Möglichkeiten, die das Konzept und die ein- gesetzte Technik bieten, nicht notwendig wäre. Durch die Analyse konnten aus technischer Sicht zwei betriebsverhindernde, drei betriebsbehindernde und zwei sonstige Schwachstellen identifiziert werden, die ein Angreifer ausnutzen kann, um sich trotz des kryptographischen Schutzes unbefug- ten Zugang zu Nachrichten zu verschaffen. Allen Schwachstellen ist gemeinsam, dass das HSM keinen oder keinen ausrei- chenden Schutz vor diesen Angriffen bietet, d.h. Nachrichten bei erfolgreichem An- griff auch außerhalb des HSM entschlüsselt oder dem HSM Leseberechtigungen vorgetäuscht werden können. Fast allen konzeptionellen Schwachstellen ist aller- dings auch gemeinsam, dass sie nur durch oder mit Hilfe von Innentätern, darunter auch Personen mit besonderer Vertrauensstellung, durchgeführt werden können, die dabei physikalisch-organisatorische Schutzmaßnahmen unterlaufen müssen. Außentäter können sich in die Position eines Innentäters bringen, wenn es ihnen ge- lingt, durch Ausnutzung von Schwachstellen der Serverkomponenten in diese ein- zudringen und die Kontrolle über sie zu übernehmen. Nur in einem Fall, einer Version: 1.0                  Stand: 18.06.2018                                               Seite 11

Technische Analyse und Konzeptprüfung des beA Täuschung eines beA-Anwenders mittels einer irreführenden EGVP-Adresse, ist auch ein Angriff durch einen Außentäter denkbar, der dafür die beA-Anwendung nicht angreifen muss. Die Ausnutzbarkeit der Schwachstellen ist in der Regel auf- grund des eingeschränkten Täterkreises und einer angenommenen geringen Moti- vation und besseren Überwachbarkeit von Innentätern gering. Die konzeptionellen Schwachstellen erhalten ihre Bedeutung in der Regel durch ihr hohes (teilweise sehr hohes) Schadenspotential. Betriebsverhindernd bewertet ist, dass Verschlüsselungszertifikate in der beA- Client-Security vor dem Versand von Nachrichten nicht geprüft werden. Dadurch verlieren die Zertifikate ihre Schutzwirkung, die beA-Client-Security kann durch ge- fälschte Zertifikate leicht getäuscht werden, und versendet dann Nachrichten lesbar für einen Angreifer. Betriebsverhindernd bewertet wird auch, dass die Integrität des Javascript-Codes, mit dem die beA-Client-Security gesteuert wird, nicht gewährleis- tet ist. Es besteht die Gefahr, dass durch böswillig manipulierten Javascript-Code bei allen beA-Anwendern Nachrichten im Klartext an einen Angreifer ausgeleitet werden. Für die Details der konzeptionellen Schwachstellen wird auf die Analyse in Kapitel 5 verwiesen. Im Rahmen der Gutachtenerstellung wurden vom Betreiber für alle be- schriebenen Schwachstellen Lösungsvorschläge unterbreitet und teilweise aus Gut- achtersicht bewertet. Alle Schwachstellen erscheinen grundsätzlich behebbar, allerdings mit unterschiedlichem Aufwand. Die betrachteten Signatur- und Signaturprüffunktionen des beA wurden ebenfalls untersucht. In diesem Bereich wurde keine konzeptionelle Schwachstelle gefunden. Auch die Authentisierungsfunktionen für den Zugriff auf ein Postfach und die Ver- waltung der Administrations- und Leserechte sind angemessen konzipiert. Die vom Betreiber vorgelegte Dokumentation zum Nachweis des sicheren IT- Betriebs des beA belegt einen geregelten, auch den Aspekt IT-Sicherheit beachten- den Betrieb. Grundlage ist ein ISO-27001-zertifiziertes Informationssicherheitsma- nagement. Erkennbar adressiert wird auch der besondere Schutzbedarf des beA. Es fehlt aber für das beA ein geschlossenes Sicherheitskonzept mit Begleitdoku- menten, das basierend auf einer Bedrohungs- und Risikoanalyse einen Nachweis darüber führt, dass allen Risiken für die hoch schutzbedürftigen Daten und IT- Systeme des beA in ausreichendem Maße entgegengewirkt wird. Dadurch war es nicht möglich, sich von der physikalisch-organisatorischen Sicherheit des beA und der vollständigen Abwehr aller nicht tragbaren Risiken zu überzeugen. Es wird emp- fohlen, ein Sicherheitskonzept und Begleitdokumente nach üblichem Muster zu er- stellen, die die fehlenden Teile enthalten und vorhandene Informationen über Sicherheitsmaßnahmen bündeln, um sowohl den Vollständigkeitsnachweis über die Abwehr aller Risiken zu führen als auch eine Grundlage für ein Sicherheits-Audit be- reitzustellen. Außerdem sollte ein unabhängiger Auditor den sicheren Betrieb des beA regelmäßig überprüfen. Dies kann als ergänzendes Audit zum bereits regelmä- ßigen stattfindenden ISO-27001-Audit geschehen. Version: 1.0                   Stand: 18.06.2018                                               Seite 12

Technische Analyse und Konzeptprüfung des beA 1.5       Resümee und Empfehlung Im Rahmen der Penetrationstests wurden insgesamt 36 Schwachstellen gefunden. Davon wurden vier Schwachstellen als betriebsverhindernd und 13 als betriebsbe- hindernd klassifiziert. Von diesen konnten zum Stichtag zwei betriebsverhindernde und vier betriebsbehindernde Schwachstellen nach Bearbeitung durch den Betreiber erneut getestet und als geschlossen festgestellt werden. Im Rahmen der Quellcodeanalysen wurden insgesamt zehn Schwachstellen gefun- den. Davon wurden sechs Schwachstellen als betriebsverhindernd und vier als be- triebsbehindernd klassifiziert. Bis zum Stichtag konnten alle betriebsverhindernden Schwachstellen nach Behandlung durch den Betreiber erneut getestet und als ge- schlossen festgestellt werden. Die konzeptionelle Analyse hat zwei betriebsverhindernde, drei betriebsbehindernde und zwei sonstige Schwachstellen aufgezeigt. Besonders problematisch sind hier der unsichere Umgang mit Verschlüsselungszertifikaten in der beA-Client-Security sowie die Verwendung von Javascript zur Steuerung der beA-Client-Security. Es wurde auch Verbesserungsbedarf bei der Dokumentation und der Kontrolle des si- cheren Betriebs erkannt. Grundsätzlich ist das beA ein geeignetes System zur vertraulichen Kommunikation im elektronischen Rechtsverkehr. Das Verschlüsselungskonzept bietet technisch gesehen einen hinreichenden Schutz für die Vertraulichkeit der vom beA übermittel- ten Nachrichten. Nicht tragbare Risiken, die noch bestehen, können beseitigt wer- den und sind teilweise auch schon beseitigt worden. Die erneute Inbetriebnahme ist bei Beachtung der folgenden Empfehlungen aus sicherheitstechnischer Sicht mög- lich. Für die noch nicht behobenen betriebsverhindernden Schwachstellen wird empfoh- len, 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 baldmöglichst zu beheben. Für den nachhaltig sicheren Betrieb des beA wird empfohlen, ein Sicherheitskon- zept, ein Kryptokonzept und ein Konzept für die Behandlung von Sicherheitsvorfäl- len in üblicher Form und Inhalt zu erstellen, bzw. vorhandene relevante Dokumente hier per Verweis einzubetten und auf der Grundlage dieser Dokumente ein regel- mäßiges Audit des ordnungsgemäßen Betriebs durchzuführen. Dies kann in Ergän- zung des regelmäßigen ISO-27001-Audits des Betreibers im gleichen Rhythmus geschehen. Version: 1.0                  Stand: 18.06.2018                                               Seite 13

Technische Analyse und Konzeptprüfung des beA 1.6       Abgrenzung Bei der Lektüre und Nutzung dieses Gutachtens sind folgende Hinweise zu berück- sichtigen: ■  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-System erforderlichen technischen Komponenten, Schnittstellen oder Anwendungsfälle betrachtet. Es kann somit nicht vollständig ausgeschlos- sen werden, 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. Zu berücksichtigen ist auch, dass die konzeptionelle Analyse sich auf die Sicherheitsziele „Vertraulichkeit“ und „Authentizität“ konzentriert hat und somit insbesondere eine Betrachtung der „Verfügbarkeit“ nur dort erfolgte, wo eine gefundene Schwachstelle diese unmittelbar bedroht. Innerhalb der technischen Analysen standen die beA-Client-Security, die beA- Anwendung und externe Schnittstellen im Fokus. ■  Die vorgelegten grundlegenden Konzepte zur IT-Sicherheit (Sicherheits- konzept, Kryptokonzept etc.) ermöglichten keine abschließende Einschät- zung der technisch-organisatorischen Sicherheit des beA. Das Ausnutzen einzelner identifizierter Schwachstellen kann eventuell durch geeignete technische und organisatorische Maßnahmen – seitens des Auftraggebers oder des Betreibers – deutlich erschwert oder sogar vereitelt werden. Um- gekehrt können aber auch Schäden durch fehlende bzw. ungeeignete technische und/oder organisatorische Maßnahmen entstehen, die erst bei einer Vollständigkeitsprüfung, wie sie im Rahmen der Erstellung eines ge- schlossenen Sicherheitskonzeptes durchzuführen wäre, auffallen. Ein sol- ches Sicherheitskonzept liegt nicht vor. Es war nicht Gutachterauftrag, ein solches Konzept auf der Basis der vorgelegten Informationen und Doku- mente zu erstellen. ■  Darüber hinaus war es erforderlich, Annahmen zu treffen und Abgrenzun- gen des Betrachtungsgegenstandes vorzunehmen, damit der Aufwand ins- gesamt vertretbar blieb. So wurde angenommen, dass der Anwaltsrechner eine sichere Einsatzumgebung für den Einsatz der beA-Client-Security darstellt und frei von Schadsoftware ist. Die Absicherung des Anwaltsrech- ners sowie der Einsatzumgebung war dementsprechend nicht Gegenstand der Untersuchung. Version: 1.0                   Stand: 18.06.2018                                               Seite 14

Technische Analyse und Konzeptprüfung des beA ■ Eine Analyse, ob das beA-System alle rechtlichen und über die Sicherheit hinausgehenden funktionalen Anforderungen erfüllt, war nicht Gegenstand der Betrachtung. ■ Es ist möglich, dass einzelne identifizierte Schwachstellen von Dritten nachvollzogen und ausgenutzt werden können, auch wenn sie bereits be- hoben wurden, z. B. bei nicht erfolgter Deinstallation älterer Versionen der beA-Client-Security. Außerdem könnten durch die Darstellung von detail- lierten technischen Informationen Rechte Dritter verletzt werden, z.B. durch Angabe von Quellcode, oder schützenswerte Informationen aufgedeckt werden, wie z.B. IP-Adressen. Aus diesem Grund werden die Schwachstel- len in diesem, zur Veröffentlichung vorgesehenen Gutachten, ohne Angabe von detaillierten technischen Informationen dargestellt. Die detaillierten technischen und inhaltlichen Informationen zu den einzelnen Schwachstel- len werden zu deren gezielter Behebung laufend an den Auftraggeber übermittelt. Version: 1.0              Stand: 18.06.2018                                               Seite 15

Technische Analyse und Konzeptprüfung des beA 2         Verfahren zur Schwachstellenbewertung In diesem Kapitel wird beschrieben, wie gefundene Schwachstellen in den folgen- den Kapiteln dargestellt werden und auf welche Art und Weise sie in Risikostufen eingeordnet worden sind. 2.1       Darstellungsform Bei der Beschreibung und Bewertung der identifizierten Schwachstellen wurde die folgende Darstellungsform gewählt. {S1}         Schwachstellenbeschreibung Beschreibung der Schwachstelle {R1}         Risikobewertung:                Einstufung in Risikokategorie (A, B, C) Ausnutzbarkeit der Schwachstelle: Bewertung der Ausnutzbarkeit gemäß Kriterien, die noch erläutert wer- den Bewertung Ausnutzbarkeit:              hoch, mittel oder niedrig Bewertung der Bedrohung: Beschreibung des Schadens eines Angriffs auf diese Schwachstelle im Erfolgsfall, Einstufung des Schadensausmaß in den drei Schutzziele Integrität, Vertraulichkeit, Verfügbarkeit gemäß Kriterien, die noch er- läutert werden Bedrohung Integrität:                  hoch, mittel oder niedrig Bedrohung Verfügbarkeit:               hoch, mittel oder niedrig Bedrohung Vertraulichkeit:             hoch, mittel oder niedrig {M1}         Maßnahmenempfehlung, Darstellung, auf welche Weise die Schwach- stelle beseitigt werden könnte Die Beschreibung der identifizierten Schwachstellen setzt sich aus den drei Kompo- nenten Schwachstelle {S}, Risiko {R} und Maßnahme {M} mit einer zugehörigen eindeutigen Nummer zusammen. Die Schwachstellen der Kategorie C-Sonstige Schwachstellehaben geringe Aus- wirkung auf die Schutzziele und eine Behebung erscheint nicht zeitkritisch. Aufgrund der damit zusammenhängenden geringeren Relevanz für die Sicherheit des beA- Version: 1.0                  Stand: 18.06.2018                                               Seite 16

Technische Analyse und Konzeptprüfung des beA Systems, wurden diese in übersichtlicher tabellarischer Form aufgelistet. In der Ta- belle sind zusätzlich die Ergebnisse der einstufungsrelevanten Bewertungen hin- sichtlich Ausnutzbarkeit und Bedrohungen zu finden. Tabelle 1: Darstellungsform C-Schwachstellen Legende: h=hoch; m=mittel; n=niedrig; J=Ja                                                           Bedrohung Ausnutzbarkeit Schwachstelle Vertraulichkeit                Verfügbarkeit Integrität                    behoben Kurzbeschreibung                                              Komponente Die REST-API des Wikis ist öffentlich erreichbar und          Webportal       m                   n               n             n                - stellt teilweise sensible Informationen bereit, die für den   XWIKI Anwendungszweck des Wikis nicht benötigt werden. 2.2       Schwachstelle Der Bereich Schwachstelle beschreibt die identifizierte Schwachstelle. Zusätzliche Erläuterungen zum Verständnis der Schwachstelle finden sich in der Regel in einem der strukturierten Bewertung vorangestellten Fließtext. Zusätzlich werden (falls ver- fügbar und relevant) zu den identifizierten Schwachstellen die zugehörigen Common Vulnerabilities and Exposure (CVE) IDs aufgeführt. Bei CVE handelt es sich um ei- nen Industriestandard, der eine einheitliche Namenskonvention für Sicherheitslü- cken    und      andere   Schwachstellen      in  Computersystemen       bereitstellt. Mehrfachbenennungen gleicher Gefahren werden um eine laufende Nummer (z. B. CVE-2006-3086) ergänzt, um eine eindeutige Identifizierung der Schwachstellen zu gewährleisten. Dadurch ist ein reibungsloser Informationsaustausch zwischen den verschiedenen Datenbanken einzelner Hersteller möglich. Basierend auf den CVE- IDs können auf der Web-Seite http://cvedetails.com/ weiterführende Informationen zu der Schwachstelle nachgelesen werden. 2.3       Risikobewertung Der Bereich Risikobewertung stellt das geschätzte Risiko dar, welches durch das Vorhandensein der Schwachstelle hervorgerufen wird. Zur Einschätzung des Risi- kos werden zum einen die Ausnutzbarkeit der Schwachstelle sowie die Bedrohung (die im Erfolgsfall des Angriffs eintretenden Schäden) bewertet. Version: 1.0                     Stand: 18.06.2018                                                                                                   Seite 17

Technische Analyse und Konzeptprüfung des beA 2.3.1     Ausnutzbarkeit Nach kurzen Erläuterungen zur Ausnutzbarkeit der Schwachstelle wird diese in die Klassen hoch, mittel und niedrig eingestuft. Beispiele für ausgewählte Fragestellungen, anhand derer die Einstufung der Aus- nutzbarkeit erfolgt, sowie diesbezügliche Kriterien für eine Einstufung sind in der fol- genden Tabelle dargestellt. Tabelle 2: Beispielkriterien zur Bestimmung der Ausnutzbarkeit Beispiele für Kriterien zur Bestimmung der Ausnutzbarkeit Fragestellung                    hoch                        mittel                      niedrig (Auswahl) Auf welchem Wege     Der Angriff ist durch        Ein berechtigter Zugriff auf Die Schwachstelle kann kann ein Angriff     direkten Zugriff aus dem     den lokalen Rechner des nur durch Innentäter durchgeführt         Internet möglich. Er         Anwalts oder Server ist      ausgenutzt werden. werden?              erfordert kein Spezialwis-   erforderlich. sen. Wie komplex ist die Die Ausnutzung ist mit        Es müssen nur wenige         Für die Ausnutzung der Durchführung des geringem technischem             Sicherheitsmaßnahmen         Schwachstelle müssen Angriffs?            und zeitlichem Aufwand       überwunden werden.           vorab verschiedene möglich.                                                  Sicherheitsmaßnahmen Die Schwachstelle lässt      überwunden werden. Für die Ausnutzung der       sich mit verhältnismäßigen Schwachstelle ist geringer Mitteln Ausnutzen.             Das Ausnutzen der Fachverstand erforderlich.                                Schwachstelle ist nur mit unverhältnismäßig Informationen zum                                         hohem Aufwand Nutzen der Schwachstelle                                  möglich. sind frei verfügbar. Welche Rechte        Der Angriff ist nicht durch  Für die Ausnutzung der       Es sind administrative sind für den Angriff eine Rechteprüfung           Schwachstelle sind           Berechtigungen erforderlich?        behindert.                   Zugriffsberechtigungen       erforderlich. erforderlich. Sind bei einen       Der Angriff kann ohne        Für den Angriff ist ein      Der Zugriff ist nur im 4- Angriff Nutzerinter- Mitwirkung eine Nutzers      aktives Handeln des          Augenprinzip möglich aktionen erforder-   oder Administrators          Nutzers erforderlich lich?                durchgeführt werden.         (Eingaben, Mausklick etc.). 2.3.2     Bedrohung Im Bereich Bedrohung werden die im Erfolgsfall des Angriffs eintretenden Schäden allgemein bewertet. Die Bewertung erfolgt dabei für die Schutzziele Integrität (kön- nen Daten unberechtigt verändert werden), die Verfügbarkeit (kann die Erreichbar- keit eines Systems / Dienstes eingeschränkt werden) und die Vertraulichkeit (kann ein Unberechtigter auf die Daten lesend zugreifen). Pro Kategorie werden die Klas- sen hoch, mittel und niedrig unterschieden, die angeben, wie kritisch der jeweilige Schaden eingeschätzt wird. Version: 1.0                      Stand: 18.06.2018                                                            Seite 18

Technische Analyse und Konzeptprüfung des beA Einen besonderen Stellenwert bei der Betrachtung hat die Vertraulichkeit der Nach- richteninhalte und sonstiger sensibler Informationen zu Mandatsinhalten. Dies ist insbesondere auf die möglichen sensiblen Nachrichteninhalte in Verbindung mit der erforderlichen anwaltlichen Verschwiegenheitspflicht zurückzuführen. In die Beurteilung der Bedrohungen für die Integrität wurde ebenso das Schutzziel Authentizität (die Echtheit, Zuverlässigkeit und Glaubwürdigkeit einer Mitteilung, ein vertrauenswürdiger Identitätsnachweis) einbezogen. In die Bewertung der Integrität fließt ebenfalls die Bedrohung einer Übernahme der Kontrolle einer beA- Teilkomponente durch einen Angreifer ein (Störung der Systemintegrität). Exemplarische Kriterien zur Einstufung der Bedrohung des jeweiligen Schutzziels in die Kategorien „hoch“, „mittel“ und „niedrig“ werden in den nachfolgenden Tabellen dargelegt. Tabelle 3: Einstufung Vertraulichkeit Einstufung zum Schutzziel     Beispiele für Bedrohungen Vertraulichkeit      ■    Unberechtigte können Einblick in den Klartext von Nach- richten nehmen. Der Angreifer kann frei wählen, welche hoch Nachrichten er lesen kann. ■    Sensible schützenswerte Informationen können unbe- rechtigt gelesen werden (Inhalte der Nachrichtenanhän- ge im Klartext, Metadaten mit vertraulichen Inhalten) ■    Administrative/technische Informationen (Passwörter), die einen gezielten Angriff direkt ermöglichen, liegen un- berechtigt vor Vertraulichkeit      ■    Unberechtigte können Einblick in den Klartext von Nach- richten nehmen. Bei der Auswahl der Nachrichten ist der mittel Angreifer auf maximal ein Postfach eines beA- Anwenders beschränkt. ■    Metadaten zu Nachrichtenanhängen, die Rückschlüsse auf die sensiblen Nachrichteninhalte ermöglichen kön- nen unberechtigt gelesen werden Vertraulichkeit      ■    Metadaten/Informationen/Fehlermeldungen oder sonsti- ge Systeminformationen mit geringem Informationsge- niedrig halt zum Auffinden oder Ausnutzen von Schwachstellen sind betroffen. Version: 1.0                  Stand: 18.06.2018                                                Seite 19

Technische Analyse und Konzeptprüfung des beA Tabelle 4: Einstufung Integrität Einstufung zum Schutzziel      Beispiele für Bedrohungen Integrität         ■   Der Angreifer kann die komplette Kontrolle über eine hoch                 beA-Systemkomponente übernehmen. ■   Der Urheber einer Nachricht kann beliebig verfälscht werden ■   Die Gültigkeitsinformation über qualifizierte Signaturen kann verfälscht werden. ■   Wichtige Sicherheitsfunktionen können deaktiviert wer- den, zum Beispiel können signierte Daten verfälscht werden. Integrität         ■   Daten können nur im eingeschränkten Maße geändert mittel               werden. ■   Der Angreifer kann mit der Identität eines Anderen in der beA-Anwendung agieren ■   Eine teilweise Übernahme zentraler Komponenten oder Systeme erscheint möglich. Ein unberechtigter Einblick in vertrauliche Informationen oder ein Ausfall des beA- Systems scheint jedoch nicht möglich. ■   Der Anwender kann Funktionen nutzen oder missbrau- chen, zu denen er nicht berechtigt ist. Integrität         ■   Integrität ist nicht betroffen oder die Änderungen haben niedrig               keine oder kaum Konsequenzen für den Betrieb auf dem Zielsystem. ■   Es enstehen keine unmittelbaren Konsequenzen für an- dere Systemkomponenten. ■   Ein System stellt kein attraktives Angriffsziel dar, da der mögliche Gewinn aus einer Integritätsstörung gering o- der gar nicht erkennbar ist. Version: 1.0                 Stand: 18.06.2018                                                 Seite 20