Donnerstag, 11. Januar 2018

Erwiderung auf das Rundschreiben der RAK Nürnberg vom 11.01.2018



Werter Hr. Link,


ich habe Ihr aktuelles Rundschreiben vom 11.01. vorliegen und möchte aus
meiner Sicht als IT-Berater, der schon 2013 Konzepte für ein ähnliches
System (für die BNotK) erarbeitet hat, darauf eingehen:

1. Ihre Formulierung zum zweiten Zertifikat "ebenfalls fehlerhaft" ist
   leider sehr verkürzt und wird dem Ausmaß nicht gerecht:

Man könnte den Eindruck gewinnen, hier wurde lediglich der erste Fehler
wiederholt, dh. die bisherige (nun schon über Jahre vorhandene) Lücke
nicht repariert. Die unangenehme Wahrheit ist aber, daß nun (sofern die
Nutzer die Anleitung der BRAK befolgt und der Zertifikat eingespielt
haben) eine noch viel fatalere Lücke hinzugefügt: nun wurde gleich die
gesamte Verschlüsselung für alle Websites, aber auch andere Dinge wie
zB. eMail, Software-Updates, etc. komplett ausgehebelt. Somit haben
Angreifer nun zB. die Möglichkeit, sich permanent auf den Anwalts-PCs
einzunisten und die Kontrolle zu übernehmen - hier helfen auch keine
Virenscanner mehr !

Stellen Sie sich vor, beim Versuch einer Reparatur am Briefkasten wurde
nun auch das Schloß Ihrer Kanzleitür ausgebaut. Die Konsequenzen können
Sie sich sicher vorstellen.

Hier muß ich auch mit der BRAK hart ins Gericht gehen: eine Anleitung,
welche explizit technisch Unkundige dazu auffordert, eindringliche
Warnungen zu umgehen, scheint mir doch grob fahrlässig. Würde mir mein
Anwalt empfehlen, bewaffnet im Gerichtssaal zu erscheinen, dann wäre
ich auch gelinde gesagt äußerst skeptisch.

2. Zum Vergabeverfahren:

Hier wäre ich doch sehr neugierig auf den konkreten Ausschreibungstext,
Vergabekriterien, udgl. In meiner täglichen Arbeit erlebe ich oft, daß
Ausschreibung (ob gewollt oder nicht) schon so aufgebaut sind, daß hier
nur ein bestimmter Anbieter, oder ein technisch schlechtes Konzept zum
Zuge kommen kann.

Gerade bei öffentlichen Projekten derartiger Tragweite und zugleich
technisch nicht versiertem Auftraggeber sehe ich keine andere
praktikable Lösung als regelmäßige _öffentliche_ Begutachtung,
insbesondere auch des Quellcode der Software selbst.

Generell ist IT-Sicherheit mit Geheimhaltung der Konzepte, Verfahren
und Quellcode nicht verträglich - das hat die Praxis seit vielen
Jahrzehnten zahllose Male gezeigt, und selbiges erlebe ich auch
regelmäßig bei meiner Kundschaft.

3. Unternehmensgrößen:

Ihr Schreiben vermittelt den Eindruck, große Unternehmen, hohe Umsätze,
etc, seien ein positiver Indikator für Qualität. Die Praxis beweist das
Gegenteil, und das ist in der soziologischen Forschung bereits gut
aufgearbeitet:

Mit steigender Organisationsgröße - vorallem in Hierarchien - nehmen der
Handlungsspielraum und Motivation der Beteiligten _dramatisch_ ab.
Bereits in unteren Ebenen gewinnt die Sicherung und Verbesserung der
eigenen Position rasch eine höhere Priorität als Qualität der Produkte,
Auf höheren Management-Ebenen ist das faktisch die einzige Tätigkeit.
Solche Organisationen filtern ihr Personal, vorallem in Verantwortungs-
Positionen systemisch nach Konformität zum soziologischen Apparat,
nicht nach fachlichen Leistungen und Begabungen.

Exzellente Experten sind üblicherweise nicht mit solchen soziologischen
Apparaten kompatibel - sofern man sie überhaupt in solchen Apparaten
findet (die überwiegende Mehrheit wird dort nicht lang bleiben), führen
sie ein unbeachtetes Schattendasein, sie werden garnicht erst nicht mit
verantwortungsvollen Aufgaben betraut. Diese Tendenzen sind bereits
im Mittelstand gut sichtbar, in Konzernen ist das Alltag.

Großunternehmen sind also systemisch nicht zu fachlicher/technischer
Exzellenz fähig. Genau diese ist aber für Projekte wie beA dringend
not-wendig.

Der wirtschaftliche Erfolg solcher Unternehmen gründet sich mitnichten
auf technische Kompetenz, sondern an den reinen _Glauben_ der Kundschaft
(bzw. dortiger Entscheider) an solche. Ein religiöser Mechanismus.

3. "beste Referenzen" von ATOS

Hier möchte ich - vorallem mit Hinblick auf og. Problem - deutlichst
hinterfragen, wer besagte Referenzen in welchem konkreten Zusammenhang
ausgestellt hat, und was diese konkret beinhalten.

Der Umstand, daß die ausgelagerte Siemens IT-Abteilung über große und
bekannte Auftraggeber verfügt, sagt über die technische Kompetenz rein
garnichts aus. Siehe oben: die referenzierten Vergabe-Entscheidungen
sind bereits religiös begründet. Und die Entscheider der Kundschaft,
sofern sie überhaupt auf ihren Hierarchieebenen von den tatsächlichen
Problemen erfahren, werden sich aus og. Gründen wohl kaum exponieren
und falsche Entscheidungen öffentlich einräumen - das würde ja ihre
Karriere rasch beenden. Solch abstrakte Referenzen haben somit keine
fachliche bzw. technische Aussagekraft, offenbaren lediglich og.
religiösen Mechanismus.

Aus dem Siemens-Konzern höre regelmäßig von gravierender Inkompetenz
seitens ATOS - sowohl technisch als auch organisatorisch. Analog auch
bei vielen anderen Konzernen.

Anbei sei angemerkt, daß die fatalste Komponente, "beA ClientSecurity",
offenkundig - zumindest zum größten Teil - von BOS/Governikus entwickelt
wurde. Diese sollten wir im Kreis der Verursacher nicht vernachlässigen.


4. Gutachten durch SEC

Das Gutachten unterliegt ja bis heute strikter Geheimhaltung. Schon das
erweckt den Eindruck, daß es hier gravierendes zu verbergen gilt. Das
weitere Festhalten daran, auch nach dem GAU, legt auch den dringenden
Verdacht, daß der BRAK die gravierenden Sicherheitsmängel bekannt waren.

Zudem wird uns weiterhin vorenthalten, worin überhaupt der Auftrag
bestand und was genau geprüft wurde. Eine Hochsicherheitstür nutzt
wenig, wenn sie allein auf freiem Feld steht.

Nach bisherigem öffentlichen Kenntnisstand konnte SEC den Quellcode nicht prüfen. Dabei wäre nämlich das Problem mit dem veröffentlichtem
privaten Schlüssel (im "ClientSecurity") sofort aufgefallen. Desweiteren
wären auch bei einem Blackbox-Test der Web-Anwendung die fatalen XSS-
Lücken rasch aufgefallen - das gehört zu den alltäglichen Standard-
Problemen bei Web-Anwendungen.

Daß nicht schon die Verwendung extrem veralteter Software-Komponenten
(teils über 10 Jahre nicht mehr gepflegt !), kann ich beim besten
Willen nicht nachvollziehen.

Daraus ergeben sich iW. drei Möglichkeiten:

a) die problematischen Punkte wurden überhaupt nicht geprüft, waren
   im Prüfauftrag nicht enthalten
b) die Prüfer sind komplett inkompetent
c) die BRAK hat fatale Mängel vertuscht

Neben den technischen Problemen sind übrigends auch Urheberrechts-
verstöße - inwieweit diese heilbar sind, ist noch zu prüfen.


5. Aufarbeitung:

Wenn Sie Ihr Versprechen einlösen und mit allen zur Verfügung stehenden
Mitteln zur Lösung beitragen möchte, kann ich Ihnen nur dringlich
anraten, auf den folgenden Minimalforderungen zu bestehen:

1. vollständige Offenlegung zwecks öffentliche Begutachtung von:
   * allen Konzept-Dokumenten, incl. Pflichten- und Lastenheft
   * Dokumentation des Entwicklungsprozess
   * Review- und Abnahmeprotokolle
   * Architektur-Dokumentation
   * Konformitätserklärung zu Einhaltung technischer Normen sowie des
     allgemeinen technischen Standes.
   * Quellcode der Software (sowohl Client- als auch Server-Seitig)
   * Sicherheitskonzept (technisch und organisatorisch)
   * Infrastruktur-und Betriebskonzept
   * die benannten externe Gutachten (incl. Abnahmeprotokolle)
   * Prüfprotokolle bzgl. gesetzlicher Normen (BSDG, DSGVO, etc)

2. Hinzuziehung *fachlich geeigneter* unabhängiger technischer Experten,
   welche in keinerlei ökonomischer Beziehung zu den Verantwortlichen
   (zB. ATOS oder BOS/Governikus) stehen - insbesondere auch solche,
   die sich bereits tiefergehend mit dem Problemkomplex EGVP/beA
   auseinander gesetzt und ähnliche Lösungen entwickelt haben.

3. Dauerhafte Einbindung der einzelnen RAK'en, DAV-IT, sowie der
   IT-Sicherheitsforschung (Universäten, CCC, etc).


Abschließend bleibe ich bei meiner Darstellung in der LTO:
Das beA ist ein Totalschaden - wir müssen von Grund auf neu beginnen.


Sollten Sie Fragen haben, stehen ich auch gern kurzfristig für eine
fernmündliche Konsultation zur Verfügung.


mit freundlichen Grüßen

Keine Kommentare:

Kommentar veröffentlichen