3.4 und daher intensiven Prüfungen unterzogen waren. Es wurde deshalb vorge- schlagen, dass bestimmte Daten, die den Rückgriff auf die       Originalvorgänge erlauben, befristet in den zentralen Datenbestand aufgerrommen werden, obwohl dies der Pseudonymisierung entgegenstünde. In der gesetzten Frist könnten Inkonsistenzen ermittelt werden und die notwendigen Klärungen bei den Sachbearbeitern erfolgen. Eine solche Maßnahme stünde nicht im Widerspruch zu $ 67 c Abs. 5 SGB X, denn diese Regelung verlangt die Anonymisierung, sobald dies vom Planungszweck möglich ist. Diese zeitli- che Eingrenzung hat den Sinn, Plausibilitätsprüfungen noch zu ermöglichen, bevor die Anonymisierung erfolgt. Diese Maßnahme führt aber auch dazu, dass die Daten         Zunächst noch im personenbezogenen Zustand in den zentralen Datenbestand überführt wer- den. Da eine Rechtsgrundlage für die Übermittlung von Sozialdaten zum Zwecke des Querschnittscontrollings an eine Senatsverwaltung, z.B. die Senatsverwaltung für Finanzen, nirgendwo zu erkennen ist, wäre dies nur möglich, wenn der zentrale Datenbestand in der datenschutrprechtlichen Ver- antwortung der Sozialämter läge. Wir erwarten auch noch die Vorlage der Risikoanalyse|und des Sicher- heitskonzepts für ePBN. Ein früherer Entwurf einer solchen Unterlage war in methodisch fragwürdiger Weise erarbeitet worden®, so dass die Vollstän- digkeit der Risikoanalyse nicht gewährleistet sein konnte. Wir haben der Senatsverwaltung für Finanzen empfohlen, nach dem eigenen vorbildlichen Vorgehen bei der Erarbeitung der Risikoanalyse und des Sicherheitskonzepts für das IT-Verfahren zum Stellenpool eine Fachberatung durch BSI-akkredi- tierte Grundschutzauditoren in Anspruch zu nehmen. Zusammenfassend haben wir bei der Vorabkontrolle von ePBN sonder- bare Erfahrungen gemacht: In dem gesamten bisherigen Verfahren, das sich bisher etwa ein Jahr lang hinzieht, haben die Projektverantwortlichen bei der Senatsverwal- tung für Finanzen nicht einen konstruktiven Beitrag für|die datenschutz- rechtliche Gestaltung des Verfahrens eingebracht. Es gibt zwar politi- sche Absichtserklärungen des Senats und des Abgeordnetenhauses von Berlin sowie von Vertretern dieser Gremien, aber es gibt keine operable Darstellung der Ziele, die mit dem Einsatz von ePBN| verbunden sind, oder der Fragestellungen, die damit beantwortet werden sollen. Mit Aus- nahme der genannten Absichtserklärungen gibt cs keine Vorgaben, nach denen sich das beauftragte Softwareunternehmen zu          6rientieren hätte. — Das beauftragte Softwareunternehmen, das auch als Unternehmensbera- tung tätig wurde, war völlig frei, mit uns über die datenschutzrechtliche Gestaltung des Verfahrens zu verhandeln. Da alle grundsätzlichen Vor- gaben fehlten, entwickelte sich in dieser Zusammenarbeit ein Trial-and- Error-Vorgehen von beiden Seiten. Mögen der Unternehmensberatung 5  1gl.3.5 40                                                        Jahresbericht BInBDI 2003

3.5 exzellente Fähigkeiten in der Programmierung des komplexen Verfah- rens attestiert werden können; allerdings lagen weder datenschutzrecht- liche Kenntnisse noch Erfahrungen zu technisch-organisatorischen Datenschutzfragestellungen noch das Gespür für die datenschutzgerech- te Gestaltung von solchen IT-Verfahren vor. Dies führte vielfach zu Missverständnissen und Fehlinterpretationen, die wegen der strikten Passivität der verantwortlichen Senatsverwaltung nur mühsam im Dia- log aufgelöst werden konnten. — Gleichzeitig wurde von politischer Seite erheblicher Erfolgsdruck aus- geübt, der sich mittelbar auch auf uns auswirkte. Dem zitierten Senats- beschluss vom 17. Dezember 2002, der das offizielle Startsignal gab, ging ein Berichtsauftrag des Abgeordnetenhauses von Berlin vom 13. Juni 2002% voraus, der ebenfalls am 17. Dezember 2002 erfüllt wurde. Der Ausschuss für Verwaltungsreform und Kommunikations- und Informationstechnik behandelte das Thema auf seiner 23. Sitzung am 23. Oktober 20039! sehr ausführlich, aber ohne unsere Beteiligung. Dabei wurde deutlich, dass unsere Einwände offenbar überraschend kamen, weil unsere Beteiligung an den Pilotprojekten letztlich zu guten Ergebnissen führten. Dabei wurde übersehen, dass die Projekte sich schon von der Konkretisierung ihrer Fragestellungen wesentlich vom ausgeweiteten Verfahren unterschieden. Erkennbar war auch die Unge- duld, mit der alle Fraktionen auf die Realisierung des Projektes warte- ten. Allerdings wurde bei allen genannten Anlässen betont, dass die Pro- jekteinführung in Übereinstimmung mit den datenschutzrechtlichen Bestimmungen und damit nicht gegen unsere wesentlichen Einwände erfolgen sollte. 3.5 Risikoanalysen und Sicherheitskonzepte — der Weg zu einer siche- ren Datenverarbeitung Seit Beginn der Datenschutzgesetzgebung gibt es Vorschriften, die von den Daten verarbeitenden Stellen verlangen, dass die Daten so verarbeitet müssen, dass sie bei ihrer Verarbeitung nicht Unbefugten zur Kenntnis gelangen dürfen, dass Unbefugte keine Veränderungen an den Daten oder an den Programmen vornehmen können und dass die Daten, Programme und Systeme für die Sicherstellung der ordnungsgemäßen Datenverarbeitung zur Verfügung stehen müssen, wenn sie gebraucht werden. Um diese Ziele zu erreichen, besteht die Verpflichtung, die dafür notwendigen technischen und organisatorischen Maßnahmen zu ergreifen. Es wird verlangt, dass die Maß- nahmen dem Schutzzweck angemessen sein und dem Stand der Technik ent- sprechen sollen. ®  Abghs.-Drs. 15/1146 61 Inhaltsprotokoll VerwRefKIT 15/23 Jahresbericht BInBDI 2003,                                                  41

3.5 Angemessenheit und Eignung technischer und organisätorischer Maß- nahmen zum Datenschutz Die wichtigste Frage, die sich die Daten verarbeitenden Stellen zu stellen haben, lautet daher, welche Maßnahmen getroffen werden müssen, welche entsprechen dem Schutzzweck und verhindern in angemes sener Weise jeg- lichen unbefugten Zugriff auf die Daten. Das BDSG un            andere Landes- gesetze, die die Datensicherheitsvorschriften noch nich t dem heutigen Methodenwissen angepasst haben, versuchen dies mit ei em Katalog von Kontrollanforderungen zu lösen. Diese Anforderungen d efinieren relativ konkret, was im Einzelnen erreicht werden muss. Zu jeder Anforderung las- sen sich Checklisten möglicher Maßnahmen zusammenttagen,                aus denen man sich die tatsächlich oder vermeintlich geeignetsten au ssuchen kann. Je nachdem, mit welchem Vorverständnis diese Auswahl getroffen wird, trägt sie dann die Handschrift des Haushälters, der arbeitsüber! lasteten IT-Stelle, des Technikfreaks oder der Fachkraft für informationstech ische Sicherheit. Die methodische Schwäche der abgeschlossenen Kontrollanforderungskata- loge liegt. mittlerweile darin, dass die vielfältige Ausptägung moderner Informationstechnik und die sich daraus ergebenden tatsächlichen Anforde- rungen von den Katalogen nicht mehr immer abgebildet werden können. Einige Bundesländer — so auch Berlin — sind bei der let ten Novellierung ihrer Datenschutzgesetze daher einen anderen Weg gegangen. Sie definieren abstraktere Ziele, die erreicht werden müssen, und verlange n, dass zur Errei- chung dieser Ziele Sicherheitskonzepte entwickelt und umgesetzt werden, die auf Risikoanalysen beruhen. Bevor entschieden wird, welche Maßnah- men getroffen werden, ist zuverlässig und vollständig zu ermitteln, gegen welche konkreten Risiken die Maßnahmen wirken sollen. Damit erhält auch die Forderung nach der Angemessenheit zum Schutzzwec erst einen Sinn: Angemessen ist eine Maßnahme dann, wenn sie ein erkanntes Risiko so weit mindert, dass das Restrisiko akzeptiert werden kann. Missbräuchlich war dagegen die manchmal den Forderungen der Datenschutzbeauftragten ent- gegengehaltene Ansicht, das Gebot der Verhältnismäßigkeit verlange, den Aufwand für Datensicherheitsmaßnahmen auf jeden Fall zu relativieren. Rechtliche Rahmenbedingungen $ 5 BInDSG bestimmt, dass bei der Verarbeitung personenbezogener Daten Maßnahmen zu treffen sind, die geeignet sind, Vertraulichkeit, Inte- grität, Verfügbarkeit und Authentizität der personenbezbgenen Daten zu gewährleisten, und dass ferner die Verarbeitung dieser Da en revisionsfähig und transparent erfolgt. Vor der Entscheidung über den Einsatz oder eine wesentliche Änderung der automatisierten Datenverarbeitung sind die zu treffenden technischen und organisatorischen Maßnahmen auf der Grund- lage einer Risikoanalyse und eines Sicherheitskonzepts zu|ermitteln. Bereits im Januar 1999 wurde für die Berliner Verwaltung die /T-Sicherheitsricht- 42                                                      3E ihresbericht BInBDI 2003

3.5 linie” erlassen, in der festgelegt wurde, dass für die verschiedenen Sicher- heitsdomänen Sicherheitskonzepte zu erstellen sind. Sicherheitsdomänen sind dabei alle logisch, organisatorisch oder räumlich zusammengehörenden Bereiche mit einheitlichen Sicherheitsanforderungen. Konkreter aber ver- langt die Richtlinie, dass für die zentrale IT-Infrastruktur (Landesnetz, Sicherheitsrechenzentrum, Grenznetz) Sicherheitskonzepte existieren müs- sen, die hohen Schutzbedarf befriedigen, dass behördenbezogene Sicher- heitskonzepte zumindest den Grundschutz für mittleren Schutzbedarf gewährleisten sollen und dass für die Sicherheitsdomänen der IT-Verfahren verfahrensspezifische Sicherheitskonzepte vorliegen müssen. Dabei ist eine Hierarchie erkennbar: Da die Behörden auch die zentrale IT-Infrastruktur nutzen, bauen die behördlichen Sicherheitskonzepte auf dem der zentralen Infrastruktur auf. Da die IT-Verfahren in den behördlichen Infrastrukturen (lokale Netzwerke) betrieben werden, bauen die verfahrenspezifischen Sicherheitskonzepte auf den behördlichen Sicherheitskonzepten auf. Sicherheitskonzepte in der Berliner Verwaltung Fünf Jahre nach Erlass der Richtlinie kann von einer flächendeckenden Ausstattung der öffentlichen Stellen Berlins mit solchen Sicherheitskonzep- ten nicht die Rede sein. Selbstverständlich gibt es technische und organisa- torische Maßnahmen, Regelungen zu bestimmten sicherheitsrelevanten Fra- gestellungen wie Datensicherung, Umgang mit Passwörtern und manches andere, methodisch erstellte Konzepte liegen jedoch nur in Ausnahmefällen vor und wurden häufig aufgrund unserer Forderungen bei neuen IT-Verfah- ren erstellt. Allerdings häufen sich die Fälle, in denen uns verfahrens- und behördenspezifische Sicherheitskonzepte zur Kenntnisnahme oder Stellung- nahme vorgelegt werden. Die Unterscheidung zwischen guten und schlech- ten Sicherheitskonzepten, die am „grünen Tisch“ zu treffen ist, ergibt sich zunächst daraus, wie präzise die Konzepte nach anerkannten methodischen Vorgaben erarbeitet worden sind. Ist zum Beispiel die vorhergehende Schutzbedarfsfeststellung zutreffend? Macht die Vorgehensweise bei der Risikoanalyse plausibel, dass sie vollständig ist, dass also die Behandlung wichtiger Risiken nicht vergessen worden ist? Wird die Auswahl der Maß- nahmen im Sicherheitskonzept durch eine Restrisikoanalyse gerechtfertigt? Geprüft werden kann auf dem Papier nur die Plausibilität, Vollständigkeit und methodische Klarheit, nicht jedoch die Richtigkeit. Diese kann wie auch die Umsetzung der Sicherheitskonzepte nur vor Ort kontrolliert werden. Manche der vorgelegten Sicherheitskonzepte waren nach den genannten Kriterien nicht zu beanstanden. Fast in allen diesen Fällen waren Beratungs- unternehmen eingebunden worden, die sich ganz oder teilweise auf diese Aufgaben spezialisiert haben. Am Beispiel des Sicherheitskonzepts für die #2 Richtlinie zur Gewährleistung der notwendigen Sicherheit beim IT-Einsatz in der Berliner Verwaltung vom 5. Januar 1999, DBI. I, S. 5 ff. Jahresbericht BInBDI 2003                                                                          43

3.5 IT-Anwendung im Rahmen des Stellenpools zeigte sich, dass BSI-akkredi- tierte Grundschutzauditoren auch unter engem Zeitdruck akzeptable Sicher- heitskonzepte entwickeln können. Die meisten Fehler werden bereits bei der Risikoana! Iyse gemacht. Ein Fehler ist, dass die betrachteten Risiken willkürlich ausg wählt erscheinen, vielleicht in einem Brainstorming oder in Workshops ohn: weitere methodi- sche Hilfsmittel ermittelt wurden, so dass die Vollständigkeit nicht plausibel gemacht werden kann. Oft entsteht der Eindruck, das: nur die Risiken betrachtet werden, für deren Eindämmung bereits Maßnahmen erkannt oder gar getroffen wurden oder die mit einfachen Mitteln verri gert werden kön- nen. Ein weiterer Fehler bei der Durchführung von Ri sikoanalysen liegt darin, dass man schon bei der Zusammenstellung der zu analysierenden Risiken auf Maßnahmen zurückgreift, die sich mindernd auf die Risiken auswirken. In diesem Falle ist für den Revisor nicht erken; nbar, aus welchem Grunde bestimmte Risiken aus der Analyse ausgeblendet wurden. Das Sicherheitskonzept muss die Maßnahmen explizit benen en, die gegen ein bestehendes Risiko getroffen worden sind, gleichgültig, b die Maßnahmen vor der Analyse bereits getroffen waren oder nicht. Vorgaben des BSI Das Bundesamt für die Sicherheit in der Information: technik (BSI) hat 1992 das /T-Sicherheitshandbuch veröffentlicht®. Es war bald klar, dass die Anwendung dieses Handbuchs zur Erarbeitung von Sid herheitskonzepten nur in besonderen Fällen, in denen ein hoher Schutzbed larf zu decken ist, angemessen sein konnte, weil der Aufwand dafür sehr ho ch ist. Eine Über- arbeitung hat das IT-Sicherheitshandbuch daher nicht m ehr erfahren. Die beschriebene abstrakte Methodik für die Durchführung iner Bedrohungs- und Risikoanalyse und der Ableitung von Maßnahmen diaraus ist nach wie vor einschlägig, die technikbezogenen Beispiele und Maß nahmenvorschläge sind dagegen weitgehend veraltet. Seit 1995 veröffentlicht das BSI in etwa jährlichen Ab iständen eine Fort- schreibung des /T-Grundschutzhandbuchs als Loseblatt-S: ammlung®%, als CD oder im Internet. Das Grundschutzhandbuch bietet eine vereinfachte Methode für die Risikoanalyse und die Auswahl geeignet er Maßnahmen an, beschränkt sich aber ausdrücklich auf den Einsatz bei ni drigem oder mitt- lerem Schutzbedarf. 3  BSI (Hrsg): IT-Sicherheitshandbuch - Handbuch für die sichere Anwendung der Informationstechnik. Bonn: Bundesdruckerei, 1992, Download ist möglich über http://www.bsi.bi ind.de/literat/kriterie.htm BSI (Hrsg.): IT-Grundschutzhandbuch. Standard-Sicherheitsmaßnahmen. K öln: Bundesanzeiger Ver- lag, 2002 65 http://www.bsi.de/gshb/deutsch/menue.htm al hresbericht BInBDI 2003

3.5 Die Schutzbedarfsanalyse Das Grundschutzhandbuch beginnt mit einer Schutzbedarfsanalyse, in der festgestellt werden soll, in welchem Umfang seine Anwendung angemessen und in welchen Zusammenhängen ergänzende Sicherheitsanalysen erforder- lich sind. Dies könnte zum Beispiel die Durchführung einer Risikoanalyse nach dem IT-Sicherheitshandbuch sein. Es wird nur sehr grob unterschieden zwischen IT-Systemen mit niedrigem bis mittlerem Schutzbedarf für den Fall, dass die Schadensauswirkungen begrenzt sind, mit hohem Schutzbedarf für den Fall, dass die Schadens- auswirkungen beträchtlich sind, oder mit sehr hohem Schutzbedarf bei existenziellbedrohlichenoderkatastrophalenSchäden.Die Schädenkönnen labei in — den Folgen von Verstößen gegen Gesetze, Vorschriften oder Verträge, — der Beeinträchtigung des informationellen Selbstbestimmungsrechts, — der Beeinträchtigung der persönlichen Unversehrtheit, — der Beeinträchtigung der Aufgabenerfüllung, — der negativen Außenwirkung oder — last but not least — — finanziellen Auswirkungen bestehen. Im Hinblick auf das informationelle Selbstbestimmungsrecht wird von sehr hohem Schutzbedarf gesprochen, wenn ein Missbrauch personen- bezogener Daten für den Betroffenen den gesellschaftlichen oder wirt- schaftlichen Ruin bedeuten würde. Zur schärferen Eingrenzung bestimmter Schutzbedarfskategorien macht es Sinn, bei den Bewertungen nach den Grundbedrohungen der Vertraulichkeit, Integrität, Verfügbarkeit und Authentizität der Daten und Systeme zu differenzieren. Es gibt IT-Systeme, deren Ausfall verheerende Wirkungen haben kann, bei denen jedoch Verlet- zungen der Vertraulichkeit weniger ins Gewicht fallen (z.B. Steuerungs- systeme bei strahlentherapeutischer Behandlung, von Nuklearanlagen); es gibt andere IT-Systeme, in denen die Beeinträchtigungen der Datenintegrität schlimmere Auswirkungen haben als Verletzungen der Vertraulichkeit (z.B. Kassenverfahren) und letztlich andere Systeme, in denen es vor allem auf die Vertraulichkeit der Daten ankommt (z.B. medizinische Register). Aus datenschutzrechtlicher Sicht ist vor allem relevant, wann Daten verarbeitet werden, die vor allem hinsichtlich der Vertraulichkeit hohen oder sehr hohen Schutzbedarf ausweisen: Dies dürfte immer dann der Fall sein, wenn beson- dere Daten im Sinne von $ 6a BinDSG, Daten, die einem besonderen Berufs- oder Amtsgeheimnis unterliegen, Daten im Rahmen der Strafverfol- gung oder des Verfassungsschutzes oder dispositive (bewertende) Daten über Personen vorliegen. Im Falle des IT-Verfahrens im Stellenpool wurde unsere Forderung nach der Eliminierung bestimmter dispositiver Personaldaten (z.B. Gesamtnoten Jahresbericht BInBDI 2003                                                 45

3.5 dienstlicher Beurteilungen, Gründe für die Beendigung vo Arbeitsverhält- nissen) von den später eingeschalteten Grundschutz-Auditoren bestätigt und durchgesetzt, weil sonst ergänzende Sicherheitsanalysen er! torderlich gewe- sen wären. Die Risikoanalyse Der für die Wirksamkeit eines Sicherheitskonzepts entsc) heidende Schritt ist die Risikoanalyse. Wenn hier Fehler gemacht werden, wi erden im Sicher- heitskonzept falsche Maßnahmen umgesetzt, die untragba: e Risiken beste- hen lassen. Die Risikobetrachtungen nach dem IT-Sicherhe) tshandbuch und dem IT-Grundschutzhandbuch unterscheiden sich erheblich, jedoch ist in beiden Fällen Vollständigkeit gewährleistet, wenn die Mei hoden strikt an- gewendet werden. Die Methode nach dem IT-Sicherheitsha dbuch ist natur- gemäß komplexer, aber logisch nachvollziehbar und mach das Grundprin- zip deutlich: Zunächst müssen alle Anwendungen und Datenbestän: le ermittelt und hinsichtlich der Schäden bei Eintreten der Grundbedrohungen bewertet wer- den. Danach werden die einzelnen Objekte der Anwendui gen, Daten und ihrer Umgebungen (Infrastruktur, Hardware, Datenträger, Paperware, Soft- ware, Anwendungsdaten, Kommunikationskomponenten, Personen) und deren Bedeutung     für die Grundbedrohungen     erfasst. Dann werden die Bedrohungen auf die Objekte konkretisiert. Am Ende di ses Schrittes ist bekannt, wie der Schaden pro Objekt bei Eintreten einer Bedrohung bewer- tet wird (Schadenswert in einer fünfstufigen Skala). Als Nächstes wird bewertet, wie häufig eine Bedrohung zu einem Scha- densfall an einem Objekt führt (Häufigkeitswert in ei ner fünfstufigen Skala). Das Wertepaar {Schadenswert, Häufigkeitswert            beschreibt das Risiko, denn es gibt an, wie häufig welcher Schaden an e nem Objekt ent- stehen kann. Da man kleine Schäden häufiger ertragen kann als große, muss entschieden werden, mit welcher Häufigkeit welche Schäden als tragbar angenommen werden sollen oder nicht (Entscheidungstabelle zur Ermittlung der tragbaren und untragbaren Risiken). Gegen die untragbaren Risiken müssen Maßnahmen ergriffen werden, die den Schadenswert und/oder den Häufigkeitswert so weit reduzieren, dass das Risiko in den tragbaren Bereich der Entscheidungstabelle rutscht. Das Sicherheitskonzept steht, wenn am Ende eine Restrisikoanalyse nachweist, dass alle zuerst untragbaren Risiken auf ein tragbares Maß reduziert worden sind. Dieses recht komplizierte Verfahren verwendet zwar Skalenwerte, aber sowohl die Schadenswerte als auch die Häufigkeitswerte und allemal die Entscheidung, wann Risiken tragbar sind und wann nicht, lassen sich objek- tiv nicht bestimmen. Daher verlangt die Vorgehensweise nach dem IT- Sicherheitshandbuch    das  diskurshafte  Zusammenwirke        von     Vertretern verschiedener Interessen und fachlicher Kompetenzen. Es wird dringend 46                                                       Jahtesbericht BInBDI 2003

3.5 empfohlen, die Diskurse unter neutraler Moderation zu führen, um die Durchsetzung einseitiger Interessen zu verhindern. Zum Beispiel darf ein vernünftiges Sicherheitskonzept nicht am entschlossenen Widerstand des Finanzverantwortlichen scheitern. Andererseits soll die Umsetzung eines Sicherheitskonzeptes ein Unternehmen oder eine Behörde nicht selbst exis- tenziell oder in seiner Aufgabenerfüllung bedrohen. Wesentlich einfacher verläuft die Risikoanalyse mit dem Grundschutz- handbuch. Das Grundschutzhandbuch benennt derzeit insgesamt 54 Kompo- nenten unterschiedlicher Art, die als Bausteine für die Modellierung des zu analysierenden IT-Systems oder der zu analysierenden IT-Anwendung ver- wendet werden können. Die Weiterentwicklung des IT-Grundschutzhand- buchs besteht unter anderem darin, dass die Zahl der Komponenten konti- nuierlich erhöht wird, um immer mehr reale IT-Systeme mit diesen Baustei- nen modellieren zu können. Jedem dieser Bausteine sind konkrete Gefähr- dungen zugeordnet, die auf ihnen lasten, und konkrete Maßnahmen, mit denen sie reduziert werden können. Alle Gefährdungen und Maßnahmen werden genau beschrieben. Sind alle Bausteine des Modells erfasst, können alle Gefährdungen aufgelistet werden. Dann muss entschieden werden, wel- che Gefährdungen im realen Fall relevant sind, d. h., ob sie aufgrund beson- derer Verhältnisse nicht bestehen, ob genannte Maßnahmen bereits ergriffen und somit die Gefährdungen reduziert wurden oder ob die angebotenen Maßnahmen ergriffen werden müssen, um die Sicherheit zu gewährleisten. IT-Sicherheitskonzepte Die Ausführungen zu den Methoden der Risikoanalysen machen bereits deutlich, dass sich bei der Anwendung der beschriebenen Methoden das Sicherheitskonzept beinahe von selbst ergibt. Beim Sicherheitshandbuch ist am Ende klar, gegen welche Risiken Maßnahmen ergriffen werden müssen. Es bietet Hilfestellungen, die aber nicht mehr aktuell sind und somit nur Anregungen geben können. Da das Sicherheitshandbuch aber nur mit Exper- tenwissen durchgeführt     werden kann, dürfte es unproblematisch sein, aktuelle Maßnahmen gegen untragbare Risiken zu finden. Das ständig aktualisierte IT-Grundschutzhandbuch bietet nach der Ana- lyse einen Katalog von Maßnahmen an. Er ist zunächst darauf zu prüfen, ob er Maßnahmen enthält, die bereits getroffen wurden. Dann ist zu prüfen, ob auf Maßnahmen verzichtet werden kann, weil sie sich gegen Gefährdungen richten, die nicht vorliegen. Bei dem Rest handelt es sich um Maßnahmen, die für die Umsetzung des Sicherheitskonzepts von Bedeutung sind. Die Dokumentation des Sicherheitskonzepts muss in allen Fällen die voll- ständige Risikoanalyse nachvollziehbar und deutlich machen, weshalb bezüglich der angebotenen Maßnahmen welche Entscheidungen getroffen wurden. Jahresbericht BInBDI 2003                                                 47

3.5 Die IT-Sicherheitsrichtlinie vom 5. Januar 1999 schre bt vor, wie ein Sicherheitskonzept in der Berliner Verwaltung aufgebaut w. rden muss: Neben der Benennung des Anwendungsbereichs (Behä rde, Verfahren), also der Beschreibung der behandelten Sicherheitsdomäne, muss es die Risi- koanalyse, die Beschreibung der Maßnahmen und eine Restrisikoanalyse, die die Beseitigung aller untragbaren Risiken nachweist, en) halten sein. Fer- ner gehört zum Sicherheitskonzept die Benennung der Veräntwortlichkeiten sowie ein Umsetzungsplan, der einen Zeitplan, Prioritätsfe tlegungen, Fort- schreibungsregeln und die Kosten spezifiziert. Das Berliner Modellsicherheitskonzept Ein wichtiges Projekt des IT-KAB“ ist derzeit die E rarbeitung eines Modellsicherheitskonzepts für die Berliner Verwaltung durkch eine spezielle Arbeitsgruppe, in der wir mitarbeiten. Grundlage für die E rarbeitung dieses Modellsicherheitskonzepts ist das IT-Grundschutzhandbuch des Bundesam- tes für Sicherheit in der Informationstechnik. Dabei werden zu den einzelnen dort beschriebenen Komponenten, die für die Berliner Verwaltung relevant sind, die im Handbuch vorgeschlagenen Maßnahmen dara f hin untersucht, ob die damit zu reduzierenden Gefährdungen überhaupt zu reffen, die Maß- nahmen bereits getroffen worden sind oder aber doch noch einer Umsetzung bedürfen. Dieses Vorgehen ist für Verfahren, die höchsten mittleren Sicher- heitsbedarf aufweisen, legitim. Abzuwarten bleibt jedoch,    b die Behörden, die das Modellsicherheitskonzept später anwenden, den Ma dellcharakter tat- sächlich anerkennen oder das Modellkonzept mehr oder weniger unange- passt übernehmen. Dies wäre jedoch ein wesentliches Mis; verständnis über den Zweck des Modellsicherheitskonzepts, denn selbstverständlich muss jede Behörde die meisten im Modell erfolgten Abwägungen anhand der behördenspezifischen Verhältnisse überprüfen. 48                                                       Jahtesbericht BInBDI 2003

41.1 4.       Aus den Arbeitsgebieten 4.1      Öffentliche Sicherheit 4.1.1 Polizei Der „Fall Mahmoud“ - junge Intensivtäter Im Frühjahr ging der „Fall Mahmoud“ durch die Presse. Es handelte sich um einen jungen Intensivtäter, der seit seinem zehnten Lebensjahr wegen rund 80 Straftaten — teilweise während der Bewährungszeit — bei der Polizei aktenkundig wurde. Diesen Fall hatte ein leitender Krimi- nalpolizist in einem Aufsatz in einer Fachzeitschrift aufbereitet. Der Polizeibeamte hatte — leicht anonymisiert — detailliert über die Statio- nen der kriminellen Karriere sowie über die persönliche Entwicklung, das soziale Umfeld und die familiäre Situation des Betroffenen berichtet. Der Aufsatz‘’ listet ausführlich sämtliche gegen den Betroffenen geführten Ermittlungsverfahren auf. Den Namen hatten Journalisten durch Recherchen in der Szene schnell herausgefunden und veröffentlicht. Datenschutzrechtliche Probleme ergeben sich daraus, ob — und gegebenenfalls in welcher Funktion der Autor (Kriminalpolizist) auf das polizeiliche Informationssystem zugegriffen hat, — der Zugriff mit Genehmigung des Polizeipräsidenten in Berlin erfolgte, — eine Genehmigung für die Fertigung des Aufsatzes vorlag und — der Text des Aufsatzes vor der Veröffentlichung von dem Polizeipräsi- denten in Berlin genehmigt wurde. Der Polizeipräsident hat uns mitgeteilt, dass diese Fragen nahezu deckungsgleich Gegenstand eines Strafermittlungsverfahrens sind. Die Berliner Polizei sei sowohl als Strafverfolgungsbehörde als auch als Dienst- behörde eingebunden. Die jeweiligen Pflichtenkreise würden sich über- lagern. Er bezweifele außerdem, dass in dem Aufsatz überhaupt personen- bezogene Daten veröffentlicht wurden. Er bat, eine Stellungnahme erst nach Abschluss des Strafermittlungsverfahrens abgeben zu können. Dem haben wir ausnahmsweise wegen der besonderen Sensibilität des Einzelfalles entsprochen. Grundsätzlich jedoch sind die strafrechtlichen Ermittlungen losgelöst von einer Stellungnahme an den Datenschutzbeauftragten zu betrachten. Der Fall hat dazu geführt, dass zwischen Justizverwaltung und Polizei eine Diskussion über den Umgang mit jugendlichen Intensivtätern einsetzte. 67. Henninger, Markus: Konsequente Inkonsequenz/ Die „kriminelle Karriere“ des Mahmoud R. und ihre zustizielle Würdigung. In: Kriminalistik 8-9 (2002), 8. 513 ff. Der Spiegel 12/2003, $. 54, 58 Jahresbericht BInBDI 2003                                                                      49