17© SecuMedia Verlags-GmbH · 55205 Ingelheim · <kes> 2006#2

Abbildung 1:Ablauf beimrevisionssicherenAuslesen,Speichern undLöschen digitalerFotos

Vollautomatischer Prozess durch Einstecken initiiert

Digitales Foto

Original

Digitales Foto

gelöschtSpeicherkarte

Arbeitsplatz-PC

Server

Ermittlung aller BilddatenVirenfreiheitContentüberprüfung jpg,tif, tiff, Herstellerformatedigital signierte Liste derkorrekten Bilder

ÜbertragungBild für BildKopie auf Server

Secure DIFO vergleichtSignaturen des Serversund erstellt digitalsignierte Löschliste

Server signiert Bildund sendet Erfolgs-meldung

Zeit

verl

auf

„Spe

iche

rn a

uf S

erve

r“

Zeit

verl

auf

„Lös

chen

Ori

gina

le“

JuristischeBeweiskraft

Logbuch enthält:

Ergebnis Virenprüfung

Ergebnis Contentprüfung

Digital signierte Liste aller Bilder

Übertragungsergebnis

Signatur Server „Bild erhalten“

Digital signierte Liste aller gelöschten Bilder

Das Projekt „Digitale Foto-grafie“ (DiFo) der Bayerischen Polizeisoll das Einsparpotenzial digitalerKameras und Arbeitsabläufe für denPolizeidienst erschließen. Die teurenVerfahren der traditionellen Fotogra-fie von Tatorten auf Filmbild-Kame-ras mit anschließender Negativ- undBildentwicklung gehören damit,zumindest in Bayern, nun der Ver-gangenheit an. Kostenvorteile bezie-hen sich hierbei nicht nur auf dieErstellung der Fotos, sondern wirkensich über die gesamte Lebensspanneund in den definierten Prozessenpositiv aus. Die schnelle – wenn er-forderlich bundesweite – Verfügbar-keit digitaler Fotos ist gerade im Jahrder Fußball-Weltmeisterschaft einweiterer wesentlicher Vorzug gegen-über der früheren Vorgehensweise.Bayern ist mit diesem Ansatz Vorrei-ter und definiert damit Standards,die nicht nur in der Polizeiarbeit,sondern auch in vielen Behördenund Wirtschaftsunternehmen sehrnützlich sein dürften.

Die Einführung von Syste-men zur digitalen Fotografie erfordertjedoch naturgemäß die Nutzung vonSchnittstellen zu Kameras und Spei-chermedien an PC-Arbeitsplätzen,die sorgsam zu reglementieren ist, da-mit keine Einbußen bei der IT-Sicher-heit zu beklagen sind. Hier hat sich dieBayerische Polizei für den Einsatz vonDeviceWatch (www.devicewatch.de)der Münchner Firma itwatch GmbH

entschieden. Der vorliegende Projekt-bericht schildert die Anforderungen,Entscheidungsgründe und ersten Er-fahrungen.

Das DiFo-Projekt ist eng andie flächendeckende Verfügbarkeitdes Betriebssystems MicrosoftWindows XP gekoppelt, in dem Peri-pheriegeräte – im Folgenden meistkurz als Geräte oder auch neudeutsch„Devices“ bezeichnet – durchPlug&Play sehr einfach eingesetztwerden können. Zur Verbindungvon Devices mit dem PC-Arbeitsplatzdienen (ganz allgemein) die Schnitt-stellen USB, FireWire, PCMCIA, Blue-tooth und einige mehr. Mit diesemleichten Zugang zum PC sind natür-lich auch Risiken verbunden, unter

Von Walter Wust, München

Sichere IT-Umgebung fürdigitale TatortfotosEin Projektbericht der Bayerischen Polizei

Digitale Fotografie verspricht enorme Kostenvorteile gegenüber der klassischen chemie-

basierten Variante. Um dieses Potenzial zu erschließen, ohne auf der IT-Seite Abstriche

bei der Sicherheit zu machen, hat die Bayerische Polizei ein flächendeckendes Device-

Management eingeführt.

Sicheres Device-ManagementSysteme und ihr Umfeld

anderem das Einbringen von Schad-software, das unerlaubte Kopierenvon Daten oder das Schaffen uner-wünschter Netzverbindungen perWLAN oder Bluetooth (vgl. bspw. [1]und [2]).

Derzeit hat die BayerischePolizei etwa 20 000 PCs im Einsatz;alle Computer wurden 2005 in weni-gen Monaten mit Windows XP aus-gestattet. Rasch nach seinem Startmeldete das zugehörige Projekt auchdie Anforderung, digitale Fotoappa-rate einbinden zu können. Wie sichherausstellte, handelt es sich hierbeium einen Schlüsselfaktor, der beiRoll-out-Vorhaben anderer Behör-den häufig vergessen wird. Diesefrühzeitige Kommunikation zwi-

17-21 (Tatortfotos) 07.04.2006, 17:02 Uhr17

Sonderdruck für

01 kes 2006-2 (4-seiter).indd 1 24.08.12 17:10

© SecuMedia Verlags-GmbH · 55205 Ingelheim · <kes> 2006#218

schen dem Basis-Projekt „Betriebs-system“ und dem Anwendungspro-jekt „DiFo“ war entscheidend für eineffizientes Arbeiten.

Bordmittel vs. USB & Co.

Aus Sicht der IT-Plattform –also Betriebssystem und systemnaheKomponenten – ist der sicherste Be-trieb dadurch gekennzeichnet, dassalle Schnittstellen mit „Bordmitteln“abgeschaltet werden. Hierzu stehenWindows Group Policy Objects (kurzGPO), das BIOS sowie lokale Einstel-lungen zur Verfügung (z. B. Rechteauf bestimmten Registry Keys perAccess-Control-Listen). Mit dem Pro-jekt DiFo hatte die Bayerische Polizeiaber gerade den Bedarf, die Schnitt-stellen der Plattform zu öffnen –selbstverständlich nur für die vorabdefinierte Nutzung.

Ein erster Lösungsansatz wares, den ohnehin klar definiertenHardwarebeschaffungsprozess mitzentraler Validierung und Freigabeauch für die Peripheriegeräte zu nut-zen. Schnell erkannte man jedoch,dass die Geschwindigkeit, in welchersich der Markt der Peripheriegeräteverändert, im Rahmen eines zentralgesteuerten Freigabeprozesses nurungenügend abzubilden ist. Da Kos-tendruck und Verbesserungen derFlexibilität Hauptgründe für die Rea-

Abbildung 2:Erfasste digitale

Fotos werden übereine Client-/Server-

Anwendung imBayerischen Landes-

kriminalamtverwaltet.

Sicheres Device-ManagementSysteme und ihr Umfeld

lisierung des Projekts DiFo waren,wäre es kontraproduktiv gewesen,realisierbares Einsparpotenzial vonvornherein auszugrenzen: Die Kos-ten digitaler Kameras unterliegen ei-nem stetigen Abwärtstrend, die Mo-delle werden häufig mit technischenVerbesserungen oder neuen Funktio-nen unter neuem Namen auf denMarkt gebracht, was zeitlich aufwän-dige, zentrale Validierungsprozessead absurdum führt.

Vom Preisdruck im Marktder Peripheriegeräte kann man ambesten dann profitieren, wenn fürdas Management der Devices„schlanke“ Prozesse definiert wer-den, die ohne großen zeitlichen undpersonellen Aufwand ablaufen undgegebenenfalls auch einen häufigenWechsel zu anderen Herstellern oderneuen Gerätetypen unterstützen.Daraus resultierte die Forderungnach einem wirtschaftlichen Life-Cycle-Management für einen poten-ziell sehr großen Device-„Zoo“ unddie effiziente Integration in definier-te Prozesse, vor allem zu Beschaffungund Freigabe.

Selbstredend ist der Sicher-heitsbedarf bei Polizeibehördenhoch, weswegen Verfahren regelmä-ßig auch einem „Negativ-Test“ un-terzogen werden, der die Funktioneiner Teilkomponente infrage stellt

und prüft – am besten „in allen Le-benslagen“. Im vorliegenden Fallzeigte sich bei den BIOS-Einstellun-gen einiger PCs ein Fehlverhalten:Der Plug&Play-Mechanismus im Be-triebssystem und das Betriebssystemselbst sind teilweise „stärker“ als dasBIOS, sodass eine Sperre von USB-Schnittstellen mit BIOS-Mitteln inbestimmten Fällen nicht mehr greiftund der Benutzer dennoch Zugangzu einigen Devices erhält – der Nega-tiv-Test für das Bordmittel BIOSkonnte somit nicht als bestandengelten.

Ein weiteres Problem: BIOSund GPO ermöglichen es nicht, spe-zifische, durch ihren Namen identifi-zierte Devices für einzelne Benutzeroder Gruppen freizugeben. Außer-dem schützen diese Bordmittel nichtvor Schnittstellen oder Geräteklas-sen, die zum Roll-out-Zeitpunktnoch nicht bekannt sind. Dadurchentsteht eine permanente Notwen-digkeit zur Nachschau.

Verfahren mit ACLs auf ein-zelne Registry Keys werden überdiesschon durch die Treiber einiger Gerä-te ausgehebelt, die beispielsweisesofort einen neuen Registry-Schlüs-sel anlegen, wenn sie einen vordefi-nierten Key nicht mehr lesen können– wenn sie an einer bestimmten Stellekeine Schreibberechtigung haben,suchen sie sich einfach einen ande-ren Platz.

Speziallösung gefordert

Nach der Analyse aller ver-fügbaren Bordmittel war damit klar,dass wegen fehlender Flexibilität undlimitierter Funktionalität eine ande-re Lösung gefunden werden musste.Nach einer kurzen Marktsondierungfiel die Entscheidung „Make or Buy“klar in Richtung „Einkauf“, da dervorgefundene Reifegrad entspre-chender marktgängiger Produkteeine Inhouse-Entwicklung nichtrechtfertigt und von anderen Stellenüber „Groschengräber“ mit starkwachsenden Kosten bis hin zur Kos-

17-21 (Tatortfotos) 07.04.2006, 17:02 Uhr1801 kes 2006-2 (4-seiter).indd 2 24.08.12 17:10

© SecuMedia Verlags-GmbH · 55205 Ingelheim · <kes> 2006#220

tenexplosion berichtet wurde. Des-halb begann man Ende 2004 miteiner Ausschreibung „sichereSchnittstellen“ ein Werkzeug zu su-chen, welches das sichere Manage-ment einzelner Devices sowie allerSchnittstellen ermöglicht. Den Zu-schlag in dieser Ausschreibung er-hielt im ersten Halbjahr 2005 dasProdukt DeviceWatch.

DeviceWatch dient dazu,alle Schnittstellen und Peripheriege-räte (auch großer PC-Netze) zentralzu managen – auch für neue, bis datounbekannte Systeme ist hierfür keinSoftware-Update erforderlich. DieDeviceWatch DEvCon (Device EventConsole) ermöglicht es, auf dezentralauftretende gerätespezifische Ereig-nisse (z. B. Plug&Play-Fehler, neuesLaufwerk, verbotene Netzwerkkarteo. Ä.) individuell zu reagieren undauch eigene Lösungen zu integrie-ren. Die Konsole umfasst zudemFunktionen zur Inventarisierung pe-ripherer Endgeräte, was überdies –ohne clientseitige Software-Installa-tion – auch durch den DeviceWatchScanner möglich ist. Nicht zuletztenthält die Lösung einen Content-Filter mit detailliertem, kundenseitigerweiterbaren Pattern Matching zursyntaktischen und semantischenKontrolle von Dateiinhalten beimAustausch mit externen Laufwerken.Als weitere Pluspunkte konnte derAnbieter eine branchenübergreifen-de Marktdurchdringung anführenund durch Referenzinstallationen ei-nen hohen Produktreifegrad bele-gen.

Parallel zum Managementder (zulässigen) Devices als solcheblieb noch eine weitere Herausforde-rung: Ein einmal freigegebenes Ge-rät, beispielsweise eine Kamera,könnte auch von Berechtigten ent-weder versehentlich oder sogar ab-sichtlich missbraucht werden. Digi-tale Kameras sind heutzutageletztlich auch Datenträger mit einem„ganz normalen“ Dateisystem, wo-durch einerseits das Risiko eines un-erwünschten Exports (Schreiben auf

eine Kamera) und zum anderen einesverbotenen Imports entsteht (Lesenvon verbotenem Material).

Auch wenn Windows XP einFlag kennt, mit dem man das Schrei-ben auf USB-Speichergeräte generellverhindern kann, so ist auch diesesBordmittel für das DiFo-Projekt un-zureichend, da es nur auf USB wirkt,also eingebaute Speicherkartenlesernicht miteinbezieht. Zudem erweistes sich im täglichen Betrieb als sehrlästig: Hier muss beispielsweise einAdministrator, der zum Schreibenberechtigt sein soll, das Flag jedesMal verändern und er darf vor allemnach der Nutzung das Rücksetzennicht vergessen. Diese manuelle Ak-tion ist nicht zumutbar und darüberhinaus äußerst fehleranfällig.

Hinzu kommt ferner, dasseinige Standard-Anwendungen beimÖffnen von Fotos kleinere Änderun-gen an dem genutzten Dateisystem-Ordner vornehmen und bei einemSchreibschutz auf dieses Directorymit undefinierten Fehlern abbre-chen. Als endgültiges K.-o.-Kriteriumerwies sich bei der Bayerischen Poli-zei die Einbindung in einen sicherenDiFo-Prozess, der nicht nur zwischenLesen und Schreiben unterscheidet,sondern der beispielsweise die Akti-on „Löschen“ erst nach der Erfüllungbestimmter Bedingungen zulässt.

Sicherer DiFo-Prozess

Innerhalb der BayerischenPolizei ist definiert, dass ein Tatortfo-to erst dann vom Originaldatenträ-ger gelöscht werden darf, wenn be-wiesenermaßen eine identische Ko-pie auf einem dafür vorgesehenenServer angekommen ist. Technischgesehen müssen die Fotos folgendenProzess durchlaufen:

Kopieren der Fotos vom Ori-ginaldatenträger in eine Quarantä-nezone und Anlegen von Integritäts-signaturen für jedes Foto in einemProtokoll

Sicheres Device-ManagementSysteme und ihr Umfeld

Prüfung aller Fotos auf Vi-renfreiheit (Freiheit von sog. Mali-cious Code) sowie inhaltlicher (se-mantischer) und syntaktischer Kor-rektheit: Dabei sind nicht nur diebekannten JPG-Formate EXIF undJFIF zu berücksichtigen, sondernauch die (Kamera-)herstellertypi-schen Rohformate, die eine höhereAuflösung und damit die Grundvor-aussetzung für forensisch detaillierteAnalysen bieten.

Nach positiver Prüfung folgtdie Übertragung der Fotos auf denServer

Die Rückmeldung des Ser-vers auf einem sicheren Kanal liefertIntegritätssignaturen zu jedem ein-zelnen Foto, die mit jedem Original-Foto verglichen werden. Erst wenndieser Inhalt korrekt über den siche-ren Kanal bestätigt ist, wird einLöschzertifikat erstellt.

Das Foto wird vom Original-datenträger gelöscht und das Lösch-protokoll archiviert.

Die digitalen Originalbilder(volles Datenvolumen) werden aufeinem lokalen File-Server im LAN dererfassenden Dienststelle gespeichert.Ein Vorschau-Bild nebst automati-siert erzeugten Metadaten wirdzudem an das Bayerische Landeskri-minalamt (BLKA) übertragen, dasdiese Informationen in einer zentra-len Bilddatenbank erfasst und bereit-stellt. Die Bildverwaltung über-nimmt dabei das Produkt „Pixelbo-xx“ (vgl. Abb. 2) – das gesamte Ver-fahren läuft auf einem zentralen Ap-plikationsserver und einem Daten-bankserver (mit Oracle 10g alsDBMS). Unter bestimmten Voraus-setzungen ist zudem vorgesehen, zunetzlastarmen Zeiten auch die volu-minösen Vollbilder zu einer überge-ordneten Dienststelle zeitversetzt zuübertragen.

Alle einzelnen Schritte undihre Ergebnisse müssen zudem in ei-nem gemeinsamen Protokoll (Log-

17-21 (Tatortfotos) 07.04.2006, 17:02 Uhr2001 kes 2006-2 (4-seiter).indd 3 24.08.12 17:10

21© SecuMedia Verlags-GmbH · 55205 Ingelheim · <kes> 2006#2

File) revisionssicher hinterlegt wer-den. Der Investitionsschutz verbietethier offenkundig proprietäre Lösun-gen, die nur auf einen (oder einzelne)Kamerahersteller zugeschnitten sindoder bei der Freigabe eines neuenKameratyps eine Anpassung an derSoftware benötigen, da der hiermitverbundene Qualitätssicherungspro-zess zu teuer und zudem zu langsamwäre, um auf dem schnelllebigenGerätemarkt geeignet reagieren zukönnen.

Ergonomie und Kosteneffizienz

Neben der Sicherheit lagenzudem Anforderungen an Ergono-mie und kostengünstigen Betrieb imFokus des DiFo-Projekts. Im Folgen-den seien hier stellvertretend nur ei-nige signifikante Eigenschaften auf-geführt:

Der DiFo-Prozess ist automa-tisiert zu starten, sobald eine Kameraper externer Schnittstelle ange-schlossen wird.

Der Benutzer muss über dasFortschreiten des Prozesses perma-nent informiert bleiben.

Der Anwender muss durcheine abschließende Meldung überden Status und eventuell notwendi-ge Folgeaktivitäten unterrichtet wer-den; hierbei war es wichtig, eigeneFormulierungen einbringen zu kön-nen.

Prinzipiell ist eine White-Listfür Kameras und Flash-Datenträgerdurchzusetzen, da keine privat er-worbenen Datenträger verwendetwerden dürfen.

Die Freigabe eines neuenTyps muss im laufenden Betrieb voneiner zentralen Stelle für alle Benutzeroder einzelne Benutzer mit minima-lem Aufwand (unter fünf Minuten)möglich sein. Dies schließt auch diesyntaktische und semantische Prü-fung der Bildinhalte mit ein (auch inden jeweiligen Rohdatenformaten).

Eine Prozesseinbindung beider Beschaffung muss insofern gege-ben sein, dass das Plug-in einer ver-botenen Kamera den Nutzer sofortmit der Information versorgt, wie erden Beschaffungsvorgang einer frei-gegebenen Kamera initiiert. Es dür-fen hier keine überflüssigen Telefo-nate entstehen.

Der Life-Cycle der Sicher-heitseinstellungen (Security Policy)muss sich in einfacher und revisions-sicherer Weise auch in einen Quali-tätszyklus mit Test-, Validierungs-und Produktionsumgebung abbil-den lassen, ohne die gesamte Infra-struktur zu doppeln.

Wünschenswert ist zudemeine enge Einbindung in den Service-Desk, der über Plug&Play-Fehler ambesten in Echtzeit informiert werdensollte.

Fazit

Das DiFo-Projekt hatinsgesamt eine sichere Plattform er-forderlich gemacht, welche die fol-genden abstrakten Anforderungenerfüllt und dabei offen für die Inte-gration eigener Erweiterungen oderSonderwünsche ist:

detailliertes Logging,

Integration eigener Prozesse(z. B. als Plug-in mit einer Auto-Start-Funktion als Reaktion auf bestimmteEreignisse wie den Anschluss einerneuen Kamera),

im Produkt vorgeseheneStandardprozesse (z. B. Beantragungund Beschaffung sowie Life-Cycle-Management der Security Policies),

Content-Filter mit inhaltli-cher Prüfung (semantische und syn-taktische Elemente kundenseitig er-weiterbar).

Aus projektübergreifenderSicht sind neben den genannten„harten“ Faktoren auch einige „wei-

Literatur

[1] Peter Scholz, Plug & Plague, Si-cherheitsdefizite durch automatischeGeräteerkennung, <kes> 2004#1, S. 6

[2] Peter Scholz, UnbekannteSchwachstellen in Hardware und Be-triebssystemen, in: Handbuch derTelekommunikation, Wolters Klu-wer Verlag, März 2005, ISBN 3-87156-096-0

che“ Entscheidungsgründe von Be-deutung: Die Auswahl einer neuentragfähigen IT-Plattform und die dar-auf aufsetzenden Geschäftsprozesseist mit hohem Aufwand verbundenund wird deshalb nur in Zeitabstän-den von fünf bis zehn Jahren erneu-ert. Die Entscheidung für eine Soft-warelösung, die (nur) alle Projekt-anforderungen sicher und effizientabdeckt, ist deshalb zu kurz gegriffen.Vielmehr müssen die Lösungen fürdas DiFo-Projekt eine Basis bilden,die auch andere Anforderungen ausdem E-Government für den sicherenund kosteneffizienten Betrieb vonSchnittstellen und Geräten erfüllt.

DeviceWatch ist mittler-weile auf allen 20 000 PCs der Bayer-ischen Polizei im produktiven Ein-satz. Es gibt keine offenen Support-Calls und es gab weder während derValidierung noch dem Roll-Outnennenswerte negative Vorkomm-nisse. Die Lösung hat sich bislang füralle skizzierten Herausforderungenbewährt. �

Walter Wust (Walter.Wust@Polizei.Bayern.de) ist Leiter Sachgebiet IuK desPolizeipräsidiums Oberbayern.

17-21 (Tatortfotos) 07.04.2006, 17:02 Uhr2101 kes 2006-2 (4-seiter).indd 4 24.08.12 17:10