Page 71

BIT 02-2015

BIT 2–2015 | 71 ren und der Prüfung nicht scan-relevanter Komponenten (siehe unten) exorbitant aufwendiger. Eine lückenlose Schutzfunktion gäbe es nur, wenn der Absender ein elektronisches Dokument (nicht Papier) mit seiner qualifizierten Signatur versieht. Aber darüber reden wir hier nicht. Und leider sind wir im Hochtechnologieland Deutschland auch nach über 17 Jahren Signaturgesetz noch immer nicht so weit, dass wir Signaturfunktionen für solche gerichtsbelastbaren Authentifizierungsfunk - tionen flächendeckend und für jedermann preiswert verfügbar und simpel anwendbar einsetzen können. Aber dieses Trauerspiel ist eine ganz andere Geschichte. Im Zusammenhang mit Resiscan reden wir über das ersetzende Scannen analoger Dokumente, nicht über vom Absender qualifiziert signierte Dokumente. Enormer Aufwand, wenig Nutzen Um die Frage nach dem Nutzen zu beantworten: Derzeit sehe ich keine rechtlich bessere Position und daher auch keinen Nutzen im Vergleich zu bisherigen Verfahren. Ein weiterer Kritikpunkt ist der extreme Aufwand, den die TR-Resiscan verursacht, wenn man den Text ernst nimmt und Punkt für Punkt durcharbeitet. Auch hier wieder nur ein Beispiel von vielen: jede Dokumentenart muss auf ihren Schutzbedarf überprüft werden und zwar für sechs unterschiedliche Datenobjekte: Original, Scan-Produkt, Index- und Metadaten, Transfervermerk, Sicherungsdaten und Protokolldaten. Jedes dieser sechs Datenobjekte ist im Hinblick auf neun Sicherheitsziele zu bewerten: Integrität, Authentizität, Vollständigkeit, Nachvollziehbarkeit, Verfügbarkeit, Lesbarkeit, Verkehrs - fähigkeit, Vertraulichkeit, Löschbarkeit. Also eine Ausarbeitung zu 54 Einzelaspekten je Dokumentenart. In einem Unternehmen mit fünf oder zehn Abteilungen und jede mit fünf bis zehn Dokumentenarten müssen hier Tausende von Einzelaspekten im Team erarbeitet und in der Resiscan konformen Schutzbedarfsanalyse niedergelegt werden. Das ist alles andere als trivial: Ich freue mich auf Diskussionen in den Projekt-Teams, wenn (wiederum nur ein Beispiel) der Aspekt des Sicherheitsziels „Authentizität“ des Datenobjektes „Metadaten“ diskutiert wird. Bereits bei diesem Punkt gibt es weitere Verzweigungen: Die Meta - daten kommen ja immer auf die gleiche Weise, sondern per Barcode, per Verknüpfung mit Fachanwendungen per automatischer oder manueller Indexierung, im Laufe eines Vorgangs und nicht schon zu Beginn und so weiter. Das wäre dann für jede Dokumentenart, jeden Prozess und jeden Bereich separat zu analysieren und im Team und mit den Resiscan-Experten abzustimmen. Spätestens an dieser Stelle wird in der Detailarbeit klar werden, dass nicht klar ist, was gemeint ist und dass jeder eine eigene Interpretation hat. Und das 54 mal je Dokumentenart. Man kann nicht einfach Dokumente mit dem gesunden Menschenverstand in eine auf den ersten Blick passende Schutzklasse legen, weil damit ganz erhebliche technische und funktionale Konseqenzen für die Lösung verbunden sind. Damit aber nicht genug – diese Einstufung und die Ableitung der Schutzmaßnahmen gilt dann auch für die technische Infrastruktur: Scanner, Server, Scan-Arbeitsplätze bis ganz tief unter der Haube, wo z. B. gemäß Anlage A, Kapitel A.1.5 auch die neun Kommunikationsverbindungen eines typischen Scan-Systems gehören, also auch die Kommunikationswege zwischen externer Integritätssicherungs Hardware und der internen Intergritätssicherungs-SW, dem Scan- Cache etc. Und ob man dann endlich Resi - scan-konform ist, erfährt man natürlich erst nach einer kostenpflichtigen Zertifizierung durch neutrale Dritte (so die Empfehlung in der TR). Wer käme dafür wohl in Frage? Und bei Schutzbedarf „hoch“ und „sehr hoch“ ist das alle 36 Monate zu wiederholen. Aufwendige Umsetzung der Richtlinie Mit anderen Worten: Die Umsetzung der Resiscan wird extrem aufwendig, wenn man sie ernst nimmt. Alleine der Aufwand, die Richtlinie mit allen Anhängen und Verweisen (BSI Grundschutz, TR-Esor, Common Critieria) zu lesen und einen Umsetzungskonsens zu erzielen, stellt ein Projekt dar. Hinzu kommt, dass sie in vielen Aspekten unklar formuliert ist und sich hierdurch ein sehr hoher Interpretationsspielraum ergibt, z. B. bei Formulierungen wie „Die Größe der Stichprobe soll abhängig vom Schutzbedarf der gescannten Dokumente und der Zuverlässigkeit des Scan-Systems bestimmt werden“. Oder man macht es oberflächlich, um den Aufwand zu redu - zieren, aber wozu taugt dann eine Zertifizerung, die einen nach unseren Schätzungen dreistelligen Personentageaufwand für Interne und Externe kostet, wenn eh jeder damit macht was er will? Ein weiterer elementarer Kritikpunkt ist die Forderung nach dem Einsatz elektronischer Signaturen und kryptografischer Schutzfunktionen für Datenobjekte und technische Komponenten inklusive der Kommunikationswege in der Scan-Workstation, sobald Dokumente mit Schutzbedarf „hoch“ oder darüber eingestuft werden. Und „hoch“ ist laut TR definiert als „Die Schadensauswirkungen sind in der Regel beträchtlich. Ein solcher Schaden führt im Regelfall zu beträchtlichen Konsequenzen für die am Geschäftsvorfall beteiligten Personen und Institutionen“. Das muss jetzt jeder selbst interpretieren, ob der Zivilrechtsstreit zu einem Kontoauszahlungsbeleg, einem Versicherungsantrag oder einer Rechnung mit hohem Betrag dieses Kriterium nicht erfüllt und niedriger eingestuft werden kann. Welcher Projektleiter würde es wagen, hier „Man kann nicht einfach Dokumente mit dem gesunden Menschenverstand in eine auf den ersten Blick passende Schutzklasse legen, weil damit erhebliche technische und funktionale Konseqenzen für die Lösung verbunden sind.“


BIT 02-2015
To see the actual publication please follow the link above