Baustein B 5.24 Web-Services

Schicht Anwendungen B 5.24

IT-Grundschutz-Kataloge: 14. EL Stand 2014 1

B 5.24 Web-Services

Beschreibung

Web-Services im Sinne dieses Bausteins sind alle IT-Services, die von einem Betreiber für einen odermehrere Dienstnehmer (engl.: Consumer) bereitgestellt und über netzbasierte Schnittstellen, in der Re-gel auf der Grundlage des HTTP-Protokolls, aufgerufen werden können.

In der Abgrenzung zu Webanwendungen (siehe Baustein B 5.21 Webanwendungen) verfügt der Web-Service dabei über keine Client-Komponente oder visualisierbare Web-Oberfläche, sondern bietet seineFunktionalität über eine definierte Schnittstelle an, die vom Consumer des Web-Service (in der Regelautomatisiert) aufgerufen wird. Web-Services können dabei auch von anderen Web-Services aufgeru-fen werden und mit diesen zusammen eine komplexere übergeordnete Funktionalität realisieren. DieZusammenstellung verschiedener Web-Services zur Realisierung einer bestimmten Funktionalität wirddabei als Orchestrierung bezeichnet und kann anhand von standardisierten Schnittstellenbeschreibun-gen auch dynamisch erfolgen. Solche komplexen Architekturen werden als Service-orientierte Architek-turen (SOA) bezeichnet und können sich auch über Organisationsgrenzen hinweg erstrecken.

An den Schnittstellen kommen typischerweise entweder das XML-basierte SOAP oder das objektorien-tierte REST-Konzept zum Einsatz. Für Web-Services und ihre Schnittstellen sind zahlreiche Standardspubliziert, die in der W-Maßnahme M 4.451 Aktuelle Web-Service Standards in diesem Baustein vorge-stellt werden.

Dieser Baustein betrachtet Web-Services stets aus der Sicht des Betreibers. Intitutionen, die ausschließ-lich als Consumer von Web-Services agieren, modellieren diesen Baustein entsprechend nicht, sondernverwenden geeignete Bausteine wie B 1.11 Outsourcing oder B 1.17 Cloud-Nutzung.

Obwohl Webanwendungen und Web-Services über Gemeinsamkeiten verfügen und teilweise überlap-pende Sicherheitsmaßnahmen erfordern, wurden im Sinne einer einfacheren Anwendung der IT-Grund-schutz-Kataloge beide Bausteine jeweils in sich vollständig erstellt, sodass diese Bausteine alternativanzuwenden sind, je nachdem, ob die betrachtete Anwendung über eine Benutzer-Oberfläche verfügt(Anwendung des Bausteins Webanwendungen) oder über eine standardisierte Schnittstelle aufgerufenwird (Anwendung des Bausteins Web-Service). Für komplexe Anwendungen, die einerseits eine Web-Anwendung sind, andererseits aber auch Web-Services für andere IT-Systeme bereitstellen, sollen bei-de Bausteine zusammen modelliert werden.

Gefährdungslage

Die folgenden Gefährdungen sind beim Einsatz von Web-Services relevant:

Organisatorische Mängel- G 2.1 Fehlende oder unzureichende Regelungen- G 2.7 Unerlaubte Ausübung von Rechten- G 2.22 Fehlende oder unzureichende Auswertung von Protokolldaten- G 2.27 Fehlende oder unzureichende Dokumentation- G 2.61 Unberechtigte Sammlung personenbezogener Daten- G 2.67 Ungeeignete Verwaltung von Zugangs- und Zugriffsrechten- G 2.87 Verwendung unsicherer Protokolle in öffentlichen Netzen- G 2.103 Unzureichende Schulung der Mitarbeiter- G 2.158 Mängel bei der Entwicklung und der Erweiterung von Webanwendungen und Web-

Services- G 2.159 Unzureichender Schutz personenbezogener Daten bei Webanwendungen und Web-

Services- G 2.160 Fehlende oder unzureichende Protokollierung- G 2.181 Mangelhafte Planung und Konzeption des Einsatzes von Web-Services



Menschliche Fehlhandlungen- G 3.3 Nichtbeachtung von Sicherheitsmaßnahmen- G 3.16 Fehlerhafte Administration von Zugangs- und Zugriffsrechten- G 3.38 Konfigurations- und Bedienungsfehler- G 3.119 Fehlerhafte Anwendung von Standards- G 3.120 Fehler bei der Orchestrierung- G 3.121 Konfigurations- und Administrationsfehler bei Web-Services

Technisches Versagen- G 4.13 Verlust gespeicherter Daten- G 4.22 Software-Schwachstellen oder -Fehler- G 4.33 Schlechte oder fehlende Authentikation- G 4.35 Unsichere kryptographische Algorithmen- G 4.84 Unzureichende Validierung von Ein- und Ausgabedaten bei Webanwendungen und

Web-Services- G 4.85 Fehlende oder mangelhafte Fehlerbehandlung durch Webanwendungen und Web-

Services- G 4.87 Offenlegung vertraulicher Informationen bei Webanwendungen und Web-Services- G 4.94 Unbefugter Zugriff auf Daten eines anderen Mandanten bei Webanwendungen und

Web-Services

Vorsätzliche Handlungen- G 5.18 Systematisches Ausprobieren von Passwörtern- G 5.19 Missbrauch von Benutzerrechten- G 5.20 Missbrauch von Administratorrechten- G 5.28 Verhinderung von Diensten- G 5.87 Web-Spoofing- G 5.131 SQL-Injection- G 5.165 Unberechtigter Zugriff auf oder Manipulation von Daten bei Webanwendungen und

Web-Services- G 5.167 Fehler in der Logik von Webanwendungen und Web-Services- G 5.168 Umgehung clientseitig umgesetzter Sicherheitsfunktionen von Webanwendungen und

Web-Services- G 5.169 Unzureichendes Session-Management von Webanwendungen und Web-Services- G 5.172 Umgehung der Autorisierung bei Webanwendungen und Web-Services- G 5.173 Einbindung von fremden Daten und Schadcode bei Webanwendungen und Web-

Services- G 5.174 Injection-Angriffe- G 5.179 Angriffe auf Protokolle- G 5.180 Angriffe auf Registries und Repositories- G 5.181 Angriffe auf das Identitäts- und Zugriffsmanagement bei Web-Services- G 5.182 Manipulation von Routen (Routing Detours)- G 5.183 Angriffe auf XML- G 5.184 Informationsgewinnung über Web-Services

Maßnahmenempfehlungen

Um den betrachteten Informationsverbund abzusichern, müssen zusätzlich zu diesem Baustein nochweitere Bausteine umgesetzt werden, gemäß den Ergebnissen der Modellierung nach IT-Grundschutz.

Im Rahmen des Einsatzes von Web-Services sind eine Reihe von Maßnahmen umzusetzen, beginnendmit der Konzeption über die Beschaffung bis zum Betrieb. Die Schritte, die dabei zu durchlaufen sind,sowie die Maßnahmen, die in den jeweiligen Schritten beachtet werden sollten, sind im Folgenden auf-geführt. Die hier beschriebenen Maßnahmen decken die vorstehenden Gefährdungen für den normalenSchutzbedarf ab.



Planung und Konzeption

Wie bei jeder anderen Art von Anwendung gilt auch für Web-Services, dass die Weichen für eine sichereRealisierung in der Planungsphase gestellt werden. Dies bedeutet insbesondere klare Verantwortlich-keiten, wie in der Maßnahme M 2.1 Festlegung von Verantwortlichkeiten und Regelungen gefordert.

Funktionalität, Architektur und Realisierung des Web-Services müssen geplant (M 4.458 Planung desEinsatzes von Web-Services ) und dokumentiert (M 2.486 Dokumentation der Architektur von Weban-wendungen und Web-Services) sein. Je nachdem, ob der Web-Service durch Lösungen Dritter oderdurch Eigenentwicklung realisiert wird, sind die Maßnahmen M 2.80 Erstellung eines Anforderungska-talogs für Standardsoftware beziehungsweise M 2.487 Entwicklung und Erweiterung von Anwendungenzu berücksichtigen. Sofern der Web-Service ein bereits vorhandenes System ablöst oder Daten darausübernimmt, muss auch die Migration in die Planungsphase eingeschlossen werden (M 2.530 Planungund Vorbereitung von Migrationen ).

Ein weiterer wichtiger Aspekt für die Planung sind Sicherheitsaspekte des Web-Service. Die dazuvorgesehenen Maßnahmen sollten schriftlich festgehalten werden (M 2.531 Erarbeitung einer Sicher-heitsrichtlinie für Web-Services ) und umfassen konzeptionelle Maßnahmen gegen SQL-Injections(M 2.363 Schutz gegen SQL-Injection) ebenso wie Maßnahmen zur sicheren Trrennung der Daten ver-schiedener Mandanten und Nutzer (M 4.457 Sichere Mandantentrennung bei Webanwendungen undWeb-Services) und Konzepte zur Absicherung der Schnittstellen (M 5.168 Sichere Anbindung von Hin-tergrundsystemen an Webanwendungen und Web-Services).

Beschaffung

Die Beschaffung von Komponenten und Lösungen für Web-Services muss nachvollziehbar und geord-net ablaufen und die Prozesse für die Abnahme und Freigabe von IT-Komponenten berücksichtigen(M 2.62 Software-Abnahme- und Freigabe-Verfahren). Bietet der Betreiber den Web-Service auch Drit-ten zur Nutzung an, sind die in der Maßnahme M 2.533 Vertragliche Aspekte bei der Bereitstellung vonWeb-Services beschriebenen Aspekte bei der Vertragsgestaltung mit den Consumern zu berücksich-tigen.

Umsetzung

Insbesondere dann, wenn Web-Services als Dienstleistung für Dritte angeboten werden, müssen si-cherheitsrelevante Fragen zwischen Anbieter und Consumer geklärt und geregelt werden (MaßnahmeM 2.532 Anbieten von Web-Services für Dritte).

Bei der Realisierung von Web-Services sind einerseits Maßnahmen für die sichere Web-Entwicklung zubeachten, wie sie auch für Webanwendungen gelten: Von der Validierung von Ein- und Ausgabedaten(M 4.393 Umfassende Ein- und Ausgabevalidierung bei Webanwendungen und Web-Services) überein robustes Session-Management (M 4.394 Session-Management bei Webanwendungen und Web-Services) bis zur Vermeidung der Preisgabe unnötiger Informationen in der Fehlerbehandlung und in denSchnittstellenbeschreibungen (M 4.395 Fehlerbehandlung durch Webanwendungen und Web-Servicesund M 4.400 Restriktive Herausgabe sicherheitsrelevanter Informationen bei Webanwendungen undWeb-Services).

Darüber hinaus sind spezifische Sicherheitsprobleme von Web-Services zu adressieren: Dies umfassteinerseits die sichere Identifizierung und Authentisierung von Web-Service-Dienstnehmer (M 4.456 Au-thentisierung bei Web-Services) einschließlich von Maßnahmen zur Verhinderung der Nutzung durchUnberechtigte (M 4.454 Schutz vor unerlaubter Nutzung von Web-Services). Sofern die Architektur desWeb-Services dafür einen Secure-Token-Service (STS) vorsieht, finden sich Hinweise zur richtigen Um-setzung in der Maßnahme M 4.453 Einsatz eines Security Token Service (STS).

Andererseits muss bei jedem Aufruf des Web-Service sichergestellt werden, dass die aufgerufene Funk-tionalität durch die Berechtigungen des Aufrufers abgedeckt ist (M 4.454 Schutz vor unerlaubter Nut-zung von Web-Services). Die Kommunikation zwischen Web-Service und Aufrufer muss geeignet ge-schützt werden (M 4.450 Absicherung der Kommunikation bei Web-Services), insbesondere wenn sieüber unsichere Netze erfolgt.



Ist die Schnittstelle des Web-Service für einen größeren Personenkreis oder gar aus öffentlichen Netzenheraus erreichbar, sollten entsprechende Maßnahmen gegen Angriffe auf die Verfügbarkeit des Web-Service umgesetzt werden (M 4.405 Verhinderung der Blockade von Ressourcen (DoS) bei Weban-wendungen und Web-Services). Um die Robustheit des Web-Service gegen Angriffe zu erhöhen, kannzusätzlich der Einsatz eines XML-Gateways erwogen werden (M 5.175 Einsatz eines XML-Gateways).

Betrieb

Fragen des sicheren Betriebs von Web-Services umfassen zunächst die Dokumentation und Einrichtungvon Berechtigungen für die Consumer (auch wenn der Web-Service durch Anwendungen oder andereWeb-Services automatisiert aufgerufen wird, siehe M 2.7 Vergabe von Zugangsberechtigungen undM 2.31 Dokumentation der zugelassenen Benutzer und Rechteprofile).

Nutzer und Administratoren müssen mit den für sie relevanten Sicherheitsmaßnahmen ausreichendvertraut sein (M 3.5 Schulung zu Sicherheitsmaßnahmen).

Der Betrieb des Web-Service muss durch geeignete Maßnahmen zur Protokollierung nachvollziehbarsein (M 4.397 Protokollierung sicherheitsrelevanter Ereignisse von Web-Anwendungen und Web-Ser-vices). Da von der Protokollierung in der Regel auch personenbezogene Daten betroffen sind, müssendabei die Anforderungen des Datenschutzes geeignet berücksichtigt werden (M 2.110 Datenschutza-spekte bei der Protokollierung). Um sicherheitsrelevante Vorfälle rechtzeitig zu erkennen, muss eineKontrolle der Protokolldateien sichergestellt werden (M 2.64 Kontrolle der Protokolldateien), gegebe-nenfalls durch automatisierte Systeme.

Veränderungen im laufenden Betrieb müssen sorgfältig durchgeführt (M 4.78 Sorgfältige Durchführungvon Konfigurationsänderungen) und dokumentiert werden (M 2.34 Dokumentation der Veränderungenan einem bestehenden System). Insbesondere ist darauf zu achten, dass bekannt werdende Sicher-heitslücken im Web-Service oder einer der von ihm genutzten Komponenten, Frameworks oder Bi-bliotheken dem Betreiber zur Kenntnis gelangen (M 2.35 Informationsbeschaffung über Sicherheits-lücken des Systems) und nach Möglichkeit behoben oder in anderer Form geeignet behandelt werden(M 2.273 Zeitnahes Einspielen sicherheitsrelevanter Patches und Updates).

Der ordnungsgemäße, sichere und störungsfreie Betrieb des Web-Service muss durch geeignete Über-wachungsmaßnahmen sichergestellt werden (M 4.452 Überwachung eines Web-Service). Regelmäßi-ge Schwachstellentests dienen zusätzlich der Prävention von Angriffen (M 5.150 Durchführung von Pe-netrationstests).

Notfallvorsorge

Ein geeignetes Datensicherungskonzept ist auch für Web-Services eine zentrale Maßnahme der Notfall-vorsorge (M 6.32 Regelmäßige Datensicherung). Weitere Maßnahmen zur Vorsorge und Bewältigungvon Notfällen sind in der Maßnahme M 6.154 Notfallmanagement für Web-Services zusammengefasst.

Planung und Konzeption- M 2.1 (A) Festlegung von Verantwortlichkeiten und Regelungen- M 2.80 (A) Erstellung eines Anforderungskatalogs für Standardsoftware- M 2.363 (B) Schutz gegen SQL-Injection- M 2.486 (A) Dokumentation der Architektur von Webanwendungen und Web-Services- M 2.487 (B) Entwicklung und Erweiterung von Anwendungen- M 2.530 (B) Planung und Vorbereitung von Migrationen- M 2.531 (A) Erarbeitung einer Sicherheitsrichtlinie für Web-Services- M 4.451 (W) Aktuelle Web-Service Standards- M 4.457 (B) Sichere Mandantentrennung bei Webanwendungen und Web-Services- M 4.458 (A) Planung des Einsatzes von Web-Services- M 5.168 (A) Sichere Anbindung von Hintergrundsystemen an Webanwendungen und Web-

ServicesBeschaffung- M 2.62 (B) Software-Abnahme- und Freigabe-Verfahren- M 2.533 (C) Vertragliche Aspekte bei der Bereitstellung von Web-Services



Umsetzung- M 2.532 (B) Anbieten von Web-Services für Dritte- M 4.393 (B) Umfassende Ein- und Ausgabevalidierung bei Webanwendungen und Web-

Services- M 4.394 (A) Session-Management bei Webanwendungen und Web-Services- M 4.395 (B) Fehlerbehandlung durch Webanwendungen und Web-Services- M 4.405 (C) Verhinderung der Blockade von Ressourcen (DoS) bei Webanwendungen und

Web-Services- M 4.450 (A) Absicherung der Kommunikation bei Web-Services- M 4.453 (Z) Einsatz eines Security Token Service (STS)- M 4.454 (A) Schutz vor unerlaubter Nutzung von Web-Services- M 4.455 (A) Autorisierung bei Web-Services- M 4.456 (A) Authentisierung bei Web-Services- M 5.175 (Z) Einsatz eines XML-GatewaysBetrieb- M 2.8 (A) Vergabe von Zugriffsrechten- M 2.31 (A) Dokumentation der zugelassenen Benutzer und Rechteprofile- M 2.34 (A) Dokumentation der Veränderungen an einem bestehenden System- M 2.35 (B) Informationsbeschaffung über Sicherheitslücken des Systems- M 2.64 (A) Kontrolle der Protokolldateien- M 2.110 (A) Datenschutzaspekte bei der Protokollierung- M 2.273 (A) Zeitnahes Einspielen sicherheitsrelevanter Patches und Updates- M 3.5 (A) Schulung zu Sicherheitsmaßnahmen- M 4.78 (A) Sorgfältige Durchführung von Konfigurationsänderungen- M 4.397 (C) Protokollierung sicherheitsrelevanter Ereignisse von Web-Anwendungen und Web-

Services- M 4.400 (B) Restriktive Herausgabe sicherheitsrelevanter Informationen bei Webanwendungen

und Web-Services- M 4.452 (A) Überwachung eines Web-Service- M 5.150 (Z) Durchführung von PenetrationstestsNotfallvorsorge- M 6.32 (A) Regelmäßige Datensicherung- M 6.154 (B) Notfallmanagement für Web-Services

Goldene Regeln

Betreiber von Web-Services müssen die im folgenden aufgeführten Regeln berücksichtigen, um eineangemessene Sicherheit umzusetzen:

1. Die Architektur des Web-Services muss dokumentiert werden. Es muss nachvollziehbar sein, welcheKomponenten genutzt werden, und welche Geschäftsprozesse und Aufgaben mit den Web-Servicesabgebildet werden.

2. Die Entwicklung von Web-Services muss einem geordneten Softwareentwicklungsprozess folgen.Dies umfasst die Anforderungsanalyse, die Konzeption und das Design der Anwendung, die Entwick-lung, das Testen, die Qualitätssicherung sowie die Integration und das unternehmensweite Ausrollendes Web-Services.

3. Der Einsatz der gewählten Web-Service-Standards muss bereits während der Planungs- und Kon-zeptionsphase gründlich vorbereitet werden. Die Verwendung unerprobter oder wenig verbreiteter Stan-dards und Frameworks sollte gemieden werden. Die Planung muss auch das Zusammenwirken mehre-rer Services für eine übergreifende Aufgabe (Orchestrierung) einbeziehen .

4. Bei der Migration von bestehenden Anwendungen in eine Web-Service-Architektur muss geprüft wer-den, ob die grundlegenden Annahmen der Sicherheitsarchitektur noch stimmen und mit einem Web-Service abbildbar sind.

5. Bei der Entwicklung von Web-Services ist darauf zu achten, dass für die Authentisierung sichereAlgorithmen, Protokolle und Techniken genutzt werden (starke Authentisierungsverfahren). Dabei ist zu



beachten, dass die Authentisierung für alle Kommunikationsverbindungen (Benutzer/Webservice, aberauch Web-Service/Web-Service) beidseitig und sicher erfolgt.

6. Eine Zugriffskontrolle muss die unbefugte Nutzung geschützter Funktionen sowie die Einsicht undManipulation von geschützten Informationen verhindern können. Die Zugriffskontrolle muss bei jedemAufruf eines Web-Service greifen und darf sich nicht auf einen bestimmten Anwendungskontext verlas-sen.

7. Zum Schutz vor Angriffen müssen alle Daten vor der Weitergabe an Schnittstellen so behandelt wer-den, dass für die Schnittstelle relevante Sonderzeichen korrekt kodiert sind. Dabei sollten alle dynami-schen Daten als vom Benutzer beeinflussbar angesehen werden. Werden generische Parser genutzt(vor allem bei XML), so muss zusätzlich darauf geachtet werden, dass Parserfunktionalität nicht uner-laubt durch die Nachrichten selbst modifiziert werden kann (zum Beispiel durch Angabe externer Refe-renzen in XML).

8. Wenn Web-Services für Dritte bereitgestellt werden, so müssen die genauen Modalitäten der Nutzungder Dienste zwischen Anbieter und Consumer geregelt sein. Insbesondere gehören dazu die Verteilungder Zuständigkeiten, die Definition von Schnittstellen und Ansprechpartnern sowie die Vereinbarung vonBerichtspflichten und Prüfrechten.

Die Sicherheitsempfehlungen zum Thema Web-Services müssen zielgruppengerecht aufbereitet undinstitutionsweit veröffentlicht werden. Weitere Informationen finden sich im Baustein B 5.24 Web-Ser-vices und in den weiteren Bereichen der IT-Grundschutz-Kataloge.

Gefährdungskatalog Organisatorische Mängel G 2.1 Bemerkungen


G 2.1 Fehlende oder unzureichendeRegelungen

Die Bedeutung übergreifender organisatorischer Regelungen und Vorgabenfür das Ziel Informationssicherheit nimmt mit dem Umfang der Informations-verarbeitung, aber auch mit dem Schutzbedarf der zu verarbeitenden Infor-mationen zu.

Von der Frage der Zuständigkeiten angefangen bis hin zur Verteilung von Kon-trollaufgaben kann das Spektrum der Regelungen sehr umfangreich sein. Aus-wirkungen von fehlenden oder unzureichenden Regelungen werden beispiel-haft in den anderen Gefährdungen des Gefährdungskatalogs G2 beschrieben.

Vielfach werden nach Veränderungen technischer, organisatorischer oderpersoneller Art, die wesentlichen Einfluss auf die Informationssicherheit ha-ben, bestehende Regelungen nicht angepasst. Veraltete Regelungen könneneinem störungsfreien Betrieb entgegen stehen. Probleme können auch da-durch entstehen, dass Regelungen unverständlich oder zusammenhanglosformuliert sind und dadurch missverstanden werden.

Dass Regelungsdefizite zu Schäden führen können, machen folgende Bei-spiele deutlich:

- Durch eine mangelhafte Betriebsmittelverwaltung kann der termingerech-te Arbeitsablauf in einem Rechenzentrum schon durch eine unterbliebeneDruckerpapierbestellung stark beeinträchtigt werden.

- Neben einer Beschaffung von Handfeuerlöschern muss auch deren regel-mäßige Wartung geregelt sein, um sicherzustellen, dass diese im Brand-fall auch funktionstüchtig sind.

- Bei einem Wasserschaden wird festgestellt, dass dieser auch den darunterliegenden Serverraum in Mitleidenschaft zieht. Durch eine unzureichendeSchlüsselverwaltung kann der Wasserschaden im Serverraum allerdingsnicht unmittelbar behoben werden, weil keiner darüber informiert ist, wosich der Schlüssel zum Serverraum gerade befindet. Dadurch steigt derSchaden erheblich.



G 2.7 Unerlaubte Ausübung vonRechten

Rechte wie Zutritts-, Zugangs- und Zugriffsberechtigungen werden als orga-nisatorische Maßnahmen eingesetzt, um Informationen, Geschäftsprozesseund IT-Systeme vor unbefugtem Zugriff zu schützen. Werden solche Rechtean die falsche Person vergeben oder wird ein Recht unautorisiert ausgeübt,können sich eine Vielzahl von Gefahren für die Vertraulichkeit und Integritätvon Daten oder die Verfügbarkeit von Rechnerleistung ergeben.

Beispiele:- Der Arbeitsvorbereiter, der keine Zutrittsberechtigung zum Datenträgerar-

chiv besitzt, entnimmt in Abwesenheit des Archivverwalters Magnetbän-der, um Sicherungskopien einspielen zu können. Durch die unkontrollierteEntnahme wird das Bestandsverzeichnis des Datenträgerarchivs nicht ak-tualisiert, die Bänder sind für diesen Zeitraum nicht auffindbar. Der Arbeits-vorbereiter, der keine Zutrittsberechtigung zum Datenträgerarchiv besitzt,entnimmt in Abwesenheit des Archivverwalters Magnetbänder, um Siche-rungskopien einspielen zu können. Durch die unkontrollierte Entnahmewird das Bestandsverzeichnis des Datenträgerarchivs nicht aktualisiert,die Bänder sind für diesen Zeitraum nicht auffindbar.

- Ein Mitarbeiter ist erkrankt. Ein Zimmerkollege weiß aufgrund von Beob-achtungen, wo dieser sein Passwort auf einem Merkzettel aufbewahrt undverschafft sich Zugang zum Rechner des anderen Mitarbeiters. Da er erstkürzlich durch ein Telefonat mitbekommen hat, dass der Kollege noch ei-ne fachliche Stellungnahme abzugeben hatte, nimmt er hier unberechtig-terweise diese Aufgabe im Namen seines Kollegen wahr, obwohl er zuder Thematik nicht auf dem aktuellen Sachstand ist. Eine daraus folgen-de Erstellung einer Ausschreibungsunterlage in der Verwaltungsabteilungfordert im Pflichtenheft daher eine längst veraltete Hardwarekomponente,weil die dortigen Mitarbeiter der fachlichen Stellungnahme des erfahrenenKollegen uneingeschränkt vertraut haben.



G 2.22 Fehlende oder unzureichendeAuswertung von Protokolldaten

In vielen IT-Systemen und Anwendungen sind Funktionalitäten integriert, umbestimmte Ereignisse in ihrem zeitlichen Ablauf protokollieren zu können. Da-durch werden in einem Informationsverbund oft große Mengen an Protokoll-daten erzeugt, die sich nur schwer und mit einem hohen Zeitaufwand auswer-ten lassen. Allerdings ist eine sinnvolle Auswertung dieser Protokolldaten not-wendig, um beispielsweise Fehleranalysen durchführen und erfolgte Angriffeidentifizieren zu können.

Im Lebenszyklus eines IT-Systems kommen verschiedene Protokollierungs-konzepte zum Einsatz. So werden während der Entwicklungsphase ausführli-che Protokolle erstellt, um die Problemanalyse bei Fehlern zu erleichtern.

In der Einführungsphase werden Protokolle genutzt, um unter anderem diePerformance des IT-Systems in der Produktivumgebung zu optimieren oderum die Wirksamkeit des Sicherheitskonzepts erstmals in der Praxis zu über-prüfen.

In der Produktivphase dienen Protokolle hauptsächlich dazu, den ordnungs-gemäßen Betrieb sicherzustellen. Über Protokolldaten werden dann unter an-derem nachträglich Sicherheitsverletzungen im IT-System oder Angriffsversu-che identifiziert. Die Protokollierung kann auch der Täterermittlung und in Fol-ge der Abschreckung von potenziellen Tätern dienen. Über eine regelmäßigeAuswertung der Protokolldaten lassen sich die Daten für Präventivmaßnah-men wie ein Frühwarnsystem heranziehen, wodurch unter Umständen vor-sätzliche Angriffe auf ein IT-System frühzeitig erkannt oder vereitelt werdenkönnen.

Zentrale Protokollierung

Werden Protokolldaten an zentraler Stelle ausgewertet, ist es möglich, dassbei der großen Menge an Daten wichtige Informationen übersehen und zumBeispiel Angriffe nicht entdeckt werden. Aus diesem Grund gibt es Systeme,die den Administrator bei der Auswertung der Protokolldaten unterstützen oderdie Daten sogar selbstständig auswerten. Je nach Produkt können die Infor-mationen der verschiedenen Datenquellen miteinander vereint und zu einerProtokollmeldung verarbeitet werden. Es besteht jedoch die Gefahr, dass dieProtokolldaten eventuell nicht mehr auf ihre ursprüngliche Datenquelle zurück-geführt werden können, sodass auch nicht mehr auf Anhieb nachvollzogenwerden kann, wo das Ereignis ursprünglich aufgetreten ist.

Weitere Probleme bei der Auswertung können durch falsch eingestellte Fil-terfunktionen der Analysewerkzeuge entstehen. Das kann dazu führen, dassProtokolldaten, die für die Störungserkennung, Fehlersuche oder Frühwar-nung erforderlich sind, nicht ausgewertet werden.

Beispiele:- Ein Angreifer versucht, den Datenbank-Server durch eine DoS-Attacke

zum Absturz zu bringen. Dieser Angriff wird auf dem betreffenden IT-Sy-stem protokolliert. Der Angriff bleibt aber durch die fehlende Auswertungder Protokolldaten unentdeckt, und der Angreifer kann die DoS-Attackebis zum Erfolg wiederholen.

- Bei einem Angriff auf einen Webserver wurde eine RPC-Sicherheitslückedazu benutzt, um in das System einzudringen. Zwar hat der Webserverentsprechende Protokolldaten erzeugt, diese wurden jedoch aufgrund feh-



lerhafter Filtereinstellungen am zentralen Protokollierungsserver verwor-fen. Somit wurde kein automatischer Alarm ausgelöst, und der Angriff bliebunentdeckt.



G 2.27 Fehlende oder unzureichendeDokumentation

Verschiedene Formen der Dokumentation können betrachtet werden: die Pro-duktbeschreibung, die Administrator- und Benutzerdokumentation zur Anwen-dung des Produktes und die Systemdokumentation.

Eine fehlende oder unzureichende Dokumentation der eingesetzten IT-Kom-ponenten kann sowohl im Auswahl- und Entscheidungsprozess für ein Pro-dukt, als auch bei einem Schadensfall im Wirkbetrieb erhebliche Auswirkun-gen haben.

Bei einer unzureichenden Dokumentation kann sich im Schadensfall, bei-spielsweise durch den Ausfall von Hardware bzw. Fehlfunktionen von Pro-grammen, die Fehlerdiagnose und -behebung erheblich verzögern oder völligundurchführbar sein.

Dies gilt auch für die Dokumentation von Leitungswegen und Verkabelungeninnerhalb der Gebäude-Infrastruktur. Ist aufgrund unzureichender Dokumen-tation die genaue Lage von Leitungen nicht bekannt, so kann es bei Bauarbei-ten außerhalb oder innerhalb eines Gebäudes zu Beschädigungen von Leitun-gen kommen. Dabei kann es zu längeren Ausfallzeiten (Eintritt eines Notfalls)oder unter Umständen sogar zu lebensbedrohenden Gefahren, zum Beispieldurch Stromschlag, kommen.

Beispiele:- Wenn von einem Programm Arbeitsergebnisse in temporären Dateien zwi-

schengespeichert werden, ohne dass dies ausreichend dokumentiert ist,kann dies dazu führen, dass die temporären Dateien nicht angemessengeschützt und vertrauliche Informationen offengelegt werden. Durch feh-lenden Zugriffsschutz auf diese Dateien oder eine nicht korrekte physika-lische Löschung der nur temporär genutzten Bereiche können Informatio-nen Unbefugten zugänglich werden.

- Bei Installation eines neuen Softwareproduktes werden bestehende Kon-figurationen abgeändert. Andere, bislang fehlerfrei laufende Programme,sind danach falsch parametrisiert und stürzen gegebenenfalls ab. Durcheine detaillierte Dokumentation der Veränderung bei der Installation vonSoftware ließe sich der Fehler schnell lokalisieren und beheben.

- In einer größeren Behörde wurde die Verkabelung der IT durch eine ex-terne Firma vorgenommen. Die Anfertigung einer Dokumentation war imLeistungsumfang nicht enthalten. Da nach Fertigstellung der Verkabelungmit der Firma kein Wartungsvertrag abgeschlossen wurde, verfügte dieBehörde nicht über die notwendige Dokumentation. Erweiterungen desNetzes konnten nur mit erheblichen Verzögerungen vorgenommen wer-den (siehe auch G 2.12 Unzureichende Dokumentation der Verkabelung).

- In einer z/OS-Installation wurden jeden Abend automatisch Batch-Jobs zurVerarbeitung von Anwendungsdaten gestartet. Für die Verarbeitung wares wichtig, dass die Batch-Jobs in der richtigen Reihenfolge abliefen. Alseines Abends die Automation versagte, mussten die Jobs manuell gestar-tet werden. Aufgrund fehlender Dokumentation wurden die Batch-Jobs inder falschen Reihenfolge gestartet. Dies führte zu Abbrüchen in der Ver-arbeitung der Anwendungsdaten und zu Verzögerungen in der Produktionum mehrere Stunden.

- Fehlende Datenblätter von (flüchtigen) Halbleiterspeichern wie SRAM(Static Random Access Memory) und DRAM (Dynamic Random Access



Memory) können dazu führen, dass die Speicher nicht ordnungsgemäßgelöscht und damit vertrauliche Informationen bekannt werden können.

- In einem Unternehmen sollten USB-Sticks (nichtflüchtige Speicher) aus-gemustert werden. Die Produktbeschreibungen waren nicht aufzufinden.Die USB-Sticks wurden daher mit dem vorhandenen Löschtool behandelt.Auf herstellerspezifische Besonderheiten konnte jedoch nicht eingegan-gen werden, so dass nicht alle Daten ordnungsgemäß und sicher gelöschtwurden.


IT-Grundschutz-Kataloge: Stand 2005 13

G 2.61 Unberechtigte Sammlungpersonenbezogener Daten

Beim Einsatz von Managementsystemen fallen im Rahmen des normalen Ab-laufes auch viele Protokolldaten an, die in der Regel automatisch erzeugt undausgewertet werden. Dies trifft im besonderen Maße auf die Bereiche derNetz- und Systemüberwachung zu. Ohne ausführliche Protokollierung der Sy-stemaktivitäten ist es z. B. auch nicht möglich, Sicherheitsverletzungen aufzu-decken. Eine Anforderung im Rahmen der Überwachung ist jedoch auch dieeindeutige Zuordnung bestimmter Zugriffe zu Benutzern. Damit müssen dieüberwachten Benutzeraktivitäten aber personenbezogen protokolliert werden.In der Regel wird durch die Managementstrategie organisationsübergreifendund im Einvernehmen mit dem Datenschutzbeauftragten festgelegt, welcheBenutzeraktivitäten aus Sicherheitsgründen überwacht werden sollen. Hier-über sind die betroffenen Benutzer entsprechend zu informieren. Die Einhal-tung der durch die Managementstrategie festgelegten Vorgaben ist jedoch imRahmen der Systemrevision zu überprüfen. Es ist zudem möglich, dass dasManagementsystem im Rahmen einer regulären Funktion temporäre Proto-kolldateien erstellt, die z. B. im wenig geschützten Bereich für temporäre Da-teien abgelegt werden. Die Protokolldateien sind dann potentiell zumindest fürdie Zeit ihrer Existenz zugreifbar und können zudem Benutzerinformationenenthalten.



G 2.67 Ungeeignete Verwaltung vonZugangs- und Zugriffsrechten

Wenn die Vergabe von Zugangs- und Zugriffsrechten schlecht geregelt ist,führt das schnell zu gravierenden Sicherheitslücken, z. B. durch Wildwuchs inder Rechtevergabe.

In vielen Institutionen ist die Verwaltung von Zugangs- und Zugriffsrechteneine extrem arbeitsintensive Aufgabe, weil sie schlecht geregelt ist oder diefalschen Tools dafür eingesetzt werden. Dadurch kann z. B. viel "Handarbeit"erforderlich sein, die gleichzeitig wiederum sehr fehleranfällig ist. Außerdemsind in diesem Prozess dann auch häufig viele unterschiedliche Rollen undPersonengruppen eingebunden, sodass hier auch leicht der Überblick überdurchgeführte Aufgaben verloren geht.

Weiterhin gibt es auch Institutionen, in denen kein Überblick über alle auf denverschiedenen IT-Systemen eingerichteten Benutzer und deren Rechteprofilvorhanden ist. Typischerweise führt das dazu, dass sich Accounts finden vonBenutzern, die die Behörde bzw. das Unternehmen längst verlassen habenoder die durch wechselnde Tätigkeiten zu viele Rechte aufgehäuft haben.

Wenn die Tools zur Verwaltung von Zugangs- und Zugriffsrechten schlechtausgewählt wurden, sind diese oft nicht flexibel genug, um auf Änderungenin der Organisationsstruktur oder auf Wechsel der IT-Systeme angepasst zuwerden.

Die Rollentrennung von Benutzern kann falsch vorgenommen worden sein,so dass Sicherheitslücken entstehen, beispielsweise durch falsche Zuordnungvon Benutzern in Gruppen oder zu großzügige Rechtevergabe. Benutzer kön-nen Rollen zugeordnet werden, die nicht ihren Aufgaben entsprechen (zu vieloder zu wenig Rechte) oder die sie aufgrund ihrer Aufgaben nicht haben dür-fen (Rollenkonflikte).



G 2.87 Verwendung unsichererProtokolle in öffentlichen Netzen

Bei der Kommunikation über öffentliche Netze, insbesondere das Internet, exi-stiert eine Reihe von Gefahren, die aus der Verwendung unsicherer Protokolleentstehen.

Eine wichtige Gefahr ist, dass vertrauliche Informationen in fremde Hände ge-langen können. Als unsichere Protokolle müssen insbesondere solche Proto-kolle gelten, bei denen Informationen im Klartext übertragen werden. Da derWeg der Datenpakete im Internet nicht vorhersagbar ist, können in diesemFall die übertragenen Informationen an verschiedensten Stellen mitgelesenwerden. Besonders kritisch ist dies, wenn es sich um

- Authentisierungsdaten wie Benutzernamen und Passwörter,- Autorisierungsdaten, beispielsweise Transaktionsnummern beim Electro-

nic Banking oder Electronic Brokerage,- andere vertrauliche Informationen, beispielsweise in Dokumenten, die per

E-Mail verschickt werden, handelt.

Protokolle, bei denen sämtliche Informationen im Klartext übertragen werden,sind beispielsweise

- das Hypertext Transfer Protocol HTTP, das bei der Kommunikation zwi-schen Webbrowsern und Webservern verwendet wird,

- das TELNET Protokoll, das noch an einigen Stellen für Remote Loginsverwendet wird,

- das File Transfer Protocol FTP, das noch häufig für den Zugriff auf Serverbenutzt wird, die Dateien zum Download bereitstellen,

- das Simple Mail Transfer Protocol SMTP, das zur Übertragung von E-Mailverwendet wird,

- die Protokolle rsh (Remote Shell), rlogin (Remote Login) und andere ver-wandte Protokolle.

Bei solchen Protokollen können sämtliche übertragenen Informationen auf je-dem Rechner, über den eine entsprechende Verbindung läuft, mitgelesen undgegebenenfalls auch verändert werden. Kritisch ist beispielsweise die Über-tragung von Kreditkartennummern oder Passwörtern über HTTP-Verbindun-gen im Internet.

Mittels Password-Sniffings können in einem ersten Schritt Passwörter bei derÜbertragung zu einem System abgefangen werden. Dies erlaubt dem Angrei-fer anschließend auf dieses IT-System zu gelangen, um dann weitere Angriffelokal auf dem Rechner durchzuführen.

Bei den erwähnten Protokollen (besonders bei HTTP oder TELNET) drohenauch sogenannte Man-in-the-middle-Angriffe oder Session Hijacking (sieheG 5.89 Hijacking von Netz-Verbindungen). Bei dieser Art von Angriffen ist einAngreifer nicht nur dazu in der Lage, Informationen mitzulesen, sondern kanndarüber hinaus aktiv Schaden anrichten, indem laufende Transaktionen verän-dert werden. Beispielsweise können Preise oder Bestellmengen bei Geschäf-ten über das Internet so verändert werden, dass der Besteller nur die Artikeloder Lieferadresse sieht und bestätigt bekommt, die er eingibt, während derAngreifer eine wesentlich höhere Menge und eine andere Lieferadresse anden Verkäufer schickt.

Neben den erwähnten Protokollen, bei denen sämtliche Informationen im Klar-text übertragen werden, existieren auch solche, bei denen zumindest die Über-



tragung der Authentisierungsdaten verschlüsselt erfolgt. Dabei droht jedochimmer noch das Mitlesen der übertragenen Nutzinformation.



G 2.103 Unzureichende Schulung derMitarbeiter

IT-Benutzer aller Art werden häufig zu wenig in der Bedienung der von ih-nen eingesetzten IT-Systeme geschult. Dies trifft leider sogar öfters auf Ad-ministratoren und Benutzerbetreuer zu. Vielfach werden teure Systeme undAnwendungen angeschafft, aber keine oder nur unzureichend Mittel für dieSchulung der IT-Benutzer bereitgestellt.

Dies kann durch unabsichtliche Fehlbedienungen, falsche Konfiguration undungeeignete Betriebsmittel zu gravierenden Sicherheitsproblemen führen.Häufig wenden Benutzer neu eingeführte Sicherheitsprogramme deswegennicht an, weil sie nicht wissen, wie sie bedient werden und eine selbstständigeEinarbeitung oft als zu zeitaufwendig im täglichen Arbeitsablauf gesehen wird.Daher reicht die Beschaffung und Installation einer Sicherheitssoftware nochlange nicht aus.

Beispiele:- Während der Datenerfassung erschien eine dem Benutzer nicht bekannte

Fehlermeldung. Da bei den meisten Fehlermeldungen das Anklicken von"ok" bisher keinen Schaden verursachte, wählte er an diesem Fall auch"ok". Nur diesmal bewirkte dies das Herunterfahren des Systems und folg-lich den Verlust der bis dahin eingegebenen Daten.

- Ein teures Firewall-System wurde beschafft. Der Administrator eines an-deren IT-Systems wurde "durch Handauflegen" zum Administrator die-ses Firewall-Systems bestimmt. Da er als unabkömmlich galt und alleverfügbaren Mittel für die System-Beschaffung verwendet worden waren,wurde er aber weder in der Bedienung der System-Plattform noch fürden eingesetzten Firewall-Typ ausgebildet. Externe Seminare wurden ausGeldmangel verweigert, nicht einmal zusätzliche Handbücher angeschafft.Zwei Monate nach Inbetriebnahme des Firewall-Systems stellte sich her-aus, dass durch eine Fehlkonfiguration der Firewall interne Systeme ausdem Internet frei zugänglich waren.

- In einem Unternehmen wurde die Migration auf ein neues Betriebssystemvorbereitet. Der dafür verantwortliche Mitarbeiter war zwar ein ausgezeich-neter Kenner der bis dahin eingesetzten Plattform, kannte sich aber mitden diskutierten neuen Systemen nicht aus und erhielt auch keine dementsprechende Schulung. Daher besuchte er einige kostenfreie Veranstal-tungen eines Herstellers, dessen Produkte er auch danach favorisierte.Dies führte zu einer kostenintensiven Fehlentscheidung durch Einführungeines ungeeigneten Produktes.

- Für die Internet-Nutzung während der Dienstreisen wurden auf den Note-books der Mitarbeiter Personal Firewalls installiert. Die Mitarbeiter wurdennicht dazu geschult, eine Abstimmung der Einstellungen der Firewall mitden Bedürfnissen der Mitarbeiter fand nicht statt. Viele Mitarbeiter habendaraufhin die Firewall abgeschaltet, um problemlos alle Internet-Seiten zuerreichen, die sie brauchten. Das Ergebnis war, dass schon nach einigenWochen viele der Rechner mit Schadprogrammen verseucht waren. Ne-ben dem Datenverlust war der Ansehensschaden erheblich, da sich einSchadprogramm über Mails an Kunden weitergesendet hatte.



G 2.158 Mängel bei der Entwicklungund der Erweiterung vonWebanwendungen und Web-Services

Wird eine Webanwendung oder ein Web-Service mit fehlenden oder unzurei-chenden Vorgaben und Standards entwickelt beziehungsweise erweitert, sokann dies zu Fehlern, Qualitätseinbußen oder einer unvollständig umgesetz-ten Funktionalität führen. Fehler, die in frühen Entwicklungsphasen der An-wendung gemacht werden, werden häufig erst in einem fortgeschrittenen Ent-wicklungsstadium entdeckt. Um diese Fehler nachträglich zu beheben, müs-sen oft aufwendige Änderungen vorgenommen werden. Dadurch können dieEntwicklungskosten deutlich zunehmen. Im Fall von grundlegenden, architek-tonischen Fehlern ist die Webanwendung oder der Web-Service gegebenen-falls sogar komplett neu zu entwickeln.

Gibt es darüber hinaus keine Vorgaben für die Umsetzung von Sicherheitsme-chanismen, wird der erforderliche Schutzbedarf (zum Beispiel hoher Schutz-bedarf bezüglich Verfügbarkeit) der zu verarbeitenden Daten möglicherweisenicht erfüllt.

Nachfolgend werden Auswirkungen von fehlenden Vorgaben bei der Entwick-lung und Erweiterung von Webanwendungen und Web-Services beispielhaftaufgeführt.

- Aufgrund eines fehlenden Vorgehensmodells bei der Softwareentwicklung(Software Development Lifecycle) werden nicht alle Entwicklungsphasenstrukturiert durchlaufen, sodass Sicherheitsaspekte gar nicht oder erst ineiner späten Entwicklungsphase berücksichtigt werden. In der Folge sinktdie Qualität der Sicherheitsfunktionen, wodurch das angestrebte Sicher-heitsniveau nicht erreicht wird oder die Entwicklungskosten aufgrund not-wendiger Nachbesserungen steigen.

- Fehlende Programmierrichtlinien (Coding Guidelines) führen zu einer un-einheitlichen Struktur und unterschiedlichen Ausprägungen von Program-mierstilen und Sicherheitsmechanismen. Die Einarbeitung in den Pro-grammcode bei der Erweiterung oder Wartung der Webanwendung oderdes Web-Service wird dadurch erschwert. Demzufolge sind nachträglicheÄnderungen und Erweiterungen nur mit hohem Aufwand umzusetzen undmit steigender Komplexität auch fehleranfälliger.

- Durch die falsche Spezifikation von (sicherheitsrelevanten) Testfällen unddie unvollständige Auswahl von Testdaten werden nicht alle denkbarenAnwendungsfälle abgedeckt, sodass Fehler unerkannt bleiben. Wird zumBeispiel die Komponente einer Webanwendung oder eines Web-Servicezur Filterung von Eingabedaten auf Basis unzureichender Testfälle undTestdaten geprüft, so werden unvollständig umgesetzte Filtermechanis-men nicht erkannt.

- Falls funktionale und rechtliche Anforderungen an die Barrierefreiheit nichterfüllt werden, ist die Webanwendung nur eingeschränkt von Menschenmit Behinderung nutzbar.



G 2.159 Unzureichender Schutzpersonenbezogener Daten beiWebanwendungen und Web-Services

Das Benutzerverhalten bei der Bedienung einer Anwendung kann durch dassogenannte User Tracking (üblicherweise ohne explizite Zustimmung des Be-nutzers) aufgezeichnet werden. Da häufig nicht der Betreiber der Webanwen-dung oder der von der Anwendung genutzten Web-Services die Datenauswer-tung durchführt, sondern diese als Dienstleistung integriert, werden die erho-benen Daten in der Regel auf Systemen von Drittanbietern gespeichert. Ausden aufgezeichneten Daten können mittels User Profiling Personenprofile er-stellt werden, die nicht konform mit den Datenschutzbestimmungen sind. Da-mit besteht die Gefahr, gegen gesetzliche Vorschriften zu verstoßen.

Im Folgenden sind Beispiele für die unbefugte Sammlung personenbezogenerDaten aufgeführt:

- Detaillierte Informationen zu Seitenaufrufen und Eingaben bei Webanwen-dungen und Web-Services werden Benutzern zugeordnet (zum Beispielmittels Cookies) und über einen längeren Zeitraum protokolliert. Auf derGrundlage dieser Datensammlung können Personenprofile von den Be-nutzern der Webanwendung oder des Web-Service ohne ihr Wissen er-stellt und zum Beispiel unbefugt für Werbezwecke verwendet werden.

- In den Webseiten der Webanwendung werden Bilder von fremden Serverneingebettet und somit von den Clients der Benutzer geladen. Anhand derangeforderten Bilder können die Betreiber der fremden Server Abrufstati-stiken über die Webseiten der Webanwendung führen. Werden darüberhinaus IP-Adressen auf dem fremden Server protokolliert, können den We-bseiten-Aufrufen IP-Adressen (und somit eventuell Benutzer) zugeordnetwerden. Zusätzlich kann der fremde Server mittels Cookies (engl. ThirdParty Cookies) das Verhalten des Benutzers detailliert nachverfolgen.

- In den HTML-Seiten der Webanwendung ist JavaScript-Code eingebettet,der Anweisungen zur Sammlung von Daten über den Client (zum Beispielinstallierte Plugins, grafische Auflösung) enthält. Bei dem Aufruf der We-bseite werden diese Anweisungen unbemerkt vom Client ausgeführt. Diegesammelten Daten können demnach ohne Kenntnis und Zustimmungdes Benutzers als Identifikationsmerkmale zur Erstellung von Benutzer-profilen verwendet werden.

- Es werden von der Webanwendung oder vom Web-Service personenbe-zogene Daten zwar rechtskräftig erhoben, jedoch nicht angemessen ge-speichert, sodass sie von Dritten unbefugt ausgelesen werden können.

- Ein Web-Service überträgt personenbezogene Daten zur aufrufenden An-wendung oder zu anderen Web-Services mit ungesicherten Klartext-Pro-tokollen über unsichere Netze.



G 2.160 Fehlende oder unzureichendeProtokollierung

Mit Hilfe von Protokolldaten kann beispielsweise festgestellt werden, ob Si-cherheitsvorgaben verletzt oder ob Angriffsversuche unternommen wurden.Zusätzlich lassen sich die Protokollinformationen für eine Fehleranalyse imSchadensfall und zur Ursachenermittlung oder Integritätsprüfung nutzen.

In einem Informationsverbund gibt es häufig IT-Systeme oder Anwendungen,bei denen die Protokollierung in der Grundeinstellung nicht aktiviert wurde.Solche Systeme und Anwendungen müssen zuvor entsprechend konfiguriertwerden. Unter Umständen ist die Protokollierung bei Systemen und Anwen-dungen nicht möglich. Auch ein unzureichendes Planungskonzept kann einGrund für eine fehlende Protokollierung sein.

Selbst wenn die Protokollierung bei einzelnen Systemen genutzt wird, könnenInformationen und daraus resultierende Erkenntnisse verloren gehen, weil sienicht an einer zentralen Stelle zusammengeführt werden. In Informationsver-bünden ohne zentrale Protokollierung ist es schwierig sicherzustellen, dassdie relevanten Protokollinformationen aller IT-Systeme erhalten und ausge-wertet werden.

Ist es den Benutzern der IT-Systeme und Anwendungen möglich, die Proto-kollierung selbstständig zu deaktivieren, kann dies ebenfalls zu Problemenführen. Beispielsweise könnte ein Benutzer gegen Richtlinien verstoßen, ohnedass dies Konsequenzen für ihn hätte. Können die Benutzer vorhandene Pro-tokolldateien verändern oder löschen, besteht die Gefahr, dass Sicherheits-verletzungen nicht erkannt werden.

Beispiel:- Ein nicht autorisierter Benutzer versucht, Passwörter für den Web-Mail-

Account anderer Benutzer zu erraten. Da mit dem Passwort meist auchandere Dienste genutzt werden können (Single-Sign-on), ist dies für denAngreifer besonders interessant. Durch eine fehlende Protokollierung aufdem Mail-Server wird dieser Angriff nicht erkannt. Der Angreifer hat dieMöglichkeit, die Passwörter der Benutzer unbemerkt durch Brute-For-ce-Methoden herauszufinden.



G 2.181 Mangelhafte Planung undKonzeption des Einsatzes vonWeb-Services

Web-Services weisen oft einen hohen Komplexitätsgrad auf. Gerade in Bezugauf die flexible Interaktion verschiedener Web-Services ist es daher erforder-lich, sorgfältig zu planen. Typische Planungsfehler umfassen:

- Standards werden nicht berücksichtigt: Gerade für Web-Services existierteine sehr hohe Anzahl an Standards zu vielfältigen Aspekten. Einige si-cherheitsrelevante Standards werden in der Maßnahme M 4.451 AktuelleWeb-Service Standards vorgestellt. Werden die einschlägigen Standardsnicht berücksichtigt, kann die Interoperabilität mit anderen Web-Serviceserschwert oder verhindert werden.

- Veraltete, noch nicht ausgereifte oder ungeeignete Standards oder Proto-kolle werden ausgewählt: Nicht alle Standards haben sich durchgesetzt.Einige publizierte Standards wurden zwischenzeitlich durch neuere Kon-zepte ergänzt. Veraltete Kommunikationsprotokolle verfügen oft nicht überausreichende Sicherheitseigenschaften.

- Die geforderte Funktionalität wird falsch umgesetzt: Wenn die Anforderun-gen aus dem zu unterstützenden Geschäftsprozess nicht korrekt erfasst,dokumentiert oder verstanden wurden, besteht die Gefahr, dass der Web-Service (oder mehrere Web-Services in ihrem Zusammenwirken) an denAnforderungen "vorbei" entwickelt werden und die eigentlich vorgeseheneAufgabe nicht oder nur unzureichend erfüllen.

- Die Anwendungsarchitektur wird unpassend gewählt: Wenn bei der Ge-staltung der Architektur nicht alle relevanten Anforderungen geeignet be-rücksichtigt werden, kann es sein, dass die Funktionalität, Sicherheit oderVerteilbarkeit der Web-Services nicht oder nur mit erhöhtem Aufwand rea-lisiert werden kann. Weiterhin besteht die Gefahr, dass die zur Realisie-rung der Architektur ausgewählten Komponenten nicht alle erforderlichenFunktionen und Standards unterstützen.

- Verfügbarkeits- und Leistungsanforderungen werden nicht berücksichtigt:Die Architektur und Realisierung der Web-Services muss die vorhande-nen Anforderungen an die Verfügbarkeit und Leistungsfähigkeit geeignetberücksichtigen. Dies gilt auch für die Skalierbarkeit der Dienste und Sy-steme.

- Schnittstellen und XML-Schemata werden ungeeignet ausgestaltet: Daskorrekte Zusammenwirken verschiedener Web-Services setzt voraus,dass die Schnittstellen und Nachrichtenformate sorgfältig geplant werden,insbesondere über Anbietergrenzen hinweg.

- Persistente Daten werden ungeeignet gespeichert: Durch das Konzeptder Zustandslosigkeit müssen auch für Zwischenergebnisse geeigneteLösungen zur Speicherung vorgesehen werden. Die Datenhaltung mussinsgesamt den Anforderungen an Leistungsfähigkeit, Zuverlässigkeit undParallelverarbeitung gerecht werden. Sofern die Web-Services durch ver-schiedene Dienstnehmer unabhängig voneinander genutzt werden, müs-sen auch die Datenbestände entsprechend getrennt werden.

- Sicherheitsfunktionen werden vernachlässigt: Die Entwicklung von Web-Services ist in der Regel fachlich getrieben. Werden in der Entwurfspha-se erforderliche Sicherheitsfunktionen wie Authentisierung, Verschlüsse-lung oder Berechtigungsprüfungen nicht hinreichend berücksichtigt, kanndies dazu führen, dass die realisierten Web-Services dem Schutzbedarf



der verarbeiteten Informationen nicht gerecht werden. Die nachträglicheRealisierung von Sicherheit ist oft umständlich und aufwändig.

- Soweit personenbezogene Daten verarbeitet werden, stellt auch die ex-terne Bereitstellung von Web-Services eine Auftragsdatenverarbeitung imSinne der Datenschutzgesetze dar. Dies erfordert, dass die daraus resul-tierenden gesetzlichen Anforderungen berücksichtigt und die für den Da-tenschutz verantwortlichen Stellen in der Organisation einbezogen wer-den.

- Je nach Einsatzbereich sind neben dem Datenschutz weitere gesetzlicheoder sonstige regulatorische Anforderungen zu beachten. Sind diese Vor-gaben oder ihre Inhalte nicht ausreichend bekannt, oder werden sie beider Konzeption der Web-Services nicht berücksichtigt, so kann später dieEinsetzbarkeit oder Nutzbarkeit der Web-Services gefährdet sein.

- Testmöglichkeiten werden nicht vorgesehen: Um die Weiterentwicklungder Web-Services, aber auch das Update eingesetzter Komponenten so-wie das Einspielen von Patches in einem geeigneten Prozess abbilden zukönnen, muss eine Testmöglichkeit vorhanden sein, die auch im laufen-den Betrieb die Durchführung von Tests ohne Beeinträchtigung der Pro-duktionsumgebung ermöglicht.

Je nach Art und Umfeld der Web-Services können weitere Aspekte für diePlanung relevant sein, eine abschließende Aufzählung ist hier wegen der Ver-schiedenartigkeit der denkbaren Szenarien nicht möglich.

Neben der fehlenden Berücksichtigung der genannten Planungsaspekte be-steht auch die Gefahr, dass entsprechende Überlegungen zwar getätigt, abernicht nachvollziehbar dokumentiert werden. Wechseln später die Verantwort-lichkeiten oder wird der Betrieb erweitert, so können dann wesentliche Infor-mationen oder Entscheidungsgrundlagen fehlen.

Gefährdungskatalog Menschliche Fehlhandlungen G 3.3 Bemerkungen


G 3.3 Nichtbeachtung vonSicherheitsmaßnahmen

Aufgrund von Nachlässigkeit und fehlenden Kontrollen kommt es immer wie-der vor, dass Personen die ihnen empfohlenen oder angeordneten Sicher-heitsmaßnahmen nicht oder nicht im vollen Umfang durchführen. Es könnenSchäden entstehen, die sonst verhindert oder zumindest vermindert wordenwären. Je nach der Funktion der Person und der Bedeutung der missachtetenMaßnahme können sogar gravierende Schäden eintreten. Vielfach werden Si-cherheitsmaßnahmen aus einem mangelnden Sicherheitsbewusstsein herausnicht beachtet. Ein typisches Indiz dafür ist, dass wiederkehrende Fehlermel-dungen nach einer gewissen Gewöhnungszeit ignoriert werden.

- Ein verschlossener Schreibtisch bietet zur Aufbewahrung von Dokumen-ten, DVDs, USB-Sticks oder anderen Informationsträgern keinen hinrei-chenden Schutz gegen unbefugten Zugriff, wenn der Schlüssel im selbernBüro aufbewahrt wird, z. B. auf dem Schrank oder unter der Tastatur.

- Obwohl die schadensmindernde Eigenschaft von Datensicherungen hin-reichend bekannt ist, treten immer wieder Schäden auf, wenn Daten un-vorhergesehen gelöscht werden und aufgrund fehlender Datensicherungdie Wiederherstellung unmöglich ist. Dies zeigen insbesondere die demBSI gemeldeten Schäden, die z. B. aufgrund von Schadsoftware entste-hen.

- Der Zutritt zu einem Rechenzentrum sollte ausschließlich durch die miteinem Zutrittskontrollsystem (z. B. Authentikation über Chipkartenleser,PIN-Eingabe oder biometrische Verfahren) gesicherte Tür erfolgen. DieFluchttür wird jedoch, obwohl sie nur im Notfall geöffnet werden darf, alszusätzlicher Ein- und Ausgang ohne besondere Sicherheitsvorrichtungengenutzt.

- In einem z/OS-System liefen täglich Batch-Jobs für die RACF-Daten-bank-Sicherungen. Die korrekte Ausführung dieser Abläufe sollte täglichvon den zuständigen Administratoren geprüft werden. Da die Sicherungenjedoch über mehrere Monate ohne Probleme durchgeführt wurden, kon-trollierte niemand mehr den Ablauf. Erst nachdem die RACF-Datenban-ken des Produktionssyfstems defekt waren und die Sicherungen zurück-gespielt werden sollten, wurde festgestellt, dass die Batch-Jobs seit meh-reren Tagen nicht mehr gelaufen waren. Dies führte dazu, dass keine aktu-ellen Sicherungen vorhanden waren und die Änderungen der letzten Tagevon Hand nachgetragen werden mussten. Neben einem erheblichen zu-sätzlichen Administrationsaufwand ergab sich dadurch ein Unsicherheits-faktor, da nicht alle Definitionen sicher rekonstruiert werden konnten.

- In einer Institution ist es verboten, fremde USB-Geräte an die IT-Infra-struktur der Institution anzuschließen. Ein Mitarbeiter findet gerade kei-nen dienstlichen USB-Stick und verbindet stattdessen sein Smartphonemit dem PC. Diese mobile IT war jedoch mit einer Schadsoftware infiziert,wodurch es zu einem unberechtigten Datenabfluss kam.


IT-Grundschutz-Kataloge: Stand Juli 1999 24

G 3.16 Fehlerhafte Administration vonZugangs- und Zugriffsrechten

Zugangsrechte zu einem IT-System und Zugriffsrechte auf gespeicherte Da-ten und IT-Anwendungen dürfen nur in dem Umfang eingeräumt werden, wiesie für die Wahrnehmung der Aufgaben erforderlich sind. Werden diese Rech-te fehlerhaft administriert, so kommt es zu Betriebsstörungen, falls erforderli-che Rechte nicht zugewiesen wurden, bzw. zu Sicherheitslücken, falls überdie notwendigen Rechte hinaus weitere vergeben werden.

Beispiel:

Durch eine fehlerhafte Administration der Zugriffsrechte hat ein Sachbearbei-ter die Möglichkeit, auf die Protokolldaten zuzugreifen. Durch gezieltes Lö-schen einzelner Einträge ist es ihm daher möglich, seine Manipulationsversu-che am Rechner zu verschleiern, da sie in der Protokolldatei nicht mehr er-scheinen.



G 3.38 Konfigurations- undBedienungsfehler

Konfigurationsfehler entstehen durch eine falsche oder nicht vollständige Ein-stellung von Parametern und Optionen, mit denen ein Programm gestartetwird. In diese Gruppe fallen unter anderem falsch gesetzte Zugriffsrechte fürDateien. Bei Bedienungsfehlern sind nicht einzelne Einstellungen falsch, son-dern die IT-Systeme oder IT-Anwendungen werden falsch behandelt. Ein Bei-spiel hierfür ist das Starten von Programmen, die für den Einsatzzweck desRechners nicht notwendig sind, aber von einem Angreifer missbraucht werdenkönnen.

Beispiele für aktuelle Konfigurations- bzw. Bedienungsfehler sind das Spei-chern von Passwörtern auf einem PC, auf dem ungeprüfte Software aus demInternet ausgeführt wird, oder das Laden und Ausführen von schadhaften Acti-veX-Controls. Diese Programme, die unter anderem, die Aufgabe haben, We-bseiten durch dynamische Inhalte attraktiver zu machen, werden mit den glei-chen Rechten ausgeführt, die auch der Benutzer hat. Sie können beliebig Da-ten löschen, verändern oder versenden.

Viele Programme, die für die ungehinderte Weitergabe von Informationen in ei-nem offenen Umfeld gedacht waren, können bei falscher Konfiguration poten-ziellen Angreifern Daten zu Missbrauchszwecken liefern. So kann beispiels-weise der finger-Dienst darüber informieren, wie lange ein Benutzer bereitsam Rechner sitzt. Aber auch Browser übermitteln bei jeder Abfrage einer Da-tei eine Reihe von Informationen an den Webserver (z. B. die Version desBrowsers und des verwendeten Betriebssystems, den Namen und die Inter-net-Adresse des PCs). In diesem Zusammenhang sind auch die Cookies zunennen. Hierbei handelt es sich um Dateien, in denen Webserver-BetreiberDaten über den Benutzer auf dessen Rechner speichern. Diese Daten könnenbeim nächsten Besuch des Servers abgerufen und vom Server-Betreiber füreine Analyse, der vom Benutzer vorher auf dem Server besuchten Webseiten,verwendet werden.

Der Einsatz eines Domain Name Systems stellt eine weitere Gefahrenquelledar. Zum einen ermöglicht ein falsch konfigurierter DNS-Server die Abfragevon vielen Informationen über ein lokales Netz. Zum anderen hat ein Angreiferdurch die Übernahme dieses Servers die Möglichkeit, gefälschte IP-Adressenzu verschicken, sodass jeglicher Verkehr von ihm kontrolliert werden kann.

Eine große Bedrohung geht auch von den automatisch ausführbaren Inhalten(Executable Content) in E-Mails oder HTML-Seiten aus. Dies ist unter demStichwort Content-Security-Problem bekannt. Dateien, die aus dem Internetgeholt werden, können Code enthalten, der bereits beim "Betrachten" und oh-ne Rückfrage beim Benutzer ausgeführt wird. Dies ist z. B. bei Makros in Of-fice-Dateien der Fall und wurde zum Erstellen von sogenannten Makro-Virenausgenutzt. Auch Programmiersprachen und -schnittstellen wie ActiveX, Ja-vascript oder Java, die für Anwendungen im Internet entwickelt worden sind,besitzen bei falscher Implementierung der Kontrollfunktionen ein Schadpoten-zial.

Die Verfügbarkeit des Sicherheitssystems RACF ist bei z/OS-Betriebssyste-men von zentraler Bedeutung für die Verfügbarkeit des gesamten Systems.Durch unsachgemäßen Einsatz von z/OS-Utilities bei der RACF-Datenbank-sicherung oder fehlerhafte Bedienung der RACF-Kommandos kann diese ein-geschränkt werden.



G 3.119 Fehlerhafte Anwendung vonStandards

Für die Realisierung von Web-Services sind zahlreiche Standards verfügbar(siehe M 4.451 Aktuelle Web-Service Standards), die insbesondere in ihremZusammenwirken und ihren Abhängigkeiten untereinander eine hohe Kom-plexität erreichen.

Als Konsequenz dieser Komplexität sind Fehler in der Anwendung der Stan-dards naheliegend. Solche Fehler können vielfältige Konsequenzen haben:

- Der Standard wird nicht wirksam umgesetzt. Insbesondere kann dies dazuführen, dass vorgesehene Sicherheitsfunktionen nicht wirksam realisiertwerden, indem zum Beispiel Berechtigungsprüfungen nicht durchgeführtwerden oder eine Verschlüsselung nicht erfolgt.Beispiel: In einem sicherheitsrelevanten SOAP-Header wurde ein Tippfeh-ler gemacht, gleichzeitig fehlt das Attribut env:mustUnderstand=true. DerSOAP-Knoten kann den Header aufgrund des Tippfehlers nicht interpre-tieren und ignoriert ihn.

- Die Anwendung des Standards erfolgt nicht in der vorgesehenen Art bezie-hungsweise nicht im vorgesehenen Umfang. So ist es denkbar, dass zumBeispiel XML-Signaturen nicht alle relevanten Bestandteile einer Nach-richt umfassen, oder dass nicht mit ausreichend sicheren Algorithmen ver-schlüsselt wird.Beispiel: Eine XML-Signatur wird über ein XML-Element erzeugt, das inder verwendeten XML-Struktur mehrfach vorkommen kann, sodass einAngreifer mit XML Signature Wrapping die Inhalte der Nachricht seman-tisch verändern kann, ohne dass die Signatur ihre Gültigkeit verliert.

- Die Implementierung erzeugt Fehler im Betrieb, die unter Umständen nurin besonderen Situationen auftreten und die Verfügbarkeit des Web-Ser-vice einschränken.Beispiel: Berechtigungsprüfungen werden mit einem Fehler abgebrochen,wenn der aufrufende Benutzer einer bestimmten Kombination aus Rolleund Organisationseinheit zuzuordnen ist.

- Die Implementierung umfasst zusätzliche, vom jeweiligen Standard um-fasste Funktionen, die für den konkreten Web-Service nicht erforderlichsind. Solche ungenutzten Funktionen bieten dem Angreifer eine höhereAngriffsfläche und können insbesondere für Angriffe auf die Verfügbarkeitdes Web-Service missbraucht werden.Beispiel: Beim Parsen einer Nachricht werden externe XML-Referenzenaufgelöst, obwohl dies für den betroffenen Web-Service nicht erforderlichist.

Aus Implementierungsfehlern kann sich einerseits eine unbeabsichtigte Be-einträchtigung der Verfügbarkeit, Offenlegung oder Verfälschung von Informa-tionen oder Metadaten ergeben, indem die implementierten Dienste nicht oderfalsch funktionieren. Andererseits können Angreifer solche Implementierungs-fehler auch gezielt ausforschen (siehe G 5.184 Informationsgewinnung überWeb-Services) und ausnutzen, um die Verfügbarkeit, Vertraulichkeit oder In-tegrität des Web-Service anzugreifen.

Wegen der hohen Abhängigkeiten der relevanten Standards untereinanderbesteht zudem die Gefahr, dass Fehler in der Anwendung eines Standardsihre Auswirkungen erst im Kontext davon unmittelbar oder mittelbar abhängi-ger Standards und Komponenten zeigen, sodass der Fehler nur mit hohemAufwand eingegrenzt und behoben werden kann.



G 3.120 Fehler bei der Orchestrierung

Wenn verschiedene Web-Services zusammengefügt werden, um übergreifen-de Aufgaben zu realisieren, so spricht man von Orchestrierung. Die Orche-strierung kann statisch erfolgen, indem auf der Grundlage von WSDL undUDDI geeignete Dienste ausgewählt und zusammengefügt werden. In Ser-vice-orientierten Architekturen kann eine Orchestrierung aber auch dynamischerfolgen, das heißt, für die zu erledigenden Aufgaben werden erst zur Laufzeitgeeignete Dienste identifiziert und ausgewählt. In der Praxis ist die dynami-sche Orchestrierung wenig verbreitet.

Die Orchestrierung oder, im Falle einer dynamischen Orchestrierung, ihre Im-plementierung erfordern besondere Sorgfalt, um Fehler unterschiedlichster Artzu vermeiden:

- Fachaufgaben werden fehlerhaft abgebildet oder Dienste werden fehler-haft zusammengestellt: Aus dem Zusammenwirken der einzelnen Dienstekann sich eine hohe Komplexität ergeben, die hohe Anforderungen an diePlanung der Orchestrierung stellt. Fehlendes Verständnis der zu realisie-renden Fachaufgabe, aber auch der Funktionalität und Interaktion der be-teiligten Services kann dazu führen, dass die Orchestrierung nicht korrekterfolgt und die resultierende Funktionalität nicht den Anforderungen ent-spricht.

- Dienste oder Schnittstellen werden fehlerhaft beschrieben oder implemen-tiert: Wenn die Beschreibung eines Dienstes und seine Implementierungvoneinander abweichen, kann daraus resultieren, dass ein ausgewählterDienst die ihm zugedachte Aufgabe nicht oder nur unzureichend erfüllt.Dies kann einerseits die Abbildung der fachlichen Funktionalität beein-trächtigen, aber auch unmittelbare Auswirkungen auf die Sicherheit ha-ben, wenn der ausgewählte Dienst eine Sicherheitsfunktion erfüllen sollte(zum Beispiel Autorisierung).

- Eine Transaktionssicherheit fehlt, oder parallele Prozesse haben unge-wollte Auswirkungen: Web-Services werden typischerweise von mehre-ren Anwendungen oder Prozessen gleichzeitig benutzt. Dieser Umstandmuss bei der Orchestrierung berücksichtigt werden. Insbesondere dürfendie beteiligten Web-Services keine Annahmen über den Zustand von Da-ten oder Systemen zwischen zwei Aufrufen oder vor und nach dem Aufrufeines weiteren Services machen.

- Der Schutzbedarf wird nicht ausreichend berücksichtigt: Wenn Dienste imRahmen der Orchestrierung zusammengestellt werden, ist neben funktio-nalen Aspekten auch das vom jeweiligen Dienst realisierte Sicherheitsni-veau zu berücksichtigen (zum Beispiel Qualität der Authentisierung, Ver-schlüsselung, aber auch Verfügbarkeiten). Andernfalls besteht die Ge-fahr, dass Dienste in eine Fachaufgabe eingebunden werden, die demSchutzbedarf dieser Aufgabe nicht gerecht werden. Dieser Aspekt gewinntbesondere Bedeutung, wenn die Orchestrierung Dienste verschiedenerDiensteanbieter umfasst.

Gerade in komplexen Szenarien mit vielen zusammenwirkenden Dienstenoder mit dynamischer Orchestrierung bestehen oft nur eingeschränkte Mög-lichkeiten, Dienste in ihrem Zusammenspiel zu testen, sodass die oben be-schriebenen Fehler gegebenenfalls erst im laufenden Betrieb erkannt werden.



G 3.121 Konfigurations- undAdministrationsfehler bei Web-Services

Beim Einsatz von Web-Services können Konfigurations- und Administrations-fehler nicht nur bei den zugrunde liegenden Plattformen (Betriebssysteme,Web- und Applikationsserver, Datenbanken) auftreten, sondern auch in Ver-bindung mit den Web-Services selbst oder den dazugehörigen Komponenten,zum Beispiel einem Enterprise Service Bus oder einem Security Token Ser-vice.

Je nach Art des Dienstes beziehungsweise der Komponenten können Kon-figurationseinstellungen und Parameter in unterschiedlichster Form gepflegtwerden, von (gegebenenfalls XML-basierten) Konfigurationsdateien über Da-tenbankinhalte bis hin zu eigenen Administrationswerkzeugen und -oberflä-chen. Entsprechend unterschiedlich stark ausgeprägt ist die Gefahr von Feh-lern: Wenn XML-Dateien manuell bearbeitet werden, ist die Fehlergefahr si-cherlich gegenüber einer Administrationsoberfläche mit Plausibilitätsprüfun-gen und Sicherheitsabfragen deutlich erhöht.

Administrationsfehler werden weiter begünstigt, wenn die Dokumentation derKonfigurationsmöglichkeiten, ihrer Auswirkungen und der gewählten Einstel-lungen fehlt, veraltet oder unvollständig ist, und wenn das administrative Per-sonal nicht ausreichend geschult oder eingewiesen wurde.

Die Konsequenzen solcher Konfigurations- und Administrationsfehler könnenganz unterschiedlich ausfallen:

- Web-Services funktionieren nicht oder erfüllen nicht die ihnen zugedachteAufgabe. Besonders problematisch sind hier Fehler, die sich auf den Web-Service erst verzögert oder nur unter bestimmten Randbedingungen aus-wirken, sodass eine Zuordnung des Problems zur Ursache erschwert wird.

- Benutzer oder Berechtigungen werden falsch administriert. Dadurch kön-nen entweder berechtigte Benutzer die ihnen zugedachten Dienste nichtnutzen (Beeinträchtigung der Verfügbarkeit), oder unberechtigte Benutzerhaben Zugriff auf Dienste oder Informationen, die nicht für sie bestimmtsind (Beeinträchtigung der Vertraulichkeit, bei Schreibzugriff auch der In-tegrität).

- Vorgesehene Sicherheitsmechanismen werden versehentlich deaktiviert,funktionieren falsch oder verfügen nicht über eine angemessene Stärke(zum Beispiel wenn kryptographische Algorithmen und Parameter falschgewählt werden).

- Die Kommunikation zwischen verschiedenen Diensten oder der Aus-tausch von Nachrichten, gegebenenfalls über einen Enterprise ServiceBus, werden gestört, verzögert oder unterbunden.

- Die Orchestrierung verschiedener Web-Services wird beeinträchtigt, weilDienste- oder Schnittstellenbeschreibungen falsch sind oder Reposito-ries nicht richtig konfiguriert sind. Insbesondere bei einer dynamischenOrchestrierung können die Folgen erheblich sein (siehe hierzu auchG 3.120 Fehler bei der Orchestrierung).

- Die Nachvollziehbarkeit der Informationsverarbeitung und die Erkennbar-keit oder Aufklärungsmöglichkeiten von Angriffen werden beeinträchtigt,wenn Fehler in der Konfiguration von Protokollierungsmechanismen oder-komponenten gemacht werden, indem zum Beispiel Protokollierungs-



funktionen ausgeschaltet oder Protokollierungsinhalte ungeeignet defi-niert werden.

- Die Angriffsfläche kann sich unnötig erhöhen, wenn in produktiven Umge-bungen Funktionen für die Fehlersuche (Debugging) und die Softwareent-wicklung oder andere ungenutzte Funktionen aktiv bleiben.

- Durch die unnötige Preisgabe von Informationen können Angriffe ermög-licht oder erleichtert werden (siehe hierzu auch G 5.184 Informationsge-winnung über Web-Services).

In verteilten Umgebungen, bei denen die beteiligten Web-Services von ver-schiedenen Anbietern betrieben werden, erhöht sich die Fehlergefahr durchdie mangelhafte Abstimmung oder Kommunikation der beteiligten Anbieter un-tereinander.

Gefährdungskatalog Technisches Versagen G 4.13 Bemerkungen


G 4.13 Verlust gespeicherter Daten

Der Verlust gespeicherter Daten kann erhebliche Auswirkungen auf den IT-Einsatz haben. Sind die Anwendungsdaten oder die Kundenstammdaten ver-loren oder verfälscht, so können privatwirtschaftliche Betriebe in ihrer Existenzbedroht sein. Der Verlust oder die Verfälschung wichtiger Dateien kann in Be-hörden Verwaltungs- und Fachaufgaben verzögern oder sogar ausschließen.

Der Verlust gespeicherter Daten kann erhebliche Auswirkungen auf Ge-schäftsprozesse und damit auf die gesamte Institution haben. Wenn ge-schäftsrelevante Informationen, egal welcher Art, zerstört oder verfälscht wer-den, können dadurch Geschäftsprozesse und Fachaufgaben verzögert odersogar deren Ausführung verhindert werden. Insgesamt kann der Verlust ge-speicherter Daten, neben dem Produktionsausfall und den Kosten für die Wie-derbeschaffung der Daten, vor allem zu langfristigen Konsequenzen, wie Ver-trauenseinbußen bei Kunden und Partnern sowie einem negativen Eindruck inder Öffentlichkeit, führen. Von den durch Datenverluste verursachten direktenund indirekten Schäden können Institutionen sogar in ihrer Existenz bedrohtsein.

Dabei können die Gründe für den Verlust gespeicherter Daten vielfältiger Artsein:

- Entmagnetisierung von magnetischen Datenträgern durch Alterung oderdurch ungeeignete Umfeldbedingungen (Temperatur, Luftfeuchte),

- Störung magnetischer Datenträger durch äußere Magnetfelder,- Zerstörung von Datenträgern durch höhere Gewalt wie Feuer oder Was-

ser,- versehentliches Löschen oder Überschreiben von Dateien,- vorsätzliches oder versehentliches Setzen von Löschmarkierungen in Ar-

chivsystemen (siehe auch G 5.106 Unberechtigtes Überschreiben oderLöschen von Archivmedien),

- technisches Versagen von Peripheriespeichern (Headcrash),- fehlerhafte Datenträger,- unkontrollierte Veränderungen gespeicherter Daten (Integritätsverlust)

und- Datenzerstörung durch Schadprogramme.



G 4.22 Software-Schwachstellen oder -Fehler

Für jede Art von Software gilt: je komplexer sie ist, desto häufiger treten Pro-grammier- oder Designfehler auf. Unter Software-Schwachstellen sollen un-beabsichtigte Programmfehler verstanden werden, die dem Anwender nichtoder noch nicht bekannt sind und ein Sicherheitsrisiko für das IT-System dar-stellen. Es werden ständig neue Sicherheitslücken in vorhandener, auch inweitverbreiteter oder ganz neuer Software gefunden.

Zu Fehlern oder Schwachstellen in Software kann es durch eine Vielzahl vonGründen kommen. Dazu gehören beispielsweise Kommunikationsfehler zwi-schen Kunden und Entwicklern, unzureichende Ausbildung der Programmie-rer oder ungenügende Tests. Auch zu hohe Erwartungen der Anwender undzeitlich zu knapp bemessene Fertigstellungstermine können dazu führen, dassdie Hersteller ihre Produkte teilweise unausgereift oder nicht fehlerfrei anbie-ten.

Werden Softwarefehler nicht erkannt, können die bei der Anwendung entste-henden Fehler zu weitreichenden Folgen führen. Bei weitverbreiteter Stan-dardsoftware können Software-Schwachstellen schnell dazu führen, dassweltweit schwerwiegende Sicherheitsprobleme für alle Arten von Institutionenentstehen können.

Beispiele:- Ein Software-Fehler in der Sicherheitssoftware RACF des z/OS-Betriebs-

systems kann bedeuten, dass nicht nur RACF den Dienst einstellt, son-dern dadurch das ganze System nicht mehr funktionsfähig ist und neu ge-startet werden muss.

- Die Stärke der in Standardsoftware implementierten Sicherheitsfunktiona-litäten (wie Passwörter oder Verschlüsselungsalgorithmen) wird vom An-wender häufig zu hoch eingeschätzt. Häufig können diese Sicherheits-funktionalitäten einem sachkundigen Angriff nicht dauerhaft standhalten.Dies gilt z. B. für die Verschlüsselungsfunktionen, die in vielen Textverar-beitungsprogrammen integriert sind. Für fast alle davon gibt es im Internetzahlreiche Tools, um diese Verschlüsselung zu überwinden.

- Nachweislich führte das Auftreten eines bestimmten Wortes in der Recht-schreibprüfung eines Textverarbeitungsprogrammes immer zu dessenAbsturz.

- Vielfach enthält Standardsoftware nicht dokumentierte Funktionen, wiesog. "Ostereier" oder "Gagscreens", mit denen sich die Entwickler desProduktes verewigt haben. Zum einen werden hierdurch zusätzliche IT-Ressourcen verbraucht, zum anderen wird dadurch auch deutlich, dass imSoftwaretest die gesamte Funktionalität des Produktes nicht bis ins Letztegeklärt werden kann.

- Die meisten Warnmeldungen der Computer Emergency Response Teamsin den letzten Jahren bezogen sich auf sicherheitsrelevante Programmier-fehler. Dies sind Fehler, die bei der Erstellung von Software entstehenund dazu führen, dass diese Software von Angreifern missbraucht werdenkann. Der größte Teil dieser Fehler wurde durch Speicherüberläufe (Buf-fer Overflow) hervorgerufen. Hierbei handelt es um Fehler, bei denen eineRoutine zum Einlesen von Zeichen nicht prüft, ob die Länge der eingege-benen Zeichenkette mit der Länge des dafür vorgesehenen Speicherbe-reiches übereinstimmt. Dadurch ist es Angreifern möglich, eine überlangeZeichenfolge zu übertragen, so dass hinter dem für die Eingabe reservier-ten Speicherbereich zusätzliche Befehle gespeichert werden können, die



zur Ausführung gebracht werden. Diese Befehle können zum Beispiel be-liebige Programme sein.

- Eine weitere große Anzahl von Warnmeldungen wurde durch Verfügbar-keitsangriffe (Denial of Service, DoS ) verursacht, bei denen durch Fehlerin einzelnen Routinen, die für die Netzdatenverarbeitung eingesetzt wer-den, der gesamte Rechner zum Absturz gebracht werden kann.

- Die unzureichende Absicherung der Registrierung zur Nutzung einesCloud Services führt dazu, dass ein Benutzer den Service in der Fol-ge unter einem falschen Namen missbrauchen kann. Der Benutzer regi-striert sich dabei beim Cloud Service im Namen eines anderen Cloud-Service-Benutzers. Bei der Registrierung wird auf eine ausreichende Ab-sicherung, beispielsweise mithilfe eines Aktivierungs-Links unter der an-gegebenen E-Mail-Adresse, verzichtet.



G 4.33 Schlechte oder fehlendeAuthentikation

Authentikationsmechanismen können zur Authentikation von Benutzern oderKomponenten oder zur Bestimmung des Datenursprungs eingesetzt werden.Wenn Authentikationsmechanismen fehlen oder zu schlecht sind, besteht dieGefahr, dass

- Unbefugte auf IT-Systeme oder Daten Zugriff nehmen können,- die Verursacher von Problemen nicht identifiziert werden können oderdie Herkunft von Daten nicht bestimmt werden kann.

Weiter besteht die Gefahr, dass Sicherheitslücken entstehen

- bei der Benutzerauthentikation, wenn z. B. Benutzer Passwörter wählen,die einfach zu erraten sind, oder wenn sie die Passwörter nie wechseln,

- bei der Komponentenauthentikation, wenn z. B. nach Inbetriebnahme ei-nes IT-Systems Default-Passwörter nicht durch individuell gewählte er-setzt werden, wenn die Passwörter, die bei vielen IT-Systemen fest ein-gegeben werden, nie wieder geändert werden oder wenn die Passwörternicht sicher hinterlegt werden und sich nach einem Systemabsturz her-ausstellt, dass das jetzt dringend benötigte Passwort vergessen wurde,

- bei der Wahl der Verfahren, wenn diese z. B. völlig untauglich sind oderSicherheitslücken bekannt werden, auf die im laufenden Betrieb aber nichtreagiert wird.



G 4.35 Unsichere kryptographischeAlgorithmen

Der Sicherheitszugewinn durch Einsatz kryptographischer Verfahren istgrundsätzlich von zwei Parametern abhängig: es müssen sichere kryptogra-phische Algorithmen eingesetzt werden und die geheimen Schlüssel müs-sen vertraulich gehandhabt werden (zur Kompromittierung kryptographischerSchlüssel siehe G 5.83 Kompromittierung kryptographischer Schlüssel).

Unsichere kryptographische Algorithmen sind dadurch gekennzeichnet, dasses einem potentiellen Angreifer mit vertretbaren Ressourcen gelingt, das ein-gesetzte kryptographische Verfahren zu brechen. Bei Verschlüsselungsalgo-rithmen bedeutet dies, dass es gelingt, aus dem verschlüsselten Text den ur-sprünglichen Klartext zu ermitteln, ohne dass zusätzliche Informationen be-kannt sind. Dabei sind als relevante Ressourcen auf Angreiferseite z. B. dieverfügbare Rechenleistung, Hilfsmittel wie Analysetools, vorhandene Kennt-nisse, verfügbare Arbeitszeit, Kenntnisse über Schwachstellen etc. zu berück-sichtigen. Werden also unsichere kryptographische Algorithmen eingesetzt,besteht für Angreifer die Möglichkeit, den kryptographischen Schutz zu unter-laufen.

Ob jedoch ein kryptographischer Algorithmus unsicher ist, muss jeweils imEinzelfall untersucht werden. Es gibt jedoch einige Kriterien, die auf Unsicher-heiten schließen lassen:

- Werden bei symmetrischen Verschlüsselungsverfahren geheime Schlüs-sel benutzt, deren effektive Länge geringer als 100 Bit ist, so können sieheute mit moderatem Rechnereinsatz durch Ausprobieren aller potentiellmöglichen Schlüssel gebrochen werden. Mit steigender Rechnerleistungist anzunehmen, dass diese Grenze in Zukunft über 100 Bit steigen wird.

- Werden bei asymmetrischen Verschlüsselungs- und Signaturverfahren Al-gorithmen eingesetzt, deren Sicherheit auf dem Problem des Faktorisie-rens großer Zahlen basiert, so wird heute angenommen, dass Schlüssel-längen von weniger als 2000 Bit als unsicher zu betrachten sind. Dies be-gründet sich in den Fortschritten bei der Entwicklung effizienter Faktorisie-rungsalgorithmen, die heute unter massivem Rechnereinsatz Faktorisie-rungen von Zahlen mit rund 500 Bit erlauben. Daneben ist die möglicheEntwicklung von opto-elektronischen Beschleunigern für einen wesentli-chen Teil-Rechenschritt bei diesen Verfahren in Betracht zu ziehen, wasdiese deutlich beschleunigen würde.

- Hashfunktionen, die eine beliebig lange Zeichenkette auf einen Hashwertmit konstanter Bitlänge abbilden, können als unsicher betrachtet werden,wenn die konstante Länge des Hashwertes geringer ist als 128 Bit, dasonst zwei Zeichenketten ermittelt werden können, die den gleichen Has-hwert ergeben.

- Kryptographische Algorithmen, die von unerfahrenen Entwicklern entwor-fen wurden und nicht in der wissenschaftlichen Szene untersucht wurden,sollten als potentiell unsicher betrachtet werden, da die Entwicklung siche-rer kryptographischer Algorithmen langjährige Erfahrung voraussetzt.

- Nicht veröffentlichte kryptographische Algorithmen, die auffällig schnell inSoftware ablaufen, sollten ebenfalls als potentiell unsicher betrachtet wer-den. Die Erfahrung zeigt, dass sichere Algorithmen meist auf komplexenmathematischen Funktionen beruhen müssen.

- Bei der Anwendung kryptographischer Verfahren werden häufig Zufalls-zahlen benötigt. Schlechte Zufallszahlengeneratoren können dazu führen,dass die damit erzeugten Werte vorhersagbar sind. Dadurch können z. B.



kryptographische Checksummen, die die Nachrichtenintegrität sicherstel-len sollen, wertlos werden.

Von diesen Kriterien betroffen ist beispielsweise der weltweit sehr häufig ein-gesetzte DES-Algorithmus zur symmetrischen Verschlüsselung. Dieser be-nutzt eine effektive Schlüssellänge von 56 Bit. Der so genannte Triple-DES-Algorithmus als dreifache Hintereinanderausführung mit zwei Schlüsseln hateine effektive Schlüssellänge von 112 Bit und kann zurzeit noch als ausrei-chend sicher betrachtet werden. Auch betroffen ist der RSA-Algorithmus, derals asymmetrisches Verfahren auf dem Faktorisierungsproblem basiert. WirdRSAmit einer Schlüssellänge unter 1024 Bit betrieben, muss davon ausge-gangen werden, dass dies keine ausreichende Sicherheit bietet. Für die näch-sten Jahre kann eine Schlüssellänge von mindestens 2000 Bit noch als aus-reichend sicher angesehen werden.

Der Hash-Algorithmus MD5 ist veraltet und weist bekannte Schwächen auf,die auch bereits anhand praktischer Beispiele demonstriert werden konnten.Auch der Hash-Algorithmus SHA-1 ist nicht mehr für alle Einsatzzwecke ge-eignet.

Ein häufiges Beispiel unsicherer, aber sehr schneller Algorithmen ist die so ge-nannte XOR-Funktion, bei der konstante Werte mit dem ursprünglichen Klar-text auf einfache Weise verknüpft werden. Dies ist ein hochperformanter Algo-rithmus, der jedoch sehr schnell gebrochen werden kann. Die XOR-Funktionkann andererseits aber der sicherste Verschlüsselungsalgorithmus überhauptsein, wenn die zu verschlüsselnden Daten mit nicht vorhersagbaren Zufalls-werten XOR-iert werden (One-Time-Pad).

Für den Laien ist es praktisch unmöglich, festzustellen, ob ein kryptographi-scher Algorithmus ausreichend sicher ist. Daher sollten nur solche Algorith-men eingesetzt werden, die bekanntermaßen von Experten entwickelt wurdenoder die einer langjährigen Untersuchung durch die wissenschaftliche Szeneunterzogen wurden.



G 4.84 Unzureichende Validierungvon Ein- und Ausgabedaten beiWebanwendungen und Web-Services

Webanwendungen werden im Allgemeinen von generischen Clients (Web-Browsern) verwendet, sodass Benutzer beliebige Eingabedaten an den Serverübermitteln können. Auf Web-Services wird dagegen durch andere Anwen-dungen oder Dienste zugegriffen (beispielsweise Smartphone-Apps). Einga-bedaten können aber auch hier oft modifiziert werden, beispielsweise durchden Einsatz eines Proxys oder durch Manipulation der Clients. Werden schad-hafte Eingaben eines Angreifers von der Webanwendung beziehungsweisedem Web-Service verarbeitet, können möglicherweise Schutzmechanismenumgangen werden.

Beispiele für Angriffe, die auf einer unzureichenden Validierung von Eingabe-daten beruhen, sind SQL-Injection (siehe G 5.131 SQL-Injection), Path Tra-versal (siehe G 5.172 Umgehung der Autorisierung bei Webanwendungen undWeb-Services) und Remote File Inclusion. Diese Angriffe können UnbefugtenZugriff auf das Betriebssystem oder auf Hintergrundsysteme ermöglichen. Beieinem erfolgreichen Angriff können schützenswerte Daten unautorisiert aus-gelesen oder manipuliert werden.

Nachdem die Webanwendung beziehungsweise der Web-Service die Einga-bedaten erfolgreich verarbeitet hat, werden üblicherweise wieder Daten aus-gegeben. Die Ausgabedaten werden entweder direkt an den Browser des Be-nutzers (zum Beispiel Statusmeldungen oder ein neuer Eintrag im Gästebuch)oder die aufrufende Anwendung übermittelt oder an nachgelagerte Systemeweitergereicht. Werden die Daten vor der Ausgabe nicht ausreichend validiert,könnten die Ausgaben Schadcode enthalten, der auf den Zielsystemen inter-pretiert oder ausgeführt wird.

Die folgenden Beispiele beschreiben mögliche Auswirkungen einer unzurei-chenden Validierung von Ein- und Ausgaben:

- Eine Webanwendung beziehungsweise ein Web-Service verwendet Ein-gabedaten ungefiltert zur Erzeugung von Datenbankabfragen. Dies kannein Angreifer ausnutzen und eine Anfrage formulieren, die neben den regu-lären Eingabedaten zusätzliche Befehle für die Datenbank enthält. Durchdas ungefilterte Einbetten der Eingabedaten in die Datenbankabfrage wer-den die Befehle von der Datenbank ausgeführt. So kann der Angreifer di-rekten Zugriff auf die Datenbank erhalten.

- Eine Webanwendung bietet eine Funktion zum Datei-Upload an undschränkt diese auf gewisse Dateitypen ein. Zur Bestimmung des Dateitypsüberprüft die Webanwendung ausschließlich die Dateiendung und berück-sichtigt dabei nicht den Inhalt der Datei. Wird eine erlaubte Dateiendungfür den Upload verwendet, können so Dateien mit beliebigem Inhalt zumServer übermittelt werden.

- Werden Eingabedaten durch die Filterkomponente automatisiert geändertund angepasst (Sanitizing), können die Daten durch gezielte Eingaben ei-nes Angreifers von der Filterkomponente in einen Angriffsvektor überführtwerden.

- Ein- und Ausgabedaten können in verschiedenen Kodierungen (zum Bei-spiel UTF-8, ISO 8859-1) und Notationen (zum Beispiel bei UTF-8 ist "." ="2E" = "C0 AE") vorliegen. Abhängig vom angewandten Kodierungssche-



ma kann der gleiche Wert unterschiedlich interpretiert werden. Interpre-tiert die Filterkomponente die Daten anders als die verarbeitenden Kom-ponenten der Webanwendung oder des Web-Service, so kann ein Angrei-fer schadhafte Daten (zum Beispiel SQL-Anweisungen) derart codieren,dass sie bei der Filterung nicht erkannt werden. Somit werden die vomAngreifer schadhaften Daten an die verarbeitenden Komponenten weiter-gereicht und aufgrund der unterschiedlichen Interpretation ausgeführt.

- Die Kommentar-Funktion einer Webanwendung erlaubt eine Formatie-rung der Texte durch HTML. Die Eingaben werden zum Beispiel nichtauf spezielle HTML-Tags eingeschränkt, sodass ein Angreifer über dieseFunktion beliebigen HTML-Code auf der Webanwendung platzieren kann.Dies kann ein Angreifer dazu nutzen, um Elemente der Webseite zu ma-nipulieren oder zu überlagern und Benutzereingaben abzufangen (sieheG 5.175 Clickjacking). Derselbe Angriff ist übertragbar auf Web-Services,welche HTML-Code als Eingabe erlauben und diesen ungefiltert in ihreAusgabe übernehmen.



G 4.85 Fehlende oder mangelhafteFehlerbehandlung durchWebanwendungen und Web-Services

Treten Fehler während des Betriebs einer Webanwendung oder eines Web-Service auf, kann dies unvorhersehbare Auswirkungen haben und die Ver-fügbarkeit der Webanwendung oder des Web-Service bis zur Unerreichbar-keit einschränken. So werden gegebenenfalls Aktionen unvollständig durch-geführt, zwischengespeicherte Zustände und Daten gehen verloren oder Si-cherheitsmechanismen fallen aus. Werden Fehler nicht korrekt behandelt,kann sowohl der Betrieb als auch der Schutz der Funktionen und Daten einerWebanwendung oder eines Web-Service nicht mehr gewährleistet werden.

Beispiele:

- Im laufenden Betrieb belegen Webanwendungen und Web-Services übli-cherweise Ressourcen, wie offene Netz- oder Datei-Streams, um auf Hin-tergrundsysteme, zwischengespeicherte Zustände oder sonstige Datenzugreifen zu können. Solange die Webanwendung/der Web-Service aufdiese Ressourcen zugreift, sind diese häufig für den exklusiven Zugriff re-serviert und können nicht durch andere Prozesse verwendet werden. Wer-den im Fehlerfall die belegten Ressourcen nicht ordnungsgemäß freige-geben, so bleiben diese gegebenenfalls in einem blockierten Zustand. Da-durch können Daten verloren gehen, da beispielsweise zwischengespei-cherte Änderungen nicht ordnungsgemäß geschrieben werden können.

- Treten während der Ausführung der Sicherheitskomponenten (zum Bei-spiel Authentisierung, Autorisierung) Fehler auf und werden diese unzu-reichend behandelt, so werden angeforderte Aktionen möglicherweise un-kontrolliert ausgeführt. Aktionen, die im normalen Zustand abgelehnt wer-den, könnten im Fehlerfall zugelassen werden.

- Fehlermeldungen können detaillierte Hinweise zur Fehlerursache beinhal-ten, die für den Benutzer nicht notwendig sind jedoch gezielte Angriffe er-möglichen. Zu diesen detaillierten Informationen gehören Stacktraces, De-bugging-Ausgaben, Fehlermeldungen bei ungültigen SQL-Abfragen, An-gaben zu verwendeten Webservern und anderen Anwendungskomponen-ten. Auch scheinbar unkritische Informationen, wie die Meldung bei ei-ner fehlgeschlagenen Anmeldung mit Benutzernamen und Passwort, dassder Benutzernamen bekannt ist, aber ein ungültiges Passwort eingegebenwurde, können zum Beispiel im Rahmen von Brute-Force-Angriffen aus-genutzt werden. In diesem Fall weiß der Angreifer, dass der Benutzerna-me existiert.

- Wird die Fehlerbehandlung ausschließlich auf dem Client (zum BeispielWebbrowser oder Anwendung, welche einen Web-Service nutzt) durch-geführt, kann sie manipuliert oder außer Kraft gesetzt werden. Ein Angrei-fer kann somit die Behandlung der Fehler beeinflussen und steuern.



G 4.87 Offenlegung vertraulicherInformationen beiWebanwendungen und Web-Services

Webseiten und Daten, die von einer Webanwendung oder einem Web-Servicegeneriert und ausgeliefert werden, können vertrauliche Informationen enthal-ten, die nicht für die Nutzung der Webanwendung oder des Web-Service er-forderlich sind (zum Beispiel Angaben zu Produkt und Versionsständen vonFrameworks oder Informationen über Schnittstellen und Funktionen in WSDL-Dokumenten oder im UDDI-Register). Diese Informationen können einem An-greifer Hinweise zur Durchführung gezielter Angriffe geben. Wenn demzufol-ge Informationen unnötig offengelegt werden, kann dies einen erfolgreichenAngriff erleichtern. Hierbei können diese Informationen auch über weniger of-fensichtliche Übertragungswege übermittelt werden (zum Beispiel im HTTP-Header).

Beispiele:

- Es werden detaillierte Informationen über Sicherheitsmechanismen oder-attribute ausgegeben, die für einen Benutzer der Webanwendung oderdes Web-Service nicht notwendig sind, aber Hinweise für potenzielle An-griffe geben (zum Beispiel "Geben Sie bitte die 6-stellige, numerische PINein" anstelle von "Geben Sie bitte die PIN ein"). Aufgrund dieser Informati-on könnte ein Angreifer den möglichen Zeichenraum bei einem Brute-For-ce-Angriff einschränken und somit schneller eine gültige PIN ermitteln.

- Kommentare (zum Beispiel im HTML-Quelltext) können Informationen zubekannten Fehlern, Funktionsweisen, eingesetzten Techniken und der an-gebundenen Infrastruktur beinhalten. Ein Angreifer kann hierdurch gezieltnach Schwachstellen in der Webanwendung, dem Web-Service und derInfrastruktur suchen und diese ausnutzen. Werden zum Beispiel die inder Entwicklungsphase verwendeten Zugangsdaten für eine Datenbank inKommentaren erwähnt, können diese gegebenenfalls auch noch im pro-duktiven Betrieb der Webanwendung für den unautorisierten Zugriff ver-wendet werden.

- Dateien mit unbekannter Dateiendung (zum Beispiel temporäre Dateienmit .tmp oder Backup-Dateien mit .bak von Skripten der Webanwendung)werden von der Webanwendung im Quelltext ausgeliefert. Auf diese Wei-se können vertrauliche Informationen wie fest kodierte Zugangsdaten aus-gelesen werden. Darüber hinaus können von einem Angreifer Program-mabläufe aus dem offengelegten Code auf Schwachstellen untersuchtwerden.

- In WSDL-Dateien werden die Schnittstellen von Web-Services definiert.Werden diese Dateien einem Angreifer offengelegt, kann er dadurch In-formationen über die Schnittstellen und Aufrufparameter der angebotenenWeb-Services erhalten, die Angriffe auf diese Schnittstellen deutlich er-leichtern oder beschleunigen.



G 4.94 Unbefugter Zugriff auf Dateneines anderen Mandanten beiWebanwendungen und Web-Services

Ein zentraler Vorteil bei der Realisierung von IT-Diensten als Web-Services istdie Möglichkeit, identische Dienste auf einer gemeinsamen technischen Infra-struktur für verschiedene Anwender ("Mandanten") anzubieten und so die Be-triebskosten pro Mandant zu senken. Die Art der angebotenen Dienste kanndabei vielfältig sein, von Cloud-Speicherdiensten über Online-Zahlungsdien-ste bis hin zu Business-Anwendungen wie zum Beispiel CRM oder Finanz-buchhaltung.

Sofern die Web-Services dabei auf mandantenspezifische Datenbestände zu-greifen, besteht die Gefahr, dass durch Konzeptions- oder Implementierungs-fehler Zugriffsmöglichkeiten auf Datenbestände der anderen Mandanten desDienstes entstehen. Typische Ursachen für solche Fehler sind:

- Benutzer werden einem Mandanten falsch zugeordnet: Wenn bei der Ad-ministration der Benutzer und Berechtigungen durch einen Bedien- oderProgrammfehler eine falsche Zuordnung vorgenommen wird, kann ein Mit-arbeiter eines Mandanten irrtümlich Zugriff auf die Daten eines anderenMandanten erhalten. Hierbei kann es sich auch um die fehlerhafte auto-matisierte Abbildung von Benutzern auf technische Dienstkonten in Hin-tergrund-Systemen handeln.

- Fehler in der Programmlogik: Soweit die Trennung der mandantenspezifi-schen Daten nur durch Prüfungen im Programmcode realisiert ist, könneneinfache Programmierfehler zum Zugriff auf falsche Daten führen, die un-ter Umständen auch zu einem anderen Mandanten gehören.

- Fehlende Prüfungen beim direkten Aufruf von Web-Services: Werdenbeim direkten Aufruf eines Web-Service Parameter übergeben (oder beiREST-basierten Web-Services URL-Bestandteile geändert), die sich aufDaten eines anderen Mandanten beziehen, so besteht bei fehlerhafter be-ziehungsweise fehlender Umsetzung von Prüfungen die Möglichkeit, dassDaten des anderen Mandanten angezeigt oder verarbeitet werden.

- Unbefugter Zugriff auf administrative Schnittstellen: Sind administrativeFunktionen für die mandantenübergreifende Verwaltung des Dienstes, ins-besondere durch den Web-Service-Anbieter selbst, nicht ausreichend ge-gen unbefugten Zugriff gesichert, so kann auch hierüber ein Zugriff aufmandantenspezifische Daten möglich werden.

- Unnötige Kenntnisnahme von fremden Daten im Rahmen von Ermittlungs-tätigkeiten: Zur Aufklärung von Sicherheitsvorfällen kann es sein, dassDienstnutzer oder dritte Stellen (zum Beispiel Ermittlungsbehörden) Ein-sicht in Protokolldaten oder IT-forensische Untersuchungen an den ein-gesetzten Systemen verlangen. Fehlen entsprechende Konzepte für dieSicherstellung der Datentrennung in solchen Fällen, so können dabei un-beabsichtigt auch sensible Daten anderer, vom Vorfall nicht betroffenerMandanten erhoben und zum Beispiel in Untersuchungsberichten doku-mentiert werden.

Der Zugriff auf Daten fremder Mandanten kann in allen Fällen auch die Da-ten der eingerichteten Dienstnutzer, darunter insbesondere auch Authentisie-rungsinformationen (zum Beispiel Passwörter) umfassen. In diesem Fall kön-nen die Auswirkungen auch über den betroffenen Dienst hinausgehen, so-



fern die Authentisierungsdaten auch für andere Dienste genutzt werden oderRückschlüsse auf Passwortmuster der Anwender erlauben.

Gefährdungskatalog Vorsätzliche Handlungen G 5.18 Bemerkungen


G 5.18 Systematisches Ausprobierenvon Passwörtern

Zu einfache Passwörter lassen sich durch systematisches Ausprobieren her-ausfinden. Dabei ist zwischen dem simplen Ausprobieren aller möglichen Zei-chenkombinationen bis zu einer bestimmten Länge (sogenannter Brute-For-ce-Angriff) und dem Ausprobieren anhand einer Liste mit Zeichenkombinatio-nen (sogenannter Wörterbuch-Angriff) zu unterscheiden. Beide Ansätze las-sen sich auch kombinieren.

Die meisten Betriebssysteme verfügen über eine Datei oder Datenbank (z. B.passwd- bzw. shadow-Datei bei Unix oder RACF-Datenbank bei z/OS) mit denKennungen und Passwörtern der Benutzer. Allerdings werden zumindest diePasswörter bei vielen Betriebssystemen nicht im Klartext gespeichert, sondernes kommen kryptographische Mechanismen zum Einsatz. Ist die Datei nurunzureichend gegen unbefugten Zugriff geschützt, kann ein Angreifer dieseDatei möglicherweise kopieren und mit Hilfe leistungsfähigerer Rechner undohne Einschränkungen hinsichtlich der Zugriffszeit einem Brute-Force-Angriffaussetzen.

Die Zeit, die bei einem Brute-Force-Angriff zum Herausfinden eines Passwortsbenötigt wird, hängt ab von

- der Dauer einer einzelnen Passwortprüfung,- der Länge des Passworts undder Zeichenzusammensetzung des Passworts (z. B. Buchstaben/Zahlen).

Die Dauer einer einzelnen Passwortprüfung hängt stark vom jeweiligen Sy-stem und dessen Verarbeitungs- bzw. Übertragungsgeschwindigkeit ab. ImFalle eines Angriffs spielen auch die Methode und die Technik des Angreiferseine Rolle.

Länge und Zeichenzusammensetzung des Passworts lassen sich dagegendurch organisatorische Vorgaben oder sogar durch technische Maßnahmenbeeinflussen.

Beispiel:- Mit einem gut ausgestatteten PC lassen sich derzeit bei der

Standard-Passwort-Verschlüsselung von Unix bzw. Linux etwa400.000 Passwortprüfungen pro Sekunde durchführen. Bei der Stan-dard-Passwort-Verschlüsselung von Windows NT/2000/XP sind es sogarüber 6.000.000 Prüfungen pro Sekunde (Quelle: Der Hamburgische Da-tenschutzbeauftragte, 2003). Bei einem Zeichenvorrat von 26 Zeichendauert es somit etwa 6 Tage, um ein 8 Zeichen langes Passwort unterUnix bzw. Linux zu ermitteln (Standard-Passwort-Verschlüsselung). Diegleiche Aufgabe dauert unter Windows sogar nur etwa 9 Stunden.



G 5.19 Missbrauch vonBenutzerrechten

Eine missbräuchliche Nutzung liegt vor, wenn man vorsätzlich recht- oder un-rechtmäßig erworbene Möglichkeiten ausnutzt, um dem System oder dessenBenutzern zu schaden.

In nicht wenigen Fällen verfügen Anwender aus systemtechnischen Gründenüber höhere oder umfangreichere Zugriffsrechte, als sie für ihre Tätigkeit be-nötigen. Diese Rechte können zum Ausspähen von Daten verwendet werden,auch wenn Arbeitsanweisungen den Zugriff verbieten.

Beispiele:- Auf vielen Unix-Systemen ist die Datei /etc/passwd für jeden Benutzer les-

bar, so dass er sich Informationen über dort eingetragene persönliche Da-ten verschaffen kann. Außerdem kann er mit Wörterbuchattacken (sieheG 5.18 Systematisches Ausprobieren von Passwörtern) versuchen, dieverschlüsselten Passwörter zu erraten. Bei zu großzügiger Vergabe vonGruppenrechten, insbesondere bei den Systemgruppen wie z. B. root, bin,adm, news oder daemon, ist ein Missbrauch wie z. B. das Verändern oderLöschen fremder Dateien leicht möglich.

- Ein für die Verwaltung der Festplatten in z/OS-Systemen zuständiger Sto-rage-Administrator konnte dank des Attributes Operations, das er für dieAusführung seiner Tätigkeit von der RACF-Administration erhalten hatte,Kundendateien einsehen. Er nutzte dieses Zugriffsrecht aus, um unerlaubtKopien zu erstellen.



G 5.20 Missbrauch vonAdministratorrechten

Eine missbräuchliche Administration liegt vor, wenn man vorsätzlich recht-oder unrechtmäßig erworbene Super-User- (root-) Privilegien ausnutzt, umdem System oder dessen Benutzern zu schaden.

Beispiele:- Da root auf Unix-Anlagen keinerlei Beschränkungen unterliegt, kann der

Administrator unabhängig von Zugriffsrechten jede Datei lesen, verändernoder löschen. Außerdem kann er die Identität jedes Benutzers seines Sy-stems annehmen, ohne dass dies von einem anderen Benutzer bemerktwird, es ist ihm also z. B. möglich, unter fremden Namen Mails zu ver-schicken oder fremde Mails zu lesen und zu löschen.

- Es gibt verschiedene Möglichkeiten, missbräuchlich Super-User-Privilegi-en auszunutzen. Dazu gehören der Missbrauch von falsch administrier-ten Super-User-Dateien (Dateien mit Eigentümer root und gesetztem s-Bit) und des Befehls su.

- Die Gefährdung kann auch durch automatisches Mounten von austausch-baren Datenträgern entstehen: Sobald das Medium in das Laufwerk gelegtwird, wird es gemountet. Dann hat jeder Zugriff auf die dortigen Dateien.Mit sich auf dem gemounteten Laufwerk befindenden s-Bit-Programmenkann jeder Benutzer Super-User-Rechte erlangen.

- In Abhängigkeit von der Unix-Variante und der zugrunde liegenden Hard-ware kann bei Zugangsmöglichkeit zur Konsole der Monitor-Modus akti-viert oder in den Single-User-Modus gebootet werden. Das ermöglicht dieManipulation der Konfiguration.

- Durch Softwarefehler kann es möglich sein, dass eine Anwendung nur ei-ne begrenzt große Menge an Daten verarbeiten kann. Werden dieser An-wendung übergroße Datenmengen oder Parameter übergeben, könnenBereiche im Hauptspeicher mit fremdem Code überschrieben werden. Da-durch können Befehle mit den Rechten der Anwendung ausgeführt wer-den. Dies war unter anderem mit dem Befehl eject unter SunOS 5.5 mög-lich, der mit SetUID-Rechten ausgestattet ist, also bei der Ausführung Su-per-User-Rechte besitzt.



G 5.28 Verhinderung von Diensten

Ein solcher Angriff, auch "Denial of Service" genannt, zielt darauf ab, die Be-nutzer daran zu hindern, Funktionen oder Geräte zu verwenden, die ihnennormalerweise zur Verfügung stehen. Dieser Angriff steht häufig im Zusam-menhang mit verteilten Ressourcen, indem ein Angreifer diese Ressourcen sostark in Anspruch nimmt, dass andere Benutzer an der Arbeit gehindert wer-den. Es können zum Beispiel die folgenden Ressourcen künstlich verknapptwerden: Prozesse, CPU-Zeit, Plattenplatz, Inodes, Verzeichnisse.

Dies kann zum Beispiel geschehen durch:

- das Starten von beliebig vielen Programmen gleichzeitig,- das mehrfache Starten von Programmen, die viel CPU-Zeit verbrauchen,- das Belegen aller freien Inodes in einem Unix-System, sodass keine neuen

Dateien mehr angelegt werden können,- unkoordiniertes Belegen von Bandstationen in z/OS-Systemen, sodass

Anwendungen auf freie Bandstationen warten müssen und die Online-Ver-arbeitung eingeschränkt ist,

- bewusste Falscheingabe von Passwörtern (auch Skript-gesteuert) mitdem Ziel der Sperrung aller Kennungen eines z/OS-Systems,

- das Versenden bestimmter konstruierter Datenpakete, die beim Empfän-ger aufgrund von Software-Schwachstellen zu Fehlfunktionen oder zu ei-ner Überlastung führen können (zum Beispiel indem exzessiv kryptogra-phische Operationen aufgerufen werden),

- die gezielte Überlastung des Netzes,- das Kappen von Netzverbindungen- das gezielte Generieren von XML-Nachrichten mit großen Datenmengen,

rekursiven Inhalten, einer großen Anzahl an Verschachtelungen und feh-lerhaften DTDs, sodass ein XML-Parser intensiv Speicherressourcen sei-nes Systems belegt.



G 5.87 Web-Spoofing

Der Begriff Spoofing beschreibt das Vortäuschen einer falschen Identität durcheinen Angreifer. Verschiedene Arten von Spoofing sind zum Beispiel ARP-,DHCP-, DNS-, IP-, MAC-, Mail- und URL-Spoofing.

Beim Web- oder URL-Spoofing fälscht ein Angreifer eine existierende Web-seite, das heißt er gestaltet eine von ihm angebotene Webseite so, dass die-se wie die Webseite einer bekannten Institution aussieht. Die bereits vorhan-dene Webseite, die nachgebildet wurde, wird dabei nicht verändert, sondernist weiterhin in der ursprünglichen Form erreichbar. Mit Hilfe verschiedenerTricks versucht der Angreifer dann Benutzer auf die von ihm ins Netz gestellteWebseite zu locken.

Dazu könnte er beispielsweise seine Web-Adresse so wählen, dass viele Be-nutzer alleine durch die Adresswahl davon ausgehen, mit einer bestimmten In-stitution verbunden zu sein. So kann er beispielsweise eine Seite registrieren,bei der der Hostname mit dem der Original-Webseite identisch ist, aber dieTop-Level-Domain ausgetauscht wurde (zum Beispiel http://www.example.netstatt http://www.example.de). Er kann aber auch versuchen, eine Adressezu verwenden, die häufige Tipp- oder Schreibfehler ("Typosquatting") ent-hält und so Benutzer auf die gefälschte Seite locken (zum Beispiel http://www.exampel.com).

Eine weitere Möglichkeit besteht darin, manipulierte Links zu verbreiten. Eskönnen unterschiedliche Zeichensätze und gleich aussehende Buchstabenverwendet werden, um täuschend echt aussehende Links zu erzeugen. Bei-spielsweise könnten Zahlen, die auf den ersten Blick wie Buchstaben ausse-hen oder Buchstaben, die sich ähneln, verwendet werden. Neben dem kaumzu erkennenden Unterschied zwischen "I" (großes "i") und "l" (kleines "L") kön-nen auch ähnlich aussehende Buchstaben verwendet werden. Ein Beispielhierfür ist die lateinische und die kyrillische Schreibweise des Buchstabens"a", der jeweils gleich aussieht, aber unterschiedlich kodiert wird.

Benutzern können auch Adressen angezeigt werden, die aber nicht mit de-nen identisch sind, zu denen der Link führt. Beispielsweise kann durch dieNutzung eines HTML-Links die URL der vertrauenswürdigen Seite angezeigtwerden, obwohl der Link zu einer gefälschten Seite führt. Als andere Möglich-keit können Benutzername und Passwort in der URL dem Seitennamen voran-gestellt werden (http://[email protected]). Benutzer, die die-se Schreibweise nicht kennen, nehmen an, dass sie zu der Webseite, die alsBenutzername/Passwort angegeben ist, geleitet werden, obwohl sich der tat-sächlich verwendete Hostname wesentlich weiter hinten in der URL befindet.

Spoofing bei Web-Services

Bevor ein Web-Service-Client einen Web-Service nutzt, benötigt der Client In-formationen, wie und mit welchen Parametern der gewünschte Web-Serviceaufzurufen ist. Diese Informationen sind in den Metadaten-Dokumenten, al-so zum Beispiel einer WSDL-Datei oder einer WS-Security-Policy-Datei, de-finiert. Gelingt es einem Angreifer, diese Informationen absichtlich zu ver-ändern, kann er damit das Verhalten des Clients oder die eingesetzten Si-cherheitsmechanismen beeinflussen. Diese Art der Veränderung an Metada-ten-Dateien ist auch als Metadata Spoofing bekannt.

Weitere Spoofing-Angriffe auf Web-Services basieren auf den im SOAP-Pro-tokoll vorgesehenen optionalen Routing-Informationen. So kann beim Aufruf



eines Web-Service im <ReplyTo>-Feld der SOAP-Anfrage ein vom anfragen-den Client abweichendes System angegeben und dadurch eine IP-Verbin-dung vom Web-Server zu einem anderen System initiiert werden, um zumBeispiel einen Denial-of-Service-Angriff oder komplexere andere Angriffssze-narien durchzuführen.

- Die XY Bank verwendet die URL www.xy-bank.de für ihren Internetauf-tritt. Ein Angreifer richtet unter den URLs www.xybank.de oder www.xy-bank.com eine Webseite ein, die auf den ersten Blick derjenigen der XYBank ähneln. Zusätzlich sorgt er dafür, dass diese Adressen von XY-Kun-den über Suchmaschinen gefunden werden.Benutzer, die diese Seiten aufrufen, werden annehmen, dass sie mit demWebserver ihrer Bank kommunizieren. Daher sind sie bereit, ihre Konto-nummer und PIN oder andere Zugangscodes einzugeben.

- Die Seite whitehouse.com durchlebte eine wechselhafte Geschichte. Hierbefand sich allerdings nie, wie von vielen Benutzern zunächst vermutet,der Webauftritt des amerikanischen Weißen Hauses, sondern wechselndekommerzielle oder pornographische Inhalte.

- Die beiden URLs www.BSI.bund.de und www.BSl.bund.de sehen zumin-dest auf den ersten Blick identisch aus. Erst beim genauen hinsehen istzu erkennen, dass nur der erste zum Webauftritt des Bundesamtes fürSicherheit in der Informationstechnik führt. Beim zweiten Link wurde dasgroße "I" durch die Ziffer 1 ersetzt.

- Gelingt es einem Angreifer, einem Web-Service-Client eine modifizierteWS-Security-Policy eines Web-Service unterzuschieben, so kann er damitzum Beispiel eine Sicherheitsanforderung an verschlüsselte Kommunika-tion außer Kraft setzen und in der Folge die Daten des vom Client initiier-ten Diensteaufrufs mitlesen.



G 5.131 SQL-Injection

Greift eine Anwendung auf die Daten einer SQL-Datenbank zu, so werden Be-fehle in Form von SQL-Anweisungen an die Datenbank übermittelt. Ist die An-wendung anfällig für SQL-Injection, kann ein Angreifer durch Manipulation derEingabedaten geänderte oder zusätzliche SQL-Anweisungen injizieren, dievon der Anwendung an die Datenbank weitergeleitet und dort bearbeitet wer-den. Auf diese Weise können wie bei einem direkten Datenbankzugriff belie-bige SQL-Anweisungen ausgeführt werden und so Sicherheitsmechanismender Anwendung beim Datenzugriff umgangen werden.

Eine SQL-Injection kann daher z. B. die folgenden Auswirkungen haben:

- unberechtigter Zugriff auf Daten,- Erzeugen, Auslesen, Verändern oder Löschen von Daten,- Ausführen von Betriebssystembefehlen,- Kontrolle über die Datenbank,- Zugriff auf weitere Server (z. B. HTTP-Get-Request oder DNS-Abfrage).

Das Einschleusen der SQL-Anweisung wird dabei durch eine unzureichen-de Validierung von Eingabedaten innerhalb der Anwendung ermöglicht, die indieser Form direkt in eine dynamische Datenbankabfrage eingebaut werden(siehe auch G 4.84 Unzureichende Validierung von Ein- und Ausgabedatenbei Webanwendungen und Web-Services).

Die SQL-Injection ist ein spezieller Injection-Angriff (siehe G 5.174 Injecti-on-Angriffe), der sich ausschließlich gegen SQL-Datenbanken richtet. So istdas grundsätzliche Vorgehen zum Einschleusen von Befehlen auch bei ande-ren Interpretern möglich (z. B. LDAP-Injection, XML-Injection).



G 5.165 Unberechtigter Zugriff auf oderManipulation von Daten beiWebanwendungen und Web-Services

Wenn ein Benutzer eine Webanwendung bedient oder wenn ein Programm aufeinen Web-Service zugreift, werden Daten übertragen und üblicherweise so-wohl client- als auch serverseitig gespeichert (zum Beispiel in Protokolldatei-en, Browser- und Proxy-Cache). Wenn diese Daten bei der Übertragung undSpeicherung nicht angemessen geschützt sind, können sie unbefugt durchDritte eingesehen oder manipuliert werden.

Aufgrund der unterschiedlichen Übertragungswege und Speicherorte der Da-ten ergeben sich besondere Gefährdungen, die anhand nachfolgender Bei-spiele erläutert werden:

- Zugangs- und Formulardaten, die ein Benutzer im Web-Browser eingibt,werden im Browser-Cache zwischengespeichert. Kann ein Angreifer aufden Rechner zugreifen, dann kann er den Browser-Cache und somit dieschützenswerten Daten auslesen, da der Browser-Cache üblicherweisenicht gesondert geschützt ist (zum Beispiel durch Verschlüsselung).

- Werden GET-Parameter in der URL übertragen, können diese auf demWeg von der Webanwendung zum Client von den dazwischenliegendenIT-Systemen (zum Beispiel Proxy-Server) in deren Protokolldateien ge-speichert werden. Proxy-Server protokollieren üblicherweise die aufrufen-de URL inklusive übertragener GET-Parameter. Personen mit Zugriff aufdie Protokolle können daher die Daten in den GET-Parametern lesen.Werden von der Webanwendung schützenswerte Daten in GET-Parame-tern übermittelt, kann demzufolge der Schutz der Daten nicht gewährlei-stet werden. Darüber hinaus können vertrauliche Daten in GET-Parame-tern beim Versenden eines Links oder durch Einsicht der Browser-Historieoffengelegt werden.

- Müssen Sitzungsdaten einer Webanwendung auf dem Client hinterlegtwerden, geschieht dies häufig über eine Speicherung in Cookies. Hierbeikann es sich um schützenswerte Daten wie die Session-ID handeln. Er-langt ein Angreifer Zugriff auf den Client (zum Beispiel durch das clientsei-tige Ausführen von Schadcode), so ist es möglich, den Inhalt von Cookiesunbefugt auszulesen oder zu verwenden und unbemerkt an den Angreiferzu versenden (siehe auch G 5.170 Cross-Site Scripting (XSS)).

- Wird die Verbindung zwischen dem Web-Service-Client und dem Web-Service nicht ausreichend durch Verschlüsselung oder elektronische Si-gnaturen abgesichert, besteht die Möglichkeit, dass Angreifer vertraulicheDaten während der Übertragung einsehen oder manipulieren können.



G 5.167 Fehler in der Logik vonWebanwendungen und Web-Services

Damit Geschäftsprozesse von einer Webanwendung abgebildet werden kön-nen, werden in der Regel einzelne Funktionen zu einer komplexen Anwen-dungslogik zusammengefasst. Dabei ist es für einen Prozess entscheidend,in welcher Reihenfolge die einzelnen Funktionen oder Prozessschritte aufge-rufen werden. In einer Service-orientierten Architektur beschreibt der Begriff"Orchestrierung" die Zusammenstellung einzelner Web-Services. In der Or-chestrierung werden die logische Abfolge der Web-Services sowie die Bedin-gungen zum Aufruf und sämtliche Abhängigkeiten der einzelnen Services un-tereinander definiert.

Werden solche logischen Abläufe bei sicherheitsrelevanten Funktionen ver-wendet, wie zum Beispiel bei der Authentisierung von Benutzern, kann die-ser Ablauf unvorhergesehen manipuliert (zum Beispiel durch Übergehen vonEinzelschritten) und somit gesteuert werden. Einem Angreifer ist es so unterUmständen möglich, den Sicherheitsmechanismus zu umgehen.

Darüber hinaus können schadhafte Aktionen auch ausgelöst werden, wennFunktionen der Webanwendung oder des Web-Service für nicht vorgeseheneZwecke verwendet werden können. Beispielsweise kann ein Kontaktformulareiner Webanwendung zum Versand von SPAM missbraucht werden, wenn dievorgegebene Kontaktadresse des Formulars geändert werden kann.

Weitere Beispiele:

- Eine Webanwendung hat ein Eingabefeld, das auf eine Länge von 20 Zei-chen begrenzt werden soll. Die Eingabedaten dieses Feldes werden vonder Webanwendung zusätzlich gefiltert. Dabei ist die Filterung der Ein-gabedaten rechenintensiver als die Prüfung der Länge der Zeichenkette.Findet die aufwendigere Filterung vor der Längenprüfung statt, kann einAngreifer das Feld mit einer sehr langen Zeichenkette füllen, die von derressourcenintensiven Filterkomponente verarbeitet wird. Damit kann auf-grund der Prüfreihenfolge ein hoher Ressourcenverbrauch provoziert wer-den, der für Denial-of-Service-Angriffe ausgenutzt werden kann.

- In einem Online-Shop wird ein Preisnachlass gewährt, wenn ein bestimm-tes Produkt (Produkt X) bestellt wird. Ein Käufer möchte allerdings nichtProdukt X kaufen, sondern Produkt Y. Indem der Käufer sowohl Produkt Xals auch Produkt Y zu seinem Warenkorb hinzufügt, wird der Preisnach-lass gewährt. Der Zahlungsvorgang wird allerdings durch den Benutzerabgebrochen und Produkt X aus dem Warenkorb entfernt. Somit bestehtkein Anspruch mehr auf einen Preisnachlass. Trotzdem wird dieser aufdas Produkt Y nach einem erneuten Wechsel in den Zahlungsprozess ge-währt. Aufgrund einer fehlenden Abschlussprüfung der Kriterien für denPreisnachlass kann demzufolge ein Betrüger den Kaufpreis für Produkt Yunbefugt ändern.

- Ein Angreifer verändert bei einem Web-Service Routing-Regeln und Funk-tionen zum Informationsaustausch, so dass eine Durchführung der abge-bildeten Geschäftsprozesse verhindert wird oder vertrauliche Nachrichtenan nicht-vertrauenswürdige Systeme weitergeleitet werden. Die durch dieOrchestrierung abgebildete Logik in den Geschäftsprozessen kann nichtmehr sichergestellt werden und erweist sich als fehlerhaft. Informationenkönnen falsch oder unvollständig beim Web-Service-Client ankommen.



G 5.168 Umgehung clientseitigumgesetzterSicherheitsfunktionen vonWebanwendungen und Web-Services

Auf Webanwendungen wird gewöhnlich mit generischen Clients (zum BeispielWeb-Browsern) zugegriffen. Diese können üblicherweise durch den Benut-zer konfiguriert und angepasst werden. Sie unterliegen damit nicht der Kon-trolle der Webanwendung, sondern sind von einem Angreifer, der sich Zu-griff verschafft hat, beliebig manipulierbar. So können clientseitige Sicherheits-funktionen außer Kraft gesetzt werden. Sind keine zusätzlichen, serverseiti-gen Schutzmaßnahmen vorgesehen, kann ein Angreifer somit unbefugt aufRessourcen der Webanwendung zugreifen.

Auch Web-Services werden zum Teil durch Anwendungen genutzt, die sichnicht in einem vom Betreiber kontrollierbaren Sicherheitskontext befinden,zum Beispiel als Anwendungen auf mobilen Endgeräten ("Apps"). WerdenWeb-Services für solche Nutzungsszenarien realisiert, darf auch hier nicht vonder Umsetzung von Sicherheitsfunktionen durch den aufrufenden Client aus-gegangen werden, da für den Web-Service nicht erkennbar ist, ob der aufru-fende Client manipuliert oder gegen einen anderen Client ohne entsprechen-de Sicherheitsfunktionen ausgetauscht wurde.

In der Praxis tritt diese Gefährdung besonders häufig in Verbindung mit Be-rechtigungsprüfungen auf, die clientseitig durchgeführt, aber nach dem Auf-ruf des Web-Service nicht vom Server verifiziert werden. So schützt beispiels-weise das Ausblenden einer Schaltfläche im Client nicht davor, die für die-se Schaltfläche hinterlegte Funktion auf Serverseite aufzurufen, indem zumBeispiel der Client manipuliert wird, URLs direkt aufgerufen werden oder Re-play- oder Man-in-the-Middle-Attacken bei der Kommunikation durchgeführtwerden.

Beispiele:

- Die Eingabevalidierung ist ausschließlich clientseitig in der Programmier-sprache JavaScript umgesetzt. Ist die JavaScript-Unterstützung auf demClient deaktiviert, wird daher die Validierungsfunktion nicht ausgeführtund somit umgangen. Somit können beliebige Eingaben (wie Schadcode)an die Webanwendung gesendet und ungeprüft verarbeitet werden. EinAngreifer kann dies ausnutzen, um beispielsweise unbefugt Befehle anHintergrundsysteme der Webanwendung zu übermitteln (zum Beispiel inForm von Datenbankabfragen um eine SQL-Injection auszuführen).

- Die Webanwendung prüft ausschließlich einen clientseitig gesetzten Pa-rameter zur Authentisierung (zum Beispiel admin=true). Ist einem Angrei-fer dieser Parameter bekannt, so kann er den Parameter manuell setzenund verwenden, um sich ohne Kenntnis der Zugangsdaten an der Weban-wendung anzumelden.

- Eine Anwendung zeigt den Menüpunkt "Benutzerverwaltung" nur an, wennder eingeloggte Anwender Administrationsrechte hat. Durch einen direk-ten Aufruf des entsprechenden Web-Services ist aber auch eine Bearbei-tung der Benutzerverwaltung ohne Administrationsrechte möglich, weil derProgrammierer des Web-Service sich darauf verlassen hat, dass eine Be-rechtigungsprüfung im Client bereits durchgeführt wurde.



G 5.169 Unzureichendes Session-Management vonWebanwendungen und Web-Services

Da das von Webanwendungen und Web-Services verwendete Protokoll HTTPzustandslos ist, wird ein zusätzlicher Mechanismus benötigt, um den Benut-zer über die Dauer einer Sitzung zu identifizieren. Webanwendungen verwen-den hierbei typischerweise Session-IDs in Form eines Cookies. Bei Web-Ser-vices kann alternativ der Standard WS-SecureConversation verwendet wer-den. Hier werden Sessions als sogenannter Security Context repräsentiert,welcher wiederum über eine Session-ID innerhalb eines Security Context To-ken referenziert werden kann. Dieser Standard umfasst zusätzlich Mechanis-men zur Transportsicherung, welche bei Webanwendungen sonst typischer-weise über SSL/TSL realisiert wird.

Kann eine dritte Person aufgrund eines unzureichenden Session-Manage-ments die Session-ID ermitteln, so kann sie die Webanwendung oder denWeb-Service im Kontext dieser Sitzung verwenden. Dies hat zum Beispiel zurFolge, dass ein Angreifer mit der Webanwendung als legitimer authentisierterBenutzer interagieren kann, ohne die eigentlichen Zugangsdaten (Benutzer-name, Passwort) zu kennen.

Die Funktionalität der Webanwendung, beziehungsweise des Web-Servicekann somit von Dritten mit den Rechten des legitimen Benutzers genutzt wer-den, um unbefugt auf schützenswerte Daten zuzugreifen oder Befehle auszu-führen.

Die folgenden Beispiele beschreiben Szenarien, die zu einer kompromittiertenSitzung führen können.

- Bei einem Session-Fixation-Angriff lässt sich ein Angreifer zunächst eineSession-ID von der Webanwendung zuweisen und übermittelt diese demOpfer (zum Beispiel über einen Link in einer E-Mail). Folgt das Opfer die-sem Link und authentisiert sich anschließend gegenüber der Webanwen-dung mit der vom Angreifer übermittelten Session-ID, so kann der Angrei-fer die Anwendung anschließend mit der ihm bekannten Session-ID ver-wenden. Auf diese Weise ist es ihm möglich, im Sicherheitskontext des an-gegriffenen Benutzers auf die Webanwendung zuzugreifen und so Funk-tionen zu nutzen, die einem unauthentisierten Benutzer nicht zur Verfü-gung stehen.

- Im Falle eines Session-Hijacking-Angriffs (Sitzungsübernahme) ist dasOpfer bereits an der Webanwendung beziehungsweise dem Web-Servicemit einer gültigen Session-ID angemeldet. Wird die Session-ID nicht zufäl-lig gewählt (zum Beispiel einfaches Inkrementieren eines Zählers bei derVergabe von Session-IDs) kann ein Angreifer gültige Session-IDs durchgezieltes Ausprobieren erraten und die entsprechenden Sitzungen der an-gemeldeten Benutzer übernehmen.

- Werden Sitzungen von inaktiven Benutzern einer Webanwendung odereines Web-Service nicht automatisch nach einem bestimmten Zeitintervallungültig (Session Timeout), bleiben die Sitzungen von nicht ordnungsge-mäß von der Anwendung abgemeldeten Benutzern (zum Beispiel durchBrowser-Schließung) weiterhin gültig. Erlangt ein Angreifer Kenntnis voneiner solchen gültigen, aber nicht mehr genutzten Session-ID oder Zugriff-



stoken, so kann er die Webanwendung im Sicherheitskontext des nichtabgemeldeten Benutzers weiter verwenden.



G 5.172 Umgehung der Autorisierungbei Webanwendungen und Web-Services

Wenn ein Benutzer oder ein Web-Service-Client sich ordnungsgemäß an ei-ner Webanwendung oder einem Web-Service angemeldet hat, so hat er (inAbhängigkeit von der ihm zugewiesenen Rolle) nicht zwangsläufig Zugriff aufalle Funktionen, welche die Webanwendung oder der Web-Service bereitstel-len. Daher muss die Webanwendung oder der Web-Service nach erfolgreicherAuthentisierung des Benutzers oder des Clients für einzelne Funktionen veri-fizieren, ob dieser für die Ausführung berechtigt ist (Autorisierung).

Bei Angriffen gegen die Autorisierungskomponente wird versucht, auf Funktio-nen oder Daten zuzugreifen, die eigentlich nur einer eingeschränkten Benut-zergruppe zur Verfügung stehen. Ist die Autorisierung der Zugriffe fehlerhaftumgesetzt, kann ein Angreifer seine Berechtigungen erweitern und Zugriff aufgeschützte Bereiche und Daten erhalten. Dies geschieht üblicherweise durchgezielte manipulierte Eingaben eines Angreifers.

Denkbare Angriffsziele sind zum Beispiel Konfigurationsdateien mit fest co-dierten Zugangsdaten für Hintergrundsysteme, geschützte Bereiche oderFunktionen der Webanwendung.

Im Folgenden werden mögliche Schwachstellen bei der Autorisierung von Zu-griffen auf Web-Ressourcen aufgeführt.

Beispiele:

- Bei der Eingabe von Pfadangaben können über einen relativen Bezug(durch sogenanntes Path Traversal) nicht für den Zugriff über die We-banwendung vorgesehene Ressourcen abgerufen werden (zum Beispiel../../../config.xml). Hierdurch können unbefugt schützenswerte Dateien wieKonfigurationsdateien aus dem Dateisystem heruntergeladen oder auchüberschrieben werden. Über relative Pfadangaben lassen sich nicht nurDateien der Webanwendung erreichen, sondern es können unter Umstän-den ebenso Ressourcen des darunter liegenden IT-Systems abgerufenwerden.

- Webanwendungen verwenden häufig Objekt-Referenzen zur Adressie-rung einer Ressource in Hintergrundsystemen (zum Beispiel http://host.tld/get.php?id=2). So können Ressourcen wie Inhalte zur Darstellung ei-ner Webseite einem Datenbankeintrag zugeordnet werden. Werden Ob-jekt-Referenzen von der Autorisierungskomponente nicht berücksichtigt,kann über eine Manipulation der Referenz id in der URL gegebenenfallsauf vertrauenswürdige Ressourcen zugegriffen werden.

- Eine manchmal genutzte Möglichkeit Informationen einer Webanwendungzu schützen besteht darin, die URL, die diese Informationen verlinkt,nur autorisierten Benutzern anzuzeigen. Unautorisierten Benutzern ist dieURL nicht bekannt. Ein Angreifer kann durch systematisches Ausprobie-ren versuchen, die URL zu erraten und so Zugriff auf geschützte Informa-tionen beziehungsweise Funktionen der Webanwendung zu erhalten. Die-ser Angriff wird "Forced Browsing" genannt.

- Ist die Autorisierungskomponente eines Web-Service fehlerhaft konfigu-riert, sodass sie zum Beispiel auch anonyme Zugriffe oder Zugriffe auffalsche Dienste erlaubt, so kann ein Unberechtigter diese Dienste aufrufenund sich so Zugang zu Daten und Funktionen verschaffen.



G 5.173 Einbindung von fremdenDaten und Schadcode beiWebanwendungen und Web-Services

Werden die Ein- und Ausgabedaten einer Webanwendung oder eines Web-Service nicht ausreichend validiert, so kann ein Angreifer Inhalte, wie zumBeispiel Schadcode zur Manipulation von Server, Clients oder nachgelager-ten Systemen, einbinden. Die eingebundenen Daten werden dem Benutzerim Sicherheitskontext der Webanwendung oder des Web-Service zurückge-geben. Demzufolge ist es dem Benutzer der Webanwendung beziehungswei-se dem Consumer des Web-Service nicht oder nur eingeschränkt möglich, diemanipulierten Anteile der Ausgabe zu erkennen. Der Angreifer kann so dieVertrauensstellung des authentisierten Benutzers gegenüber der Webanwen-dung oder dem Web-Service ausnutzen.

Bei Web-Services kann Schadcode auf den Web-Service selbst oder aberauf einen Consumer des Web-Service (Endanwendung oder nachgelagerterWeb-Service) abzielen. Bei Webanwendungen können sowohl die Clients alsauch die Server der Webanwendung durch eingebundenen Schadcode ange-griffen werden. So können von einem Angreifer eingebettete Daten beispiels-weise Schadcode zur Ausführung auf den Clients (zum Beispiel zum Ausle-sen von vertraulichen Daten) oder gefälschte Anmelde-Formulare zum Dieb-stahl von Zugangsdaten beinhalten. Wird der eingebundene Programmcodevon der Webanwendung oder dem Web-Service ausgeführt, so kann darüberhinaus das Betriebssystem des Servers kompromittiert werden.

Beispiele:

- Über Parameter in der URL können in dynamischen Webseiten fremdeInhalte eingebunden werden, die sich nicht von den Inhalten der Weban-wendung unterscheiden lassen (zum Beispiel http://host.tld/index.php?frame=http://angreifer.tld&title=modifizierter Titel). Hierbei wird der über-mittelte Parameter title in der zurückgelieferten Webseite der Webanwen-dung als Titel im HTML-Dokument eingebettet. Ebenso wird der Parame-ter frame als Quelle für einen Frame auf der Webseite verwendet. Hiermitlassen sich über die Parameterwerte beliebige Inhalte und Programmcode(zum Beispiel JavaScript) in die Webseite einfügen. Derselbe Angriff istauf Web-Services übertragbar, welche über eine REST-Schnittstelle an-gesprochen werden, ihre Parameter also als Teil der URL übergeben be-kommen.

- Eine Weiterleitungsfunktion akzeptiert beliebige Werte als Zieladresse. Inder Folge kann über einen manipulierten Parameter eine Weiterleitung aufnicht vertrauenswürdige Webseiten durch einen Angreifer veranlasst wer-den (zum Beispiel http://host.tld/redirect.php?target=http://angreifer.tld).Der Benutzer erwartet aufgrund der Ursprungs-Domäne der Webanwen-dung die Weiterleitung auf eine vertrauenswürdige Adresse. Dies kannvon einem Angreifer ausgenutzt werden, um über die Weiterleitung aufeine gefälschte Anmeldeseite zur Eingabe der Zugangsdaten einen Phis-hing-Angriff zu realisieren.

- In Webanwendungen können fremde Inhalte von Partnern (zum BeispielWerbeanzeigen in einem iFrame) eingebunden werden. Die Kontrolle überdiese Inhalte liegt üblicherweise beim Partner und nicht beim Betreiber derWebanwendung. Werden Schadsoftware oder unerwünschte Inhalte überden Partner eingebunden, so kann dies den Ruf des Webanwendungs-Be-



treibers schädigen, da die Inhalte dem Benutzer im Kontext der Weban-wendung dargestellt werden. Darüber hinaus können die Clients der Be-sucher von der Schadsoftware infiziert und somit kompromittiert werden.

- Über eine Upload-Funktion der Webanwendung lassen sich beliebige Da-teien in der Verzeichnisstruktur auf dem Server speichern. Dadurch kön-nen gegebenenfalls schadhafte Skripte zur Ausführung auf der Weban-wendung gespeichert oder bestehende Dateien (zum Beispiel Konfigura-tionsdateien) überschrieben werden. Der Upload von großen Mengen anDaten kann auch zu einer Verhinderung des Dienstes führen.

- In die XML-formatierten Parameter für einen Web-Service werden externeReferenzen eingebettet, zum Beispiel <!DOCTYPE sample PUBLIC "foo""">. Falls die serverseitige Anwendung bei der Interpretation der Ergeb-nisse der externen Referenz folgt, kann der Angreifer damit ausgehendeIP-Verbindungen vom Server aus initiieren und so entweder den Betriebstören (Denial-of-Service) oder Informationen über interne Netzstrukturengewinnen.



G 5.174 Injection-Angriffe

Bei einem Injection-Angriff versucht ein Angreifer, Befehle in eine Webanwen-dung oder einen Web-Service zu injizieren und auszuführen. Der Angriff richtetsich dabei in der Regel gegen serverseitig verwendete Interpreter oder einenParser.

Werden beispielsweise eingehende Daten unzureichend validiert, so könnenEingaben (zum Beispiel Formulardaten, Cookies, SOAP-Nachrichten oderHTTP-Header) so gewählt werden, dass sie von der Webanwendung und denverwendeten Interpretern beziehungsweise Parsern (zum Beispiel SQL-Da-tenbank, XML-Prozessoren, LDAP-Verzeichnisdienst) als Befehl interpretiertwerden. Auf diese Weise können unbefugt Befehle zum Auslesen oder Mani-pulieren von Daten übermittelt werden.

Können mittels Injection beliebige System-Kommandos ausgeführt werden,so kann ein Angreifer die Webanwendung oder den Web-Service als Ersatzfür eine System-Shell nutzen. Die abgesetzten System-Kommandos werdendabei üblicherweise im Sicherheitskontext und somit mit den Privilegien derWebanwendung/des Web-Service oder des verwendeten Interpreters bezie-hungsweise Parsers ausgeführt.

Injection-Angriffe werden anhand der angegriffenen Interpreter/Parser in An-griffstypen klassifiziert. Die folgenden Beispiele verdeutlichen diese Klassifi-zierung:

- SQL-Injection (siehe auch G 5.131 SQL-Injection)- LDAP-Injection- Mail-Command-Injection- OS-Command-Injection- SSI-Injection- XPath-Injection- Code-Injection



G 5.179 Angriffe auf Protokolle

Innerhalb einer Service-orientierten Architektur (SOA) können unterschiedli-che Protokolle zum Nachrichten- und Daten-Austausch eingesetzt werden.Nicht alle Protokolle bringen dabei ausreichende Sicherheitsmechanismenmit, um die Vertraulichkeit und Integrität der übertragenen Informationen unddie Authentizität der Kommunikationspartner sicherzustellen.

So können zum Beispiel beim Einsatz von HTTP ohne zusätzliche Sicherheits-schicht (wie SSL/TLS) die übertragenen Informationen im Netz mitgelesen undgegebenenfalls sogar verändert werden. Die Sicherheit eines Web-Service istdamit abhängig von der Sicherheit der eingesetzten oder unterstützten Kom-munikationsprotokolle.

Auch beim Einsatz proprietärer oder selbst entwickelter Protokolle für die Kom-munikation ist besondere Vorsicht geboten. Die Gefahr von Implementierungs-fehlern, die sich von einem Angreifer ausnutzen lassen, ist hier gegenüberetablierten, veröffentlichten Protokollen hoch.

Werden kryptographisch abgesicherte Protokolle eingesetzt, so ist die Schut-zwirkung abhängig von den eingesetzten Kryptoverfahren, Schlüssellängenund der Implementierung der Protokolle. So kann auch der Einsatz von SSL/TLS nur einen geringen Schutz bieten, wenn veraltete Versionen des Stan-dards genutzt werden oder schwache Kryptoverfahren zum Einsatz kommen.

Ein häufig für die Kommunikation von Web-Services eingesetztes Protokoll istSOAP, das auf der Übertragung von XML-Nachrichten, im Regelfall per HTTP,basiert. Fehlende Sicherheitsmechanismen von HTTP beziehungsweise demgenutzten Übertragungsprotokoll müssen dabei durch entsprechende Struk-turen in XML, insbesondere XML-Signaturen, XML-Verschlüsselung und Au-thentisierungstoken ersetzt werden. Andernfalls drohen Angriffe wie das Ab-hören oder Verfälschen von Nachrichteninhalten, die Manipulation von Para-metern beim Diensteaufruf per SOAP oder Injection-Angriffe.



G 5.180 Angriffe auf Registries undRepositories

In einer serviceorientierten Architektur (SOA) werden Metainformationen zen-tral in Diensteverzeichnissen ("Registries") und Metadaten-Speichern ("Repo-sitories") hinterlegt. Die dort hinterlegten Informationen umfassen Dienstbe-schreibungen, Schnittstellen und Aufrufparameter, aber auch Service oder Se-curity Policies.

Die Repositories sind dabei als Datenbanken oder Verzeichnisdienste mit ei-ner definierten Schnittstelle zum Abruf der Informationen (in der Regel perHTTP) realisiert. Bei unsauberer Implementierung oder unsicherer Konfigura-tion können die Repositories von einem Angreifer manipuliert werden (zumBeispiel durch Injection-Angriffe). Damit kann der Angreifer nicht nur Informa-tionen über die angebotenen Dienste und die eingesetzten Sicherheitsmecha-nismen erlangen (siehe auch G 5.184 Informationsgewinnung über Web-Ser-vices), sondern auch die bereitgestellten Service-Beschreibungen und Poli-cies verändern oder durch eigene ersetzen. Dadurch kann er unter Umstän-den Dienst-Aufrufe oder XML-Nachrichten umleiten oder vorgesehene Sicher-heitsfunktionen außer Kraft setzen.

Durch die Verfälschung oder Löschung von Metainformationen kann ein An-greifer auch die Funktionsfähigkeit oder Nutzbarkeit der angebotenen Web-Services beeinträchtigen (Denial-of-Service). Ebenso ist es denkbar, durcheinen Denial-of-Service-Angriff auf die Registry beziehungsweise das Repo-sitory selbst die Funktionsfähigkeit der SOA sehr effektiv an einem zentralenPunkt zu attackieren.



G 5.181 Angriffe auf das Identitäts- undZugriffsmanagement bei Web-Services

Um angebotene Web-Services vor einem missbräuchlichen Zugriff zu schüt-zen, müssen entsprechende Zugriffsschutzmechanismen umgesetzt sein, diedie Identität eines aufrufenden Benutzers oder Dienstes prüfen und den Zugriffwirksam verwehren, wenn dem Benutzer oder Dienst die Berechtigung zumAufruf des Dienstes fehlt. Dabei kann die Berechtigung auch abhängig seinvon den übergebenen Parametern: So ist es zum Beispiel denkbar, dass einKunde nur Daten zu den eigenen Aufträgen abfragen darf, oder ein Berechti-gungsverwalter nur Mitarbeiter seiner eigenen Institution mit Berechtigungenausstatten kann.

Der erste mögliche Ansatzpunkt für einen Angreifer ist hier das verwendeteZugriffsschutzsystem selbst. Findet der Angreifer Fehler in der Berechtigungs-prüfung, so kann er diese ausnutzen, um sich unbefugten Zugriff zu verschaf-fen. Dies ist insbesondere der Fall, wenn Berechtigungsprüfungen nicht um-gesetzt werden, weil die Entwickler implizite Annahmen darüber machen, werdie Services in welchem Kontext aufruft. Dass eine Funktion in einer Anwen-dung erst nach erfolgreicher Anmeldung zur Verfügung steht, heißt aber ebennicht, dass der dahinterstehende Web-Service von einem Angreifer nicht auchaußerhalb des Anwendungskontextes aufgerufen werden kann.

Nutzt das Zugriffsschutzsystem für die Berechtigungsprüfung Informationenaus einer externen Quelle, zum Beispiel einem Verzeichnisdienst, so kannder Angreifer auch versuchen, die Berechtigungsinformationen in der externenQuelle zu manipulieren oder dem Zugriffsschutzsystem falsche oder manipu-lierte Berechtigungsdaten unterzuschieben, zum Beispiel durch einen Man-in-the-Middle-Angriff (siehe G 5.143 Man-in-the-Middle-Angriff).

Ein zweiter Angriffspunkt ist die Identität des aufrufenden Benutzers oderDienstes. Gelingt es dem Angreifer, einen Dienstaufruf mit der Identität einesberechtigten Benutzers oder Dienstes zu initiieren, so kann er effektiv dessenBerechtigungen für die Durchführung seines Angriffs missbrauchen.

Ein solcher Identitätsdiebstahl kann beispielsweise durch eine schwacheImplementierung des Sitzungsmanagements möglich werden ("Session Hi-jacking" oder "Session Fixation", siehe auch G 5.169 Unzureichendes Sessi-on-Management von Webanwendungen und Web-Services). Andere Angriffs-arten umfassen das Mitschneiden von Nachrichten und das Wiedereinspielender aufgezeichneten Nachrichten (mit gültigen Authentisierungsinformationendes originalen Absenders) in einem anderen Kontext ("Replay-Attacken"). So-fern hiergegen keine Schutzmaßnahmen vorgesehen sind, kann der Angrei-fer dabei gegebenenfalls sogar verschlüsselte Nachrichten abfangen und ver-wenden, ohne dass er die eingesetzte Verschlüsselung brechen muss.

Schließlich können auch externe, vom Web-Service genutzte Identitätsmana-gement-Dienste angegriffen werden mit dem Ziel, sich gegenüber dem Web-Service wirksam als ein berechtigter Dienstnutzer auszuweisen. Bei fehlen-den Mechanismen zur Dienstauthentisierung kann der Angreifer dabei auchentweder gegenüber dem Web-Service oder dem Dienstnutzer einen eige-nen Identitäts-Dienst zum Einsatz bringen und so entweder dem Dienst einefalsche Identität vorgaukeln oder den legitimen Benutzer zur Preisgabe vonAuthentisierungsdaten bewegen.



G 5.182 Manipulation von Routen(Routing Detours)

SOAP-Nachrichten können unter Verwendung des Standards WS-Routingoder WS-Addressing Informationen über die Route enthalten, die die Nach-richt durchlaufen soll. Dadurch können zum Beispiel Kommunikationsflüsseabgebildet werden, ebenso aber auch Geschäftsprozesse, indem zum Bei-spiel eine Bestellnachricht nacheinander an verschiedene Dienste (Verfüg-barkeitsprüfung, Bezahlung, Bestellung) weitergereicht wird. Bei Verwendungvon WS-Routing enthält die Nachricht dabei bereits die gesamte Abfolge vonZieladressen, bei WS-Addressing nur den jeweils nächsten Empfänger.

Gelingt es einem Angreifer, mit einem Man-in-the-Middle-Angriff (siehe auchG 5.143 Man-in-the-Middle-Angriff) die SOAP-Nachrichten beim Versand oderauf dem Übertragungsweg zu manipulieren, so können dabei neben einer Ver-änderung der Nachrichteninhalte auch die eingebetteten Routing-Informatio-nen verändert werden. Dadurch erhält der Angreifer Kontrolle über die weitereVerarbeitung der Nachricht. Mögliche Angriffe auf diesem Weg sind:

- Der Angreifer kann die Route der SOAP-Nachricht um zusätzliche Syste-me erweitern, die unter seiner eigenen Kontrolle sind. Beim Einsatz vonWS-Routing ist es dabei gegebenenfalls sogar möglich, die Nachricht nachder Verarbeitung durch einen der vorgesehenen Services zurück an denAngreifer zu spielen. So könnte er zum Beispiel eine Preisangabe verrin-gern, die Nachricht an den Bezahldienst leiten und von dort wieder an eineigenes System, das die Manipulation rückgängig macht, bevor die Nach-richt weiter an die nachgelagerten Services übergeben wird.

- Der Angreifer kann die Übermittlung der SOAP-Nachricht an vorgeseheneServices unterbinden. So kann zum Beispiel der Bezahlvorgang oder einzwischengeschobener Prüfschritt ausgelassen werden, indem die Nach-richt direkt an den nächsten vorgesehenen Service übermittelt wird.

- Der Angreifer kann die Reihenfolge oder Abfolge der Services ändern, andie die Nachricht übermittelt wird. Je nach der Logik der Anwendungsar-chitektur kann das Effekte haben, die vom Angreifer zu seinen Gunstenausgenutzt werden.

- Der Angreifer kann ungültige Adressen in die Route einbringen und da-mit Nachrichten unterdrücken oder Fehlerzustände hervorrufen (Denial ofService).



G 5.183 Angriffe auf XML

Web-Services verwenden häufig XML als Grundlage für ihr Nachrichtenfor-mat. Das hat zur Folge, dass alle eingehenden Nachrichten zunächst an einenXML-Parser übergeben werden, der die XML-Strukturen auswertet und dieenthaltenen Daten zur Verarbeitung durch den Web-Service extrahiert.

Der XML-Parser wird dabei sinnvollerweise nicht für jeden Web-Service neuentwickelt, sondern als fertige Drittkomponente eingebunden. Solche XML-Parser bieten dabei einen Funktionsumfang, der häufig über die vom Web-Service tatsächlich benötigten Parserfunktionen hinausgeht. Damit erhöht sichjedoch auch die Angriffsfläche des Web-Service. Immer wieder finden sich inden eingesetzten XML-Parsern auch Schwachstellen, die ein Angreifer durchdie entsprechende Gestaltung von XML-Eingaben ausnutzen kann. GeradeSchwachstellen durch ungenutzte Parserfunktionen werden dabei oft überse-hen oder in ihrer Bedeutung unterschätzt.

Da XML-Dokumente sehr komplex sein können, kann auch der Ressourcen-verbrauch für das XML-Parsen entsprechend ansteigen. Dies können Angrei-fer ausnutzen, indem sie XML-Strukturen so gestalten (Verschachtelung, Re-kursion, externe Verweise), dass sie den Ressourcenverbrauch des Parsersgezielt erhöhen und das verarbeitende System damit an seine Lastgrenzenbringen.

Es sind verschiedene Angriffsarten bekannt, die auf der Gestaltung speziellerXML-Nachrichten zur Erreichung des Angriffsziels basieren:

Coercive Parsing

Beim Coercive Parsing überlastet der Angreifer den eingesetzten XML-Parser,indem er ihm als Eingabe eine sehr große oder unbegrenzte Anzahl von Star-telementen (Opening Tags) für XML-Elemente schickt. Hat der Parser keinAbbruchkriterium für die Verarbeitung, so belegt er für jedes neu geöffneteElement neuen Speicher auf einer neuen Verschachtelungsebene, bis die vor-handenen Ressourcen erschöpft sind.

XML Entity Expansion (XML Bomb)

Bei dieser Attacke werden durch starke Verschachtelung oder Rekursion vonEntity-Definitionen mit sehr kurzen XML-Dokumenten sehr umfangreiche Da-tenstrukturen beschrieben. XML-Parser, die diese Art von Attacke nicht er-kennen und über ein sinnvolles Abbruchkriterium verhindern, konstruieren beider Auswertung des XML-Dokuments die beschriebene Datenstruktur im Spei-cher. Der Angreifer kann dadurch mit sehr geringem Aufwand die vorhande-nen Systemressourcen vollständig blockieren. Varianten dieses Angriffs nut-zen externe Verweise und belegen so zusätzliche Ressourcen für deren Auf-lösung.

XML Document Size

Der Angreifer sendet ein überlanges Dokument an den Web-Service, um denXML-Parser zur Ausschöpfung der vorhandenen Systemressourcen zu brin-gen.

Oversized XML

Bei dieser Angriffsvariante nutzt der Angreifer den Umstand, dass der Stan-dard keine Längenbeschränkungen für XML-Bestandteile wie Elementnamen,



Attributnamen oder Namensräume vorsieht, und versucht, durch Überlängenin diesen Bestandteilen den XML-Parser zum Absturz zu bringen.

XML Document Width/XML Document Depth

Auch dieser Angriff zielt auf die Belegung von Systemressourcen durch denParser, hier allerdings durch eine übergroße Anzahl von Attributen (Width)oder Verschachtelungsstufen (Depth) und dadurch die Belegung übergroßerSpeichermengen.

XML Wellformedness

Auch über bewusst in die XML-Struktur eingebrachte Fehler lassen sich XML-Parser angreifen. Dies können zum Beispiel überlappende oder nicht ge-schlossene XML-Elemente sein. Je nach Implementierung können dadurchFehlerzustände im Parser hervorgerufen werden, die gegebenenfalls nicht ge-eignet behandelt werden.

XML Schema Poisoning

XML-Schemata werden verwendet, um die Konformität von XML-Daten zu denerwarteten Strukturen zu überprüfen. Gelingt es dem Angreifer, extern refe-renzierte Schemata zu manipulieren oder durch eigene zu ersetzen, so kanner damit unter Umständen Prüfungen der übergebenen Daten durch den Web-Service aushebeln und so schadhafte Bestandteile einbetten.

XML External Entities/XML External References

XMLDokumente können Verweise auf externe Dokumente oder Entitäten ent-halten, die bei der Verarbeitung des XML-Dokuments durch den Parser au-tomatisch aufgelöst werden, indem der Parser die externe Ressource nach-lädt und auswertet. Dadurch kann der Angreifer erreichen, dass das Parser-system Verbindungen zu den angegebenen URLs initiiert. Neben Denial-Of-Service-Angriffen durch das Nachladen von übergroßen oder nicht erreichba-ren Dokumenten kann der Angreifer das auch ausnutzen, um zum BeispielSicherheitsgateways auszuhebeln, in dem das Parsersystem Verbindungenaus seiner eigenen Netzumgebung heraus initiiert. So können zum Beispielandere Web-Services in einer DMZ, die von außen nicht direkt aufrufbar sind,auf diesem Wege angesprochen werden.

Gelingt es dem Angreifer, die Inhalte extern abgelegter Ressourcen zu än-dern, kann er damit mittelbar auch den Web-Service angreifen, wenn dieserim Rahmen eines legitimen Aufrufs durch einen anderen Nutzer die manipu-lierten Ressourcen inklusive der schadhaften Inhalte des Angreifers nachlädt.

XML Signature Wrapping

XML-Signaturen sichern die Integrität und/oder Authentizität von XML-Doku-menten, indem sie kryptographische Prüfsummen über Elemente bilden, diedurch eine entsprechende Referenz in der Signatur bezeichnet sind. Die Si-gnatur sichert dabei nur das referenzierte Element, unabhängig von seinerEinbindung in den XML-Kontext. Ein Angreifer kann daher durch eine Verän-derung der XML-Dokumentstruktur dafür sorgen, dass das durch die Signaturgesicherte Element zwar in sich unverändert erhalten bleibt, aber vom Parsernicht oder nicht in der beabsichtigten Form ausgewertet wird, weil zum Bei-spiel weitere, gleichartige Elemente mit manipuliertem Inhalt auf höherer Ebe-ne in die XML-Struktur eingebracht werden. Die Signaturprüfung führt dann



weiter zu einem positiven Ergebnis, obwohl der Web-Service manipulierte In-halte verarbeitet.

Die hier aufgeführten Angriffsarten sind nur Beispiele, zahlreiche weitere An-griffe sind bekannt oder werden neu entwickelt, basieren aber auf denselbenoder sehr ähnlichen Angriffsprinzipien.



G 5.184 Informationsgewinnung überWeb-Services

Damit in einer Service-orientierten Architektur (SOA) Web-Services zur Erfül-lung übergreifender Aufgaben dynamisch kombiniert werden können (Orche-strierung), stellen die einzelnen Web-Services Informationen über sich und ih-re Schnittstellen in standardisierter Form als WSDL-Dokumente bereit (WebService Description Language). Die Consumer können dadurch in standardi-sierter, maschinenlesbarer Form alle nötigen Informationen zum Aufruf desDienstes abrufen. Die WSDL-Dokumente werden in einer SOA über ein zen-trales Verzeichnis (engl. Repository) bereitgestellt.

Die aus diesen Schnittstellenbeschreibungen ersichtlichen Informationen kön-nen jedoch auch für Angreifer wertvolle Hinweise enthalten und damit Angriffeauf die Dienste vorbereiten oder erleichtern. Da WSDL-Dateien oft automati-siert aus den verwendeten Entwicklerframeworks generiert werden, enthaltensie häufig mehr Angaben, als für den Einsatz tatsächlich benötigt werden.

Angreifer, die sich gegen Web-Services richten, beginnen häufig mit einer Er-kundungsphase, in der der Angreifer versucht, WSDL-Dateien zu den ange-botenen Services abzurufen und auszuwerten, zum Beispiel mit Hilfe einerSuchmaschine (WSDL Google Hacking).

Zu den Informationen, die für einen Angreifer von Interesse sein können, ge-hören:

- Namen von aufrufbaren Methoden und zugehörige Parameter. Gerade beiautomatisch generierten WSDL-Dokumenten sind hier oft auch Methodenenthalten, die für einen Aufruf von außen gar nicht vorgesehen sind. An-greifer können durch den direkten Aufruf solcher Methoden versuchen, Si-cherheitsfunktionen wie Berechtigungsprüfungen zu umgehen.

- Informationen über verwendete Namensschemata. So können Angreiferaus den Namen von veröffentlichten Methoden versuchen, die Namen wei-terer, nicht veröffentlichter Methoden zu erraten und diese direkt aufzuru-fen. Das Ausprobieren nicht veröffentlichter, aber aus veröffentlichten Na-men abgeleiteter Methoden wird auch WSDL Scanning oder WSDL Enu-meration genannt.

Mit den Informationen über die erreichbaren (veröffentlichten oder abgeleite-ten) Methoden und Aufrufparameter kann der Angreifer versuchen, nicht fürihn bestimmte Funktionen direkt aufzurufen. Weiter kann er aber auch, durchdie Veränderung von Aufrufparametern, Fehlerzustände provozieren, um zumBeispiel aus den Fehlermeldungen weitere Rückschlüsse auf die technischeRealisierung zu ziehen (zum Beispiel zu Datenbanktabellen und Feldnamen,verwendeten Bibliotheken und Frameworks). Aus den Fehlermeldungen lässtsich unter Umständen auch schließen, wie der Service die übermittelten Pa-rameter prüft. Auf Grundlage der Erkenntnisse können dann weitere Angriffe(zum Beispiel Injection-Angriffe) gestartet werden.

Eine weitere Angriffsvariante besteht darin, die URL zum Aufruf eines Web-Service zu manipulieren, um dadurch andere, nicht zum Aufruf von außenbestimmte Services zu finden und auszunutzen (zum Beispiel durch Wechseldes Server-Verzeichnisses mit Directory Traversal). Solche Angriffe droheninsbesondere bei REST-Schnittstellen durch die semantische Bedeutung derURL für den Diensteaufruf.

Maßnahmenkatalog Organisation M 2.1 Bemerkungen


M 2.1 Festlegung vonVerantwortlichkeiten undRegelungen

Verantwortlich für Initiierung: Behörden-/UnternehmensleitungVerantwortlich für Umsetzung: Leiter IT, Leiter Organisation

Für alle wesentlichen Aufgaben und Geschäftsprozesse in einer Institutionsollten die Verantwortlichkeiten nachvollziehbar geregelt sein. Die Aufgabensollten dabei so zugeschnitten sein, dass es keine Überschneidungen zwi-schen ähnlichen Aufgaben gibt, aber auch keine Zuständigkeitslücken. Diessollte für alle Bereiche eine Selbstverständlichkeit sein, für alle sicherheitsre-levanten Aufgaben ist es aber unabdingbar.

Die sicherheitsrelevanten Aufgaben aller internen und externen Mitarbeiterund Dienstleister müssen nachvollziehbar festgelegt sein. Sie müssen mit denSicherheitszielen der Institution abgestimmt sein. Zu den Bereichen, die gere-gelt werden sollten, gehören beispielsweise:

- explizite Zuweisung der Verantwortlichkeiten und Befugnisse an Rol-len bzw. Organisationseinheiten bei allen sicherheitsrelevanten Aufgaben(Dabei ist sicherzustellen, dass alle Rollen konkreten Personen zugeord-net sind),

- geeigneter Umgang mit geschäftskritischen Informationen, so dass derenVertraulichkeit, Integrität und Verfügbarkeit angemessen geschützt sind,

- Vertraulichkeitsvereinbarungen,- Einbeziehung des Sicherheitsbeauftragten bei Aufträgen und Projekten,

die geschäftskritische Informationen betreffen,- Unterrichtungen über den geeigneten Umgang mit geschäftskritischen In-

formationen, beispielsweise im Kontakt mit Kunden oder auf Reisen,- Festlegung von Verhaltensregeln und Informationspflichten bei sicher-

heitsrelevanten Aktionen und bei Sicherheitsvorfällen,- Klassifikation von Informationen entsprechend ihres Schutzbedarfs.

Die Regelungen für Informationssicherheit sollten mit denen für Datenschutzund Geheimschutz in geeigneter Weise zusammengeführt werden, damit sievon den Mitarbeitern leichter adaptiert und besser wahrgenommen werdenkönnen. Wichtig ist auch, dass alle Regelungen zusammengenommen wider-spruchsfrei sind.

Übergreifende Regelungen zur Informationssicherheit müssen als ein Aspektder Informationsverarbeitung verbindlich festgelegt werden.

Es empfiehlt sich, Regelungen unter anderem über die Themen

- Datensicherung,- Datenarchivierung,- Datenträgertransport,- Datenübertragung,- Datenträgervernichtung,- Dokumentation von IT-Verfahren, Software, IT-Konfiguration,- Zutritts-, Zugangs- und Zugriffsberechtigungen,- Wartungs- und Reparaturarbeiten,- Datenschutz,- Schutz gegen Schadsoftware,- Revision,- Notfallvorsorge und



- Vorgehensweise bei der Verletzung von Sicherheitsrichtlinien

zu treffen. Hinweise dazu finden sich in den Maßnahmenbeschreibungen derjeweils relevanten IT-Grundschutz-Bausteine.

Die in Kraft gesetzten Regelungen sind den betroffenen Mitarbeitern in ge-eigneter Weise bekannt zu geben (siehe M 3.2 Verpflichtung der Mitarbeiterauf Einhaltung einschlägiger Gesetze, Vorschriften und Regelungen). Es emp-fiehlt sich, die Bekanntgabe zu dokumentieren. Darüber hinaus sind sämtlicheRegelungen in der aktuellen Form an einer Stelle vorzuhalten und bei berech-tigtem Interesse zugänglich zu machen.

Die getroffenen Regelungen sind regelmäßig zu aktualisieren, um Missver-ständnisse, ungeklärte Zuständigkeiten und Widersprüche zu vermeiden undgegebenenfalls aufzulösen. Alle Regelungen sollten deshalb auch ein Erstel-lungsdatum oder eine Versionsnummer enthalten.

Prüffragen:

- Sind die Verantwortlichkeiten und Befugnisse bei allensicherheitsrelevanten Aufgaben klar geregelt?

- Werden die Regelungen regelmäßig überarbeitet und auf einem aktuellenStand gehalten?

- Wurden die Regelungen allen Mitarbeitern bekannt gegeben?



M 2.8 Vergabe von ZugriffsrechtenVerantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter ITVerantwortlich für Umsetzung: Administrator, Fachverantwortliche

Über Zugriffsrechte wird geregelt, welche Person im Rahmen ihrer Funkti-on bevollmächtigt wird, IT-Anwendungen oder Daten zu nutzen. Die Zugriffs-rechte (z. B. Lesen, Schreiben, Ausführen) auf IT-Anwendungen, Teilanwen-dungen oder Daten sind von der Funktion abhängig, die die Person wahr-nimmt, z. B. Anwenderbetreuung, Arbeitsvorbereitung, Systemprogrammie-rung, Anwendungsentwicklung, Systemadministration, Revision, Datenerfas-sung, Sachbearbeitung. Dabei sollten immer nur so viele Zugriffsrechte ver-geben werden, wie es für die Aufgabenwahrnehmung notwendig ist ("Need-to-know-Prinzip"). Umgesetzt werden müssen die Zugriffsrechte durch die Rech-teverwaltung des IT-Systems.

Eine Vielzahl von IT-Systemen lassen es zu, dass verschiedene Rechte alsGruppenrechte bzw. als Rechteprofil definiert werden (z. B. Gruppe Datener-fassung). Diese Definition entspricht der technischen Umsetzung der Rech-te, die einer Funktion zugeordnet werden. Für die Administration der Rechteeines IT-Systems ist es vorteilhaft, solche Gruppen oder Profile zu erstellen,da damit die Rechtezuteilung und deren Aktualisierung erheblich vereinfachtwerden kann.

Die Festlegung und Veränderung von Zugriffsrechten ist vom jeweils Verant-wortlichen zu veranlassen und zu dokumentieren. Aus der Dokumentationmuss hervorgehen:

- welche Funktion unter Beachtung der Funktionstrennung (siehe M 2.5 Auf-gabenverteilung und Funktionstrennung) mit welchen Zugriffsrechten aus-gestattet wird,

- welche Gruppen bzw. Profile eingerichtet werden,- welche Person welche Funktion wahrnimmt,- welche Zugriffsrechte eine Person im Rahmen welcher Rolle erhält (hier-

bei sollten auch die Zugriffsrechte von Vertretern erfasst werden) und- welche Konflikte bei der Vergabe von Zugriffsrechten aufgetreten sind.

Diese Konflikte können z. B. daraus resultieren, dass eine Person unver-einbare Funktionen wahrnimmt oder daraus, dass abhängig vom IT-Sy-stem die Trennung bestimmter Zugriffsrechte nicht vorgenommen werdenkann.

- welche Personen in einem Notfall welche Zugriffsrechte erhalten, z. B. dasie zum Krisenstab gehören.

Die Vorgehensweise bei der Funktionstrennung und der Rechtevergabe wirdam nachfolgenden Beispiel erläutert.

Die betrachtete Anwendung ist ein Reisekosten-Abrechnungssystem. Die re-levanten Räume sind in nachfolgender Graphik erläutert. Das IT-System be-steht aus einem LAN, an dem neben einem Server und der Bedienkonsoledrei PCs als Arbeitsplatzrechner angeschlossen sind.



Abbildung: Aufgabenvertei-lung und Funktionstrennung

Schritt 1: Aufgabenverteilung und Funktionstrennung

Folgende Funktionen sind für das betrachtete Reisekosten-Abrechnungssy-stem notwendig:

1. LAN-Administration2. Revision3. Datenerfassung4. Sachbearbeitung mit Feststellung der rechnerischen Richtigkeit5. Sachbearbeitung mit Feststellung der sachlichen Richtigkeit6. Sachbearbeitung mit Anordnungsbefugnis

Folgende Funktionen sind aufgrund der Sachzwänge nicht miteinander ver-einbar:

- Funktion 1 und Funktion 2 (die Administration darf sich nicht selbst kon-trollieren)

- Funktion 2 und Funktion 6 (der Anordnungsbefugte darf sich nicht selbstkontrollieren)

- die Kombination der Funktionen 4 oder 5 mit 6 (das Vier-Augen-Prinzipwäre verletzt für Zahlungsanweisungen)

Diese Funktionen werden durch folgende Personen wahrgenommen:

Hr. Mayer Fr.Schmidt

Hr. Müller Fr. Fleiß

1. LAN-Administra-tion

X

2. Revision X

3. Datener-fassung

X

4. Sachbear-beitungrechn.

X

5. Sachbear-beitungsachl.

X

6. Anord-nungsbe-fugnis

X



Schritt 2: Vergabe von Zutrittsrechten

Nachfolgend wird der Schutzbedarf der einzelnen Räume begründet und inder Tabelle die Vergabe der Zutrittsrechte dokumentiert:

- Serverraum:Der unbefugte Zutritt zum Server muss verhindert werden, weil die Verfüg-barkeit, Integrität und Vertraulichkeit der gesamten Anwendung von dieserzentralen Komponente abhängig ist.

- Belegarchiv:Für die Rechnungslegung müssen die Reisekostenabrechnungen länger-fristig aufbewahrt werden. Es ist sicherzustellen, dass die Belege vollstän-dig und unverändert aufbewahrt werden.

- Büro 1:In diesem Büro werden die notwendigen Daten erfasst sowie die rechne-rische und sachliche Richtigkeit festgestellt. Für die Gewährleistung derKorrektheit dieser Vorgänge muss verhindert werden, dass Unbefugte Zu-tritt zu den Arbeitsplatzrechnern erhalten.

- Büro 2:Hier wird die Auszahlung der Reisekosten am APC angeordnet. DieserVorgang darf nur von einer befugten Person vorgenommen werden. Un-befugten ist der Zutritt zu verwehren.

Server-raum

Belegar-chiv

Büro 1 Büro 2


X

2. Revision X X X X

3. Datener-fassung

X


X X


X X


X X X

Schritt 3: Vergabe von Zugangsberechtigungen

Aufgrund der Funktionen ergeben sich folgende Zugangsberechtigungen:

Betriebs-systemServer

Anwen-dung Pro-tokollaus-wertung

Anwen-dung Da-tenerfas-sung

Anwen-dung Be-legbear-beitung


X

2. Revision X X X




Anwen-dung Pro-tokollaus-wertung



3. Datener-fassung

X


X


X


X

Schritt 4: Vergabe von Zugriffsrechten

Im folgenden werden die Zugriffsrechte, die eine Funktion zur Ausübung be-nötigt, dargestellt. Es bezeichnen:

A = Recht zur Ausführung der Anwendung/Software

L = Leserecht auf Daten

S = Schreibrecht, d.h. Erzeugen von Daten

M = Recht zum Modifizieren von Daten

Ö = Recht zum Löschen von Daten

U = Recht zum Unterschreiben von Zahlungsanweisungen


Protokoll-auswer-tung




A,L,S,M,Ö

2. Revision A,L A,L,Ö A,L

3. Datener-fassung

A,S


A,L,M


A,L,M


A,L,U



Eine solche Dokumentation erleichtert die Rechteverteilung. Angenommen,dass Frau Schmidt den Arbeitgeber wechseln würde und ihre Stelle neu be-setzt werden müsste, so lässt sich anhand der obigen Tabellen einfach fest-stellen, welche der ehemaligen Rechte Frau Schmidts zu löschen und für dieneue Kraft einzurichten sind. Wenn die neue Kraft zusätzlich vertretungswei-se die Funktion Sachbearbeitung mit Anordnungsbefugnis übernehmen soll,so wird anhand der durchzuführenden Rechteverteilung der Konflikt offenbar,dass die neue Kraft im Vertretungsfall Manipulationen unbemerkt durchführenkönnte.

Prüffragen:

- Liegt eine aktuelle Dokumentation der vergebenen Zugriffsrechte vor?- Werden nur die Zugriffsrechte vergeben, die für die jeweiligen Aufgaben

erforderlich sind?- Werden beantragte Zugriffsrechte oder Änderungen erteilter

Zugriffsrechte von den Verantwortlichen bestätigt und geprüft?- Existiert ein geregeltes Verfahren für den Entzug von Zugriffsrechten?



M 2.31 Dokumentation derzugelassenen Benutzer undRechteprofile

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter ITVerantwortlich für Umsetzung: Administrator

Es muss eine Dokumentation der am IT-System zugelassenen Benutzer, an-gelegten Benutzergruppen und Rechteprofile erfolgen. Dabei gibt es verschie-dene Dokumentationsmöglichkeiten wie beispielsweise über

- vorgegebene Administrationsdateien des Systems,- individuelle Dateien, die vom zuständigen Administrator verwaltet werden,- in Papierform.

Es sollte eine geeignete Form ausgewählt werden, möglichst einheitlich fürdie gesamte Institution.

Dokumentiert werden sollten insbesondere folgende Angaben zur Rechtever-gabe an Benutzer und Benutzergruppen:

Zugelassene Benutzer:

- zugeordnetes Rechteprofil (gegebenenfalls Abweichungen vom verwen-deten Standard-Rechteprofil)

- Begründung für die Wahl des Rechteprofils (und gegebenenfalls der Ab-weichungen)

- Zuordung des Benutzers zu einer Organisationeinheit, Raum- und Tele-fonnummer

- Zeitpunkt und Grund der Einrichtung- Befristung der EinrichtungZugelassene Gruppen:

- zugehörige Benutzer- Zeitpunkt und Grund der Einrichtung- Befristung der Einrichtung

Die Dokumentation der zugelassenen Benutzer und Rechteprofile sollte regel-mäßig (mindestens alle 6 Monate) daraufhin überprüft werden, ob sie den tat-sächlichen Stand der Rechtevergabe widerspiegelt und ob die Rechtevergabenoch den Sicherheitsanforderungen und den aktuellen Aufgaben der Benutzerentspricht. Die vollständige Dokumentation ist Voraussetzung für Kontrollender vergebenen Benutzerrechte.

Die Dokumentation muss so gespeichert beziehungsweise aufbewahrt wer-den, dass sie vor unbefugtem Zugriff geschützt ist und so, dass auch bei einemgrößeren Sicherheitsvorfall oder IT-Ausfall darauf zugegriffen werden kann.Falls die Dokumentation in elektronischer Form erfolgt, muss sie in das Da-tensicherungsverfahren einbezogen werden.

Prüffragen:

- Sind die zugelassenen Benutzer, angelegten Benutzergruppen undRechteprofile dokumentiert?

- Wird die Dokumentation der zugelassenen Benutzer, angelegtenBenutzergruppen und Rechteprofile regelmäßig auf Aktualität überprüft?

- Ist die Dokumentation der zugelassenen Benutzer, Benutzergruppen undRechteprofile vor unbefugtem Zugriff geschützt?



- Wird die Dokumentation der zugelassenen Benutzer, Benutzergruppenund Rechteprofile - sofern sie elektronisch erfolgt - in dasDatensicherungsverfahren einbezogen?



M 2.34 Dokumentation derVeränderungen an einembestehenden System


Um einen reibungslosen Betriebsablauf zu gewährleisten, muss der Admini-strator einen Überblick über das System haben bzw. sich verschaffen können.Dieses muss auch für seinen Vertreter möglich sein, falls der Administratorunvorhergesehen ausfällt. Der Überblick ist auch Voraussetzung, um Prüfun-gen des Systems (z. B. auf problematische Einstellungen, Konsistenz bei Än-derungen) durchführen zu können.

Daher sollten die Veränderungen, die Administratoren am System vornehmen,dokumentiert werden, nach Möglichkeit automatisiert. Dieses gilt insbesonde-re für Änderungen an Systemverzeichnissen und -dateien.

Bei Installation neuer Betriebssysteme oder bei Updates sind die vorgenom-menen Änderungen besonders sorgfältig zu dokumentieren. Möglicherweisekann durch die Aktivierung neuer oder durch die Änderung bestehender Sy-stemparameter das Verhalten des IT-Systems (insbesondere auch Sicher-heitsfunktionen) maßgeblich verändert werden.

Unter Unix müssen ausführbare Dateien, auf die auch andere Benutzer als derEigentümer Zugriff haben oder deren Eigentümer root ist, vom Systemadmini-strator freigegeben und dokumentiert werden (siehe auch M 2.9 Nutzungsver-bot nicht freigegebener Hard- und Software). Insbesondere müssen Listen mitden freigegebenen Versionen dieser Dateien geführt werden, die außerdemmindestens das Erstellungsdatum, die Größe jeder Datei und Angaben überevtl. gesetzte s-Bits enthalten. Sie sind Voraussetzung für den regelmäßigenSicherheitscheck und für Überprüfungen nach einem Verlust der Integrität.

Prüffragen:

- Werden Systemänderungen ausreichend und für eine fachkundige Personnachvollziehbar dokumentiert?



M 2.35 Informationsbeschaffung überSicherheitslücken des Systems

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter ITVerantwortlich für Umsetzung: Administrator, IT-Sicherheitsbeauftragter

Gegen bekannt gewordene und durch Veröffentlichungen zugänglich gemach-te Sicherheitslücken müssen die erforderlichen organisatorischen und admi-nistrativen Maßnahmen ergriffen werden. Sicherheitsrelevante Updates oderPatches für die eingesetzte Hard- und Software müssen gegebenenfalls in-stalliert werden (siehe auch M 2.273 Zeitnahes Einspielen sicherheitsrelevan-ter Patches und Updates). Sind keine entsprechenden Updates oder Patchesverfügbar, so muss eventuell zusätzliche Sicherheitshardware bzw. Sicher-heitssoftware eingesetzt werden.

Es ist daher sehr wichtig, dass sich die Systemadministratoren regelmäßigüber neu bekannt gewordene Schwachstellen informieren. Informationsquel-len zu diesem Thema sind beispielsweise:

- Das Bundesamt für Sicherheit in der Informationstechnik (BSI) (siehehttp://www.bsi.bund.de/)

- Hersteller bzw. Distributoren von Programmen und Betriebssystemen.Diese informieren oft registrierte Kunden über bekannt gewordene Sicher-heitslücken ihrer Systeme und stellen korrigierte Varianten des Systemsoder Patches zur Behebung der Sicherheitslücken zur Verfügung.

- Computer Emergency Response Teams (CERTs).Dies sind Computer-Notfallteams, die als zentrale Anlaufstelle für präven-tive und reaktive Maßnahmen in bezug auf sicherheitsrelevante Vorfällein Computersystemen dienen. CERTs informieren in sogenannten Advi-sories über aktuelle Schwachstellen in Hard- und Softwareprodukten undgeben Empfehlungen zu deren Behebung. Verschiedene Organisationenoder Verbände unterhalten eigene CERTs.Das ursprüngliche CERT der Carnegie Mellon Universität diente als Vor-bild für viele weitere derartige Teams und ist heute eine Art "Dach-CERT":Computer Emergency Response Team / Coordination Center (CERT/CC),Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA15213-3890,Telefon: +1-412-268-7090 (24-Stunden-Hotline), E-Mail: [email protected],WWW: http://www.cert.orgDie CERT-Mitteilungen werden in Newsgruppen (comp.security.announceund info.nsfnet.cert) und über Mailinglisten (Aufnahme durch E-Mail an:[email protected]) veröffentlicht.In Deutschland existieren unter anderem folgende CERTs:

- CERT-Bund, Bundesamt für Sicherheit in der Informationstechnik,Postfach 20 03 63, D-53133 Bonn, Telefon: 0228 99-9582-222,Fax: 022899-9582-5427, E-Mail: [email protected], WWW: htt-ps://www.bsi.bund.de/certbund/

- DFN-CERT, Zentrum für sichere Netzdienste GmbH, Heidenkamps-weg 41, D-20097 Hamburg, Telefon: 040-808077-555, Fax: -556, E-Mail: [email protected], WWW: http://www.dfn-cert.de. Das DFN-CERTbietet verschiedene Mailinglisten an, siehe http://www.dfn-cert.de/info-serv/dml.html.

- An verschiedenen Hochschulen existieren CERTs, die auch Informationenöffentlich zur Verfügung stellen. Ein Beispiel ist das RUS-CERT der Uni-versität Stuttgart (siehe http://cert.uni-stuttgart.de).



- Hersteller- und systemspezifische sowie sicherheitsspezifische News-gruppen oder Mailinglisten. In solchen Foren werden Hinweise auf existie-rende oder vermutete Sicherheitslücken oder Fehler in diversen Betriebs-systemen und sonstigen Softwareprodukten diskutiert. Besonders aktuellsind meist die englischsprachigen Mailinglisten wie Bugtraq, von denen esan vielen Stellen öffentlich zugängliche Archive gibt, beispielsweise unterhttp://www.securityfocus.com.

- Manche IT-Fachzeitschriften veröffentlichen ebenfalls regelmäßig Beiträ-ge mit einer Übersicht über neue Sicherheitslücken in verschiedenen Pro-dukten.

Idealerweise sollten sich die Administratoren und der IT-Sicherheitsbeauftrag-te bei mindestens zwei verschiedenen Stellen über Sicherheitslücken infor-mieren. Dabei ist es empfehlenswert, neben den Informationen des Herstel-lers auch eine "unabhängige" Informationsquelle zu benutzen.

Die Administratoren sollten jedoch in jedem Fall auch produktspezifische Infor-mationsquellen des Herstellers nutzen, um beispielsweise darüber Bescheidzu wissen, ob für ein bestimmtes Produkt beim Bekanntwerden von Sicher-heitslücken überhaupt Patches oder Updates bereitgestellt werden. Bei Pro-dukten, für die der Hersteller keine Sicherheitspatches mehr zur Verfügungstellt, muss rechtzeitig geprüft werden, ob ein Einsatz unter diesen Umstän-den noch zu verantworten ist und durch welche zusätzlichen Maßnahmen einSchutz der betroffenen Systeme trotzdem gewährleistet werden kann.

Prüffragen:

- Informieren sich die Administratoren regelmäßig bei verschiedenenQuellen über neu bekannt gewordene Schwachstellen?

- Werden sicherheitsrelevante Updates zeitnah eingespielt?- Bei fehlenden Updates für bekannte Schwachstellen: Werden andere

technische oder organisatorische Maßnahmen ergriffen?



M 2.62 Software-Abnahme- undFreigabe-Verfahren

Verantwortlich für Initiierung: Leiter ITVerantwortlich für Umsetzung: Leiter IT

Der Einsatz von IT zur Aufgabenbewältigung setzt voraus, dass die maschi-nelle Datenverarbeitung soweit wie möglich fehlerfrei arbeitet, da die Kontrolleder Einzelergebnisse in den meisten Fällen nicht mehr zu leisten ist. Im Zugeeines Software-Abnahme-Verfahrens wird deshalb überprüft, ob die betrach-tete Software fehlerfrei arbeitet, das heißt, ob die Software die erforderlicheFunktionalität zuverlässig bereitstellt und ob sie darüber hinaus keine uner-wünschten Nebeneffekte hat. Mit der anschließenden Freigabe der Softwaredurch die fachlich zuständige Stelle wird die Erlaubnis erteilt, die Software zunutzen. Gleichzeitig übernimmt diese Stelle damit auch die Verantwortung fürdas IT-Verfahren, dass durch die Software realisiert wird.

Bei der Software-Abnahme unterscheidet man sinnvollerweise zwischen Soft-ware, die selbst oder im Auftrag entwickelt wurde, und Standardsoftware, dienur für den speziellen Einsatzzweck angepasst wird.

Abnahme von selbst- oder im Auftrag entwickelter Software

Bevor der Auftrag zur Software-Entwicklung intern oder extern vergeben wird,muss die Anforderungsdefinition für die Software erstellt sein, aus der danndas Grob- und Feinkonzept für die Realisierung entwickelt wird. Anhand die-ser Dokumente erstellt die fachlich zuständige Stelle, nicht die für die Softwa-re-Entwicklung zuständige Stelle, im allgemeinen einen Abnahmeplan.

Üblicherweise werden hierzu Testfälle und die erwarteten Ergebnisse für dieSoftware erarbeitet. Anhand dieser Testfälle wird die Software getestet undder Abgleich zwischen berechnetem und erwartetem Ergebnis wird als Indizfür die Korrektheit der Software benutzt.

Zur Entwicklung der Testfälle und zur Durchführung der Tests ist folgendeszu beachten:

- die Testfälle werden von der fachlich zuständigen Stelle entwickelt,- für Testfälle werden keine Daten des Wirkbetriebs benutzt,- Testdaten, insbesondere wenn sie durch Kopieren der Wirkdaten erstellt

werden, dürfen keine vertraulichen Informationen beinhalten; personen-bezogene Daten sind zu anonymisieren oder zu simulieren,

- die Durchführung der Tests darf keine Auswirkungen auf den Wirkbetriebhaben; nach Möglichkeit sollte ein logisch oder physikalisch isolierter Test-rechner benutzt werden.

Eine Abnahme ist zu verweigern, wenn:

- schwerwiegende Fehler in der Software festgestellt werden,- Testfälle auftreten, in denen die erwarteten Ergebnisse nicht mit den be-

rechneten übereinstimmen und- Benutzerhandbücher oder Bedienungsanleitungen nicht vorhanden oder

von nicht ausreichender Qualität sind unddie Software, unter anderem der Quellcode und die Abläufe, nicht oder

nicht ausreichend dokumentiert ist.



Die Ergebnisse der Abnahme sind schriftlich festzuhalten. Die Dokumentationdes Abnahmeergebnisses sollte umfassen:

- Bezeichnung und Versionsnummer der Software und gegebenenfalls desIT-Verfahrens,

- Beschreibung der Testumgebung,- Testfälle und Testergebnisse und- Abnahmeerklärung.

Abnahme von Standardsoftware

Wird Standardsoftware beschafft, so sollte auch diese einer Abnahme undeiner Freigabe unterzogen werden. In der Abnahme sollte überprüft werden,ob

- die Software frei von Computer-Viren ist,- die Software kompatibel zu den anderen eingesetzten Produkten ist,- die Software in der angestrebten Betriebsumgebung lauffähig ist und wel-

che Parameter zu setzen sind,- die Software komplett einschließlich der erforderlichen Handbücher aus-

geliefert wurde unddie geforderte Funktionalität erfüllt wird.

Freigabe-Verfahren

Ist die Abnahme der Software erfolgt, muss die Software für die Nutzung frei-gegeben werden. Dazu ist zunächst festzulegen, wer berechtigt ist, Softwarefreizugeben. Die Freigabe der Software ist schriftlich festzulegen und geeignetzu hinterlegen.

Die Freigabeerklärung sollte umfassen:

- Bezeichnung und Versionsnummer der Software und gegebenenfalls desIT-Verfahrens,

- Bestätigung, dass die Abnahme ordnungsgemäß vorgenommen wurde,- Einschränkungen für die Nutzung (Parametereinstellung, Benutzer-

kreis,...),- Freigabedatum, ab wann die Software eingesetzt werden darf unddie eigentliche Freigabeerklärung.

Falls IT-technisch möglich, muss verhindert werden, dass Software nach derFreigabe unbemerkt verändert oder manipuliert werden kann, beispielsweisedurch geeignete Verfahren zum Integritätsschutz. Andernfalls müssen geeig-nete organisatorische Regelungen festgelegt werden, um Änderungen an derSoftware zu verhindern bzw. zeitnah festzustellen.

Auch nach intensiven Abnahmetests kann es vorkommen, dass im laufendenEinsatz Fehler in der Software festgestellt werden. Für diesen Fall ist festzule-gen, wie in einem solchen Fehlerfall verfahren werden soll (Ansprechpartner,Fehlerbeseitigungsablauf, Beteiligung der fachlich zuständigen Stelle, Wieder-holung der Abnahme und Freigabe, Versionskontrolle).

Für weiterführende Erklärungen siehe Baustein B 1.10 Standardsoftware.

Prüffragen:

- Gibt es für sämtliche eingesetzte Software eine Abnahmebestätigung undeine Freigabeerklärung?

- Existiert ein Verfahren, welches die Fehlerbehebung während deslaufenden Einsatzes definiert?



M 2.64 Kontrolle der ProtokolldateienVerantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter ITVerantwortlich für Umsetzung: Revisor, Verantwortliche der einzelnen

Anwendungen

Die Protokollierung sicherheitsrelevanter Ereignisse ist als Sicherheitsmaß-nahme nur wirksam, wenn die protokollierten Daten in regelmäßigen Abstän-den durch einen Revisor ausgewertet werden. Ist es personell oder technischnicht möglich, die Rolle eines unabhängigen Revisors für Protokolldateien zuimplementieren, kann ihre Auswertung auch durch den Administrator erfolgen.Für diesen Fall bleibt zu beachten, dass damit eine Kontrolle der Tätigkeitendes Administrators nur schwer möglich ist. Das Ergebnis der Auswertung solltedaher dem IT-Sicherheitsbeauftragten, dem IT-Verantwortlichen oder einemanderen besonders zu bestimmenden Mitarbeiter vorgelegt werden.

Die regelmäßige Kontrolle dient darüber hinaus auch dem Zweck, durch dieanschließende Löschung der Protokolldaten ein übermäßiges Anwachsen derProtokolldateien zu verhindern. Je nach Art der Protokolldaten kann es sinnvollsein, diese auf externen Datenträgern zu archivieren.

Da Protokolldateien in den meisten Fällen personenbezogene Daten beinhal-ten, ist sicherzustellen, dass diese Daten nur zum Zweck der Datenschutzkon-trolle, der Datensicherung oder zur Sicherstellung eines ordnungsgemäßenBetriebes verwendet werden (siehe § 14 Abs. 4 BDSG und M 2.110 Daten-schutzaspekte bei der Protokollierung). Der Umfang der Protokollierung unddie Kriterien für deren Auswertung sollte dokumentiert und innerhalb der Or-ganisation abgestimmt werden.

Aus verschiedenen gesetzlichen Regelungen können sich einerseits Minde-staufbewahrungsfristen, aber andererseits auch Höchstaufbewahrungsfristenan Protokolldaten ergeben. So kann durch datenschutzrechtliche Regelungeneine Löschung erforderlich sein (siehe dazu auch M 2.110 Datenschutzaspek-te bei der Protokollierung).

Für bestimmte Protokolldaten gelten aber unter Umständen gesetzliche Min-destaufbewahrungsfristen, z. B. wenn sie Aufschluss über betriebswirtschaft-liche Vorgänge geben. Diese Fristen müssen auf jeden Fall eingehalten wer-den. Vor der Löschung von Protokolldaten ist daher sorgfältig zu prüfen, obentsprechende Rechtsvorschriften zu beachten sind und ggf. welche Aufbe-wahrungsfristen sich daraus ergeben. Hierbei sollte die Rechtsabteilung be-teiligt werden.

Die nachfolgenden Auswertungskriterien dienen als Beispiele, die Hinweiseauf eventuelle Sicherheitslücken, Manipulationsversuche und Unregelmäßig-keiten erkennen lassen:

- Liegen die Zeiten des An- und Abmeldens außerhalb der Arbeitszeit (Hin-weis auf Manipulationsversuche)?

- Häufen sich fehlerhafte Anmeldeversuche (Hinweis auf den Versuch,Passwörter zu erraten)?

- Häufen sich unzulässige Zugriffsversuche (Hinweis auf Versuche zur Ma-nipulation)?

- Gibt es auffällig große Zeitintervalle, in denen keine Protokolldaten aufge-zeichnet wurden (Hinweis auf eventuell gelöschte Protokollsätze)?

- Ist der Umfang der protokollierten Daten zu groß (eine umfangreiche Pro-tokolldatei erschwert das Auffinden von Unregelmäßigkeiten)?



- Gibt es auffällig große Zeitintervalle, in denen anscheinend kein Benut-zerwechsel stattgefunden hat (Hinweis darauf, dass das konsequente Ab-melden nach Arbeitsende nicht vollzogen wird)?

- Gibt es auffallend lange Verbindungszeiten in öffentliche Netze hinein (sie-he G 4.25 Nicht getrennte Verbindungen)?

- Wurde in einzelnen Netzsegmenten oder im gesamten Netz eine auffäl-lig hohe Netzlast oder eine Unterbrechung des Netzbetriebes festgestellt(Hinweis auf Versuche, die Dienste des Netzes zu verhindern bzw. zu be-einträchtigen oder auf eine ungeeignete Konzeption bzw. Konfigurationdes Netzes)?

Bei der Auswertung der Protokolldateien sollte besonderes Augenmerk aufalle Zugriffe gelegt werden, die unter Administratorkennungen durchgeführtwurden.

Wenn regelmäßig umfangreiche Protokolldateien ausgewertet werden müs-sen, ist es sinnvoll, ein Werkzeug zur Auswertung zu benutzen. Dieses Werk-zeug sollte wählbare Auswertungskriterien zulassen und besonders kritischeEinträge (z. B. mehrfacher fehlerhafter Anmeldeversuch) hervorheben.

Das oben Gesagte gilt analog auch für die Erhebung von Auditdaten, da essich dabei im Prinzip nur um die Protokollierung sicherheitskritischer Ereignis-se handelt.

Prüffragen:

- Gibt es einen Verantwortlichen für die Auswertung von Protokolldaten?- Werden die Ergebnisse der Auswertung dem IT-Sicherheitsbeauftragten

oder einem anderen hierfür bestimmten Mitarbeiter vorgelegt?- Existiert ein Konzept, das den Umfang und die Auswertung der

Protokollierung festlegt?- Werden die gesetzlichen Vorgaben in Bezug auf die Protokolldaten

eingehalten?



M 2.80 Erstellung einesAnforderungskatalogs fürStandardsoftware

Verantwortlich für Initiierung: Leiter FachabteilungVerantwortlich für Umsetzung: Fachabteilung, Leiter IT

Zur Lösung einer Aufgabe, die mit IT bearbeitet wird, bietet der Markt meisteine Vielzahl gleichartiger Standardsoftwareprodukte an. In ihrer Grundfunk-tionalität vergleichbar, unterscheiden sie sich jedoch in Kriterien wie Anschaf-fungs- und Betriebskosten, Zusatzfunktionalitäten, Kompatibilität, Administra-tion, Ergonomie und Informationssicherheit .

Anforderungskatalog

Für die Auswahl eines geeigneten Produktes muss daher zunächst ein Anfor-derungskatalog erstellt werden. Der Anforderungskatalog sollte unter ande-rem zu den folgenden Punkten Aussagen enthalten:

- Funktionale Anforderungen, die das Produkt zur Unterstützung der Auf-gabenerfüllung der Fachabteilung erfüllen muss. Die für die Fachaufgaberelevanten Einzelfunktionalitäten sollten hervorgehoben werden.Verkürzte Beispiele:

- Textverarbeitung mit den Zusatzfunktionen Einbinden von Grafiken,Makro-Programmierung, Rechtschreibprüfung und Silbentrennung.Makro-Programmierung muss abschaltbar sein, Rechtschreibprü-fung muss in Englisch, Französisch und Deutsch verfügbar sein. Diespezifizierten Textformate müssen im- und exportiert werden kön-nen.

- Datenbank (Front-End und Back-End) für Multi-User-Betrieb mit Un-terstützung der Standardabfragesprache SQL und grafischer Be-dienoberfläche

- Terminplaner zur Koordinierung und Kontrolle von Terminen der Ab-teilungsangehörigen mit integrierter Terminabstimmung, automati-schem Versand von Einladungen und Aufgaben- und Prioritäten-Li-sten, Schnittstelle zum hausinternen Mailprogramm

- IT-Einsatzumgebung, diese wird einerseits beschrieben durch die Rah-menbedingungen, die durch die vorhandene oder geplante IT-Einsatzum-gebung vorgegeben werden, und andererseits durch die Leistungsanfor-derungen, die durch das Produkt an die Einsatzumgebung vorgegebenwerden.Verkürztes Beispiel:

- Erforderliche IT-Einsatzumgebung und Leistungsanforderungen:Betriebssystem, Prozessor, Hauptspeicher, Festplattenkapazität,Schnittstellen für externe Datenträger und für Vernetzung

- Kompatibilitätsanforderungen zu anderen Programmen oder IT-Syste-men, also Migrationsunterstützung und Aufwärts- und Abwärtskompatibi-lität.Verkürzte Beispiele:

- Datenbestände aus der vorhandenen Datenbank XYZ müssen über-nommen werden können.

- Die Funktionen A, B, C müssen bei Versionswechseln erhalten blei-ben.

- Der Datenaustausch mit dem Unix-System XYZ muss möglich sein.



- Performanceanforderungen beschreiben die erforderlichen Leistungenhinsichtlich Durchsatz und Laufzeitverhalten. Für die geforderten Funktio-nen sollten möglichst genaue Angaben über die maximal zulässige Bear-beitungszeit getroffen werden.Verkürzte Beispiele:

- Die maximale Antwortzeit bei Ausführung von Funktion X darf 2 Se-kunden nicht überschreiten.

- Andere gleichzeitig verarbeitete Prozesse dürfen durch das Produktmaximal um 30% verlangsamt werden.

- Interoperabilitätsanforderungen, d. h. die Zusammenarbeit mit anderenProdukten über Plattformgrenzen hinweg muss möglich sein.Verkürzte Beispiele:

- Versionen des Textverarbeitungsprogramms sollen für Windows-,Unix- und MacOS-Plattformen verfügbar sein (in den zu benennen-den Versionen). Dokumente sollen auf einem Betriebssystem erstelltund auf einem anderen weiterverarbeitet werden können.

- Das Textverarbeitungsprogramm muss mit dem eingesetzten Mail-programm zusammenarbeiten können.

- Zuverlässigkeitsanforderungen betreffen die Stabilität des Produktes,also Fehlererkennung und Toleranz sowie Ausfall- und Betriebssicherheit.Verkürzte Beispiele:

- Fehleingaben des Benutzers müssen erkannt werden und dürfennicht zum Programmabbruch oder Systemabsturz führen.

- Die Datenbank muss über Mechanismen verfügen, die es erlauben,bei einem Systemabbruch mit Zerstörung der Datenbank alle Trans-aktionen zu rekonstruieren (Roll-Forward).

- Konformität zu Standards, dies können internationale Normen, De-fac-to-Standards oder auch Hausstandards sein.Verkürztes Beispiel:

- Das Produkt muss der EU-Bildschirmrichtlinie 90/270/EWG entspre-chen.

- Einhaltung von internen Regelungen und gesetzlichen Vorschriften(z. B. ausreichender Datenschutz bei der Verarbeitung personenbezoge-ner Daten)Verkürzte Beispiele:

- Das Produkt muss den Grundsätzen ordnungsmäßiger DV-gestütz-ter Buchführungssysteme genügen.

- Da personenbezogene Daten verarbeitet werden, müssen die Be-stimmungen des Bundesdatenschutzgesetzes mit den implemen-tierten Funktionen erfüllt werden können.

- Anforderungen an die Benutzerfreundlichkeit, die durch die leichte Be-dienbarkeit, Verständlichkeit und Erlernbarkeit gekennzeichnet ist, alsoinsbesondere durch die Güte der Benutzeroberfläche sowie die Qualitätder Benutzerdokumentation und der Hilfefunktionen.Verkürzte Beispiele:

- Eine Online-Hilfefunktion muss implementiert sein.- Die Benutzeroberfläche muss so gestaltet sein, dass ungelernte

Kräfte innerhalb von zwei Stunden in die Benutzung eingewiesenwerden können.

- Die Benutzerdokumentation und die Benutzeroberfläche sollten inder Landessprache vorliegen.



- Anforderungen an die Wartbarkeit ergeben sich für den Anwenderhauptsächlich aus der Fehlerbehandlung des Produktes.Verkürzte Beispiele:

- Der Administrationsaufwand darf nicht zu hoch sein.- Der Anbieter muss eine Hotline für Fragen anbieten.- Das Produkt muss einfach zu installieren und zu konfigurieren sein.- Das Produkt muss einfach zu deinstallieren sein.

- die Obergrenze der Kosten, die durch die Beschaffung dieses Produktesverursacht würden, werden vorgegeben. Dabei müssen nicht nur die un-mittelbaren Beschaffungskosten für das Produkt selber einbezogen wer-den, sondern auch Folgekosten, wie z. B. eine Aufrüstung der Hardware,Personalkosten oder notwendige Schulungen.Verkürzte Beispiele:

- Das Produkt darf maximal 15.000,- Euro kosten.- Die Schulungskosten dürfen 2.000,- Euro nicht überschreiten

- Aus den Anforderungen an die Dokumentation muss hervorgehen, wel-che Dokumente in welcher Güte (Vollständigkeit, Verständlichkeit) erfor-derlich sind.Verkürzte Beispiele:

- Die Benutzerdokumentation muss leicht nachvollziehbar und zumSelbststudium geeignet sein. Die gesamte Funktionalität des Pro-duktes ist zu beschreiben.

- Die Systemverwalterdokumentation muss Handlungsanweisungenfür mögliche Fehler enthalten.

- Bezüglich der Softwarequalität können Anforderungen gestellt werden,die von Herstellererklärungen zum eingesetzten Qualitätssicherungsver-fahren, über ISO 9000 ff. Zertifikate bis hin zu unabhängigen Softwareprü-fungen nach ISO/IEC 25051 reichen.Verkürzte Beispiele:

- Der Software-Herstellungsprozess des Herstellers muss nach ISO9000 zertifiziert sein.

- Die Funktionalität des Produktes muss unabhängig gemäß ISO/IEC25051 überprüft worden sein.

- Sollen durch das Produkt Sicherheitsfunktionen erfüllt werden, sind sie inForm von Sicherheitsanforderungen zu formulieren (siehe M 4.42 Im-plementierung von Sicherheitsfunktionalitäten in der IT-Anwendung). Dieswird nachfolgend noch ausführlich erläutert.

Sicherheitsanforderungen

Abhängig davon, ob das Produkt Sicherheitseigenschaften bereitstellen muss,können im Anforderungskatalog Sicherheitsfunktionen aufgeführt werden. Ty-pische Sicherheitsfunktionen, die hier in Frage kommen, seien kurz erläutert.Weitere Ausführungen findet man in den Common Criteria (den "Gemeinsa-men Kriterien für die Prüfung und Bewertung der Sicherheit von Informations-technik").

- Identifizierung und AuthentisierungIn vielen Produkten wird es Anforderungen geben, diejenigen Benutzerzu bestimmen und zu überwachen, die Zugriff auf Betriebsmittel haben,die vom Produkt kontrolliert werden. Dazu muss nicht nur die behaupteteIdentität des Benutzers festgestellt, sondern auch die Tatsache nachge-prüft werden, dass der Benutzer tatsächlich die Person ist, die er zu seinvorgibt. Dies geschieht, indem der Benutzer dem Produkt Informationenliefert, die fest mit dem betreffenden Benutzer verknüpft sind.



- ZugriffskontrolleBei vielen Produkten wird es erforderlich sein sicherzustellen, dass Be-nutzer und Prozesse, die für diese Benutzer tätig sind, daran gehindertwerden, Zugriff auf Informationen oder Betriebsmittel zu erhalten, für diesie kein Zugriffsrecht haben oder für die keine Notwendigkeit zu einemZugriff besteht. Desgleichen wird es Anforderungen bezüglich der unbe-fugten Erzeugung oder Änderung (einschließlich Löschung) von Informa-tionen geben.

- BeweissicherungBei vielen Produkten wird es erforderlich sein sicherzustellen, dass überHandlungen, die von Benutzern bzw. von Prozessen im Namen solcherBenutzer ausgeführt werden, Informationen aufgezeichnet werden, damitdie Folgen solcher Handlungen später dem betreffenden Benutzer zuge-ordnet werden können und der Benutzer für seine Handlungen verantwort-lich gemacht werden kann.

- ProtokollauswertungBei vielen Produkten wird sicherzustellen sein, dass sowohl über gewöhn-liche Vorgänge als auch über außergewöhnliche Vorfälle ausreichend In-formationen aufgezeichnet werden, damit durch Nachprüfungen späterfestgestellt werden kann, ob tatsächlich Sicherheitsverletzungen vorgele-gen haben und welche Informationen oder sonstigen Betriebsmittel davonbetroffen waren.

- UnverfälschbarkeitBei vielen Produkten wird es erforderlich sein sicherzustellen, dass be-stimmte Beziehungen zwischen unterschiedlichen Daten korrekt bleibenund dass Daten zwischen einzelnen Prozessen ohne Änderungen über-tragen werden.Daneben müssen auch Funktionen bereitgestellt werden, die es bei derÜbertragung von Daten zwischen einzelnen Prozessen, Benutzern undObjekten ermöglichen, Verluste, Ergänzungen oder Veränderungen zuentdecken bzw. zu verhindern, und die es unmöglich machen, die angeb-liche oder tatsächliche Herkunft bzw. Bestimmung der Datenübertragungzu ändern.

- ZuverlässigkeitBei vielen Produkten wird es erforderlich sein sicherzustellen, dass zeit-kritische Aufgaben genau zu dem Zeitpunkt durchgeführt werden, zu demes erforderlich ist, also nicht früher oder später, und es wird sicherzustel-len sein, dass zeitunkritische Aufgaben nicht in zeitkritische umgewandeltwerden können. Desgleichen wird es bei vielen Produkten erforderlich seinsicherzustellen, dass ein Zugriff in dem erforderlichen Moment möglich istund Betriebsmittel nicht unnötig angefordert oder zurückgehalten werden.

- ÜbertragungssicherungDieser Begriff umfasst alle Funktionen, die für den Schutz der Daten wäh-rend der Übertragung über Kommunikationskanäle vorgesehen sind:

- Authentisierung- Zugriffskontrolle- Datenvertraulichkeit- Datenintegrität- Sende- und Empfangsnachweis

Einige dieser Funktionen werden mittels kryptographischer Verfahren rea-lisiert.

Darüber hinaus können weitere Sicherheitsanforderungen an Standardsoft-ware konkretisiert werden.

- Datensicherung



An die Verfügbarkeit der mit dem Produkt verarbeiteten Daten werden ho-he Anforderungen gestellt. Unter diesen Punkt fallen im Produkt integrier-te Funktionen, die Datenverlusten vorbeugen sollen wie die automatischeSpeicherung von Zwischenergebnissen oder die automatische Erstellungvon Sicherungskopien vor der Durchführung größerer Änderungen.

- VerschlüsselungVerschlüsselung dient der Wahrung der Vertraulichkeit von Daten. Bei vie-len Produkten wird es erforderlich sein, Nutzdaten vor einer Übertragungoder nach der Bearbeitung zu verschlüsseln und sie nach Empfang odervor der Weiterverarbeitung zu entschlüsseln. Hierzu ist ein anerkanntesVerschlüsselungsverfahren zu verwenden. Es ist sicherzustellen, dass diezur Entschlüsselung benötigten Parameter (z. B. Schlüssel) in der Weisegeschützt sind, dass kein Unbefugter Zugang zu diesen Daten besitzt.

- Funktionen zur Wahrung der DatenintegritätFür Daten, deren Integritätsverlust zu Schäden führen kann, können Funk-tionen eingesetzt werden, die Fehler erkennen lassen oder sogar mittelsRedundanz korrigieren können. Meist werden Verfahren zur Integritäts-prüfung eingesetzt, die absichtliche Manipulationen am Produkt bzw. dendamit erstellten Daten sowie ein unbefugtes Wiedereinspielen von Datenzuverlässig aufdecken können. Sie basieren auf kryptographischen Ver-fahren (siehe M 4.34 Einsatz von Verschlüsselung, Checksummen oderDigitalen Signaturen).

- Datenschutzrechtliche AnforderungenWenn mit dem Produkt personenbezogene Daten verarbeitet werden sol-len, sind über die genannten Sicherheitsfunktionen hinaus zusätzlichespezielle technische Anforderungen zu stellen, um den Datenschutzbe-stimmungen genügen zu können.

Stärke der Mechanismen / Angriffsresistenz

Sicherheitsfunktionen werden durch Mechanismen umgesetzt. Je nach Ein-satzzweck müssen diese Mechanismen eine unterschiedliche Stärke besit-zen, mit der sie Angriffe abwehren können. Die erforderliche Stärke der Me-chanismen ist im Anforderungskatalog anzugeben. Bei Anwendung der Com-mon Criteria (CC) wird die Angriffsresistenz eines IT-Produktes, das in einerbestimmten Einsatzumgebung betrieben wird, an den in den Sicherheitsvor-gaben oder gegebenenfalls in einem Schutzprofil definierten Bedrohungen derzu schützenden Datenobjekte und der für die Evaluierung angesetzten Prüf-tiefe bewertet. Die geforderte Prüftiefe beinhaltet die Festlegung der Angriffs-resistenz und richtet sich nach dem Schutzbedarf und dem Einsatzzweck desProduktes. Die Prüftiefe wird anhand eines Kataloges (siehe CC, Teil 3) meistmittels vordefinierter Evaluierungsstufen (EAL 1 bis 7) festgelegt.

Für die Bewertung der Angriffsresistenz werden die für das Einsatzszenariorelevanten Angriffe nach dem Stand der Technik bis zu einer bestimmten Stär-ke unter Berücksichtigung der erforderlichen Angriffszeit, technischen Exper-tise des Angreifers, Kenntnissen über das Produkt, Gelegenheit zum Angriffund benötigten Hilfsmittel analysiert. Die Bestätigung der Angriffsresistenz imRahmen der Zertifizierung erfolgt dabei dann in den Abstufungen niedrig (ba-sic), erweitert (enhanced basic), mittel (moderate) und hoch (high).

Basic bedeutet Schutz gegen öffentlich bekannte Angriffe und gegen Angrei-fer mit sehr begrenzten Fähigkeiten und Möglichkeiten. Hoch bedeutet, dassein erfolgreicher Angriff sehr gute Fachkenntnisse, Produktkenntnisse, Gele-genheiten und Betriebsmittel erfordert, und damit insgesamt als extrem auf-wändig gilt.



Beispiele für Anforderungen zu Sicherheitseigenschaften

Nachfolgend werden für einige wichtige Sicherheitsfunktionen Beispiele ge-nannt, aus denen typische Anforderungen an Sicherheitseigenschaften deut-lich werden.

Soll das Produkt über einen Identifizierungs- und Authentisierungsme-chanismus verfügen, können beispielsweise folgende Anforderungen gestelltwerden:

- Der Zugang darf ausschließlich über eine definierte Schnittstelle erfolgen.Dabei kann z. B. ein Anmeldemechanismus zum Einsatz kommen, der ei-ne eindeutige Benutzer-Kennung und ein Passwort verlangt. Wird beimZugang zum IT-System bereits die Identität des Benutzers sichergestellt,ist eine anonyme Passworteingabe ausreichend. Andere Möglichkeitensind Verfahren, die auf dem Besitz bestimmter "Token" beruhen, wie z. B.einer Chipkarte.

- Das Zugangsverfahren selbst muss die sicherheitskritischen Parameter,wie Passwort, Benutzer-Kennung, usw., sicher verwalten. So dürfen aktu-elle Passwörter nie unverschlüsselt auf den entsprechenden IT-Systemengespeichert werden.

- Das Zugangsverfahren muss definiert auf Fehleingaben reagieren. Erfolgtzum Beispiel dreimal hintereinander eine fehlerhafte Authentisierung, istder Zugang zum Produkt zu verwehren oder alternativ sind die zeitlichenAbstände, nach denen ein weiterer Zugangsversuch erlaubt wird, sukzes-siv zu vergrößern.

- Das Zugangsverfahren muss das Setzen bestimmter Minimalvorgaben fürdie sicherheitskritischen Parameter zulassen. So sollte die Mindestlängeeines Passwortes acht Zeichen, die Mindestlänge einer PIN vier Ziffernbetragen. Auch die Komplexität für Passwörter sollte vorgegeben werden.

Soll das Produkt über eine Zugriffskontrolle verfügen, können beispielsweisefolgende Anforderungen gestellt werden:

- Das Produkt muss verschiedene Benutzer unterscheiden können.- Das Produkt muss je nach Vorgabe Ressourcen einzelnen autorisierten

Benutzer zuteilen können und Unberechtigten den Zugriff gänzlich ver-wehren

- Mittels einer differenzierten Rechtestruktur (lesen, schreiben, ausführen,ändern, ...) sollte der Zugriff geregelt werden können. Die für die Rech-teverwaltung relevanten Daten sind manipulationssicher vom Produkt zuverwalten.

Soll das Produkt über eine Protokollierung verfügen, können folgende An-forderungen sinnvoll sein:

- Der Mindestumfang, den das Produkt protokollieren können muss, sollteparametrisierbar sein. Beispielsweise sollten folgende Aktionen protokol-lierbar sein:

- bei Authentisierung: Benutzer-Kennung, Datum und Uhrzeit, Er-folg, ...,

- bei der Zugriffskontrolle: Benutzer-Kennung, Datum und Uhrzeit, Er-folg, Art des Zugriffs, was wurde wie geändert, gelesen, geschrie-ben, ...

- Durchführung von Administratortätigkeiten,- Auftreten von funktionalen Fehlern.

- Die Protokollierung darf von Unberechtigten nicht deaktivierbar sein. DieProtokolle selbst dürfen für Unberechtigte weder lesbar noch modifizierbarsein.



- Die Protokollierung muss übersichtlich, vollständig und korrekt sein.

Soll das Produkt über eine Protokollauswertung verfügen, können folgendeAnforderungen sinnvoll sein:

- Eine Auswertefunktion muss nach den bei der Protokollierung gefordertenDatenarten unterscheiden können (z. B. "Filtern aller unberechtigten Zu-griffe auf alle Ressourcen in einem vorgegebenen Zeitraum").

- Die Auswertefunktion muss auswertbare ("lesbare") Berichte erzeugen, sodass keine sicherheitskritischen Aktivitäten übersehen werden.

Soll das Produkt über Funktionen zur Unverfälschbarkeit verfügen, könntebeispielsweise folgende Anforderung gestellt werden:

- Ein Datenbank-Managementsystem muss über Möglichkeiten zur Be-schreibung von Regeln bestimmter Beziehungen zwischen den gespei-cherten Daten verfügen (z. B. referentielle Integrität). Außerdem müssengeeignete Mechanismen existieren, die verhindern, dass es durch Ände-rungen der Daten zu Verstößen gegen diese Regeln kommt.

Soll das Produkt über Funktionen zur Datensicherung verfügen, können bei-spielsweise folgende Anforderungen gestellt werden:

- Es muss konfigurierbar sein, welche Daten wann gesichert werden.- Es muss eine Option zum Einspielen beliebiger Datensicherungen existie-

ren.- Die Funktion muss das Sichern von mehreren Generationen ermöglichen.- Datensicherungen von Zwischenergebnissen aus der laufenden Anwen-

dung sollen möglich sein.

Soll das Produkt über eine Verschlüsselungskomponente verfügen, sindfolgende Anforderungen sinnvoll:

- Der implementierte Verschlüsselungsalgorithmus sollte dem Schutzbedarfentsprechen und eine ausreichende Mechanismenstärke besitzen (sieheauch M 2.164 Auswahl eines geeigneten kryptographischen Verfahrens).

- Das Schlüsselmanagement muss mit der Funktionalität des Produktesharmonieren. Dabei sind insbesondere grundsätzliche Unterschiede derAlgorithmen zu berücksichtigen:

- symmetrische Verfahren benutzen einen geheim zu haltendenSchlüssel für die Ver- und Entschlüsselung,

- asymmetrische Verfahren benutzen einen öffentlichen Schlüssel fürdie Verschlüsselung und einen privaten (geheim zu haltenden) fürdie Entschlüsselung.

- Das Produkt muss die sicherheitskritischen Parameter wie Schlüssel si-cher verwalten. So dürfen Schlüssel (auch mittlerweile nicht mehr benutz-te) nie ungeschützt, das heißt auslesbar, auf den entsprechenden IT-Sy-stemen abgelegt werden.

Soll das Produkt über Mechanismen zur Integritätsprüfung verfügen, sindfolgende Anforderungen sinnvoll:

- Das Produkt führt bei jedem Programmaufruf einen Integritätscheck durch.- Bei der Datenübertragung müssen Mechanismen eingesetzt werden, mit

denen absichtliche Manipulationen an den Adressfeldern und den Nutz-daten erkannt werden können. Daneben darf die bloße Kenntnis der ein-gesetzten Algorithmen ohne spezielle Zusatzkenntnisse nicht ausreichen,unerkannte Manipulationen an den obengenannten Daten vorzunehmen.



Werden personenbezogene Daten mit dem Produkt verarbeitet, können bei-spielsweise folgende datenschutzrechtlichen Anforderungen gestellt wer-den:

- Das Produkt darf keine freie Abfrage für Datenauswertungen zulassen.Die Auswertungen von Datensätzen müssen auf bestimmte Kriterien ein-schränkbar sein.

- Es muss parametrisierbar sein, dass für bestimmte Dateien Änderungen,Löschungen oder Ausdrucke von personenbezogenen Daten nur nachdem Vier-Augen-Prinzip möglich sind.

- Die Protokollierung muss parametrisierbar sein, so dass aufgezeichnetwerden kann, wer wann an welchen personenbezogenen Daten welcheÄnderungen vorgenommen hat.

- Die Übermittlung personenbezogener Daten muss durch geeignete Stich-probenverfahren festgestellt und überprüft werden können (BDSG, § 10).Die Art der Stichprobe muss sich individuell einstellen lassen.

- Das Produkt muss das Löschen von personenbezogenen Daten ermögli-chen. Ersatzweise muss das Sperren personenbezogener Daten möglichsein, um ihre weitere Verarbeitung oder Nutzung einzuschränken bzw. zuverhindern.

Bewertungsskala

Um einen Vergleich verschiedener Produkte im Sinne einer Nutzwertanalysedurchführen zu können, müssen Kriterien vorhanden sein, wie die Erfüllungder einzelnen Anforderungen gewertet wird. Dazu ist es erforderlich, vorabdie Bedeutung der einzelnen Anforderungen für die angestrebte IT-gestützteAufgabenerfüllung quantitativ oder qualitativ zu bewerten.

Diese Bewertung kann beispielsweise in drei Stufen vorgenommen werden.In der ersten Stufe wird festgelegt, welche im Anforderungskatalog geforder-ten Eigenschaften notwendig und welche wünschenswert sind. Wenn einenotwendige Eigenschaft nicht erfüllt ist, wird das Produkt abgelehnt (so ge-nanntes K.O.-Kriterium). Das Fehlen einer wünschenswerten Eigenschaft wirdzwar negativ gewertet, dennoch wird aber das Produkt aufgrund dessen nichtzwingend abgelehnt.

Als zweite Stufe wird die Bedeutung der geforderten wünschenswerten Ei-genschaft für die Aufgabenerfüllung angegeben. Dies kann z. B. quantitativmit Werten zwischen 1 für niedrig und 5 für hoch erfolgen. Notwendige Eigen-schaften müssen nicht quantitativ bewertet werden. Ist dies aber aus rechneri-schen Gründen erforderlich, müssen sie auf jeden Fall höher bewertet werdenals jede wünschenswerte Eigenschaft (um die Bedeutung einer notwendigenEigenschaft hervorzuheben, kann sie z. B. mit 10 bewertet werden).

In der dritten Stufe wird ein Vertrauensanspruch für die Korrektheit der gefor-derten Eigenschaften für die Aufgabenerfüllung angegeben (z. B. mit Wertenzwischen 1 für niedrig und 5 für hoch). Anhand des Vertrauensanspruchs wirdspäter entschieden, wie eingehend die Eigenschaft getestet wird. Der Vertrau-ensanspruch der Sicherheitsmechanismen muss entsprechend ihrer Mecha-nismenstärke bewertet werden, beispielsweise kombiniert man

- Mechanismenstärke niedrig mit Vertrauensanspruch 1- Mechanismenstärke mittel mit Vertrauensanspruch 3- Mechanismenstärke hoch mit Vertrauensanspruch 5

Diese Orientierungswerte müssen im Einzelfall verifiziert werden.



Beispiele:

Auszugsweise sollen für einige typische Standardsoftwareprodukte Sicher-heitsanforderungen erläutert werden:

Textverarbeitungsprogramm:

Notwendige Sicherheitseigenschaften:

- Automatische Datensicherung von Zwischenergebnissen im laufendenBetrieb

Wünschenswerte Sicherheitseigenschaften:

- Passwortschutz einzelner Dateien- Verschlüsselung einzelner Dateien- Makro-Programmierung muss abschaltbar sein

Dateikompressionsprogramm:


- Im Sinne der Datensicherung dürfen nach Kompression zu löschende Da-teien erst dann vom Kompressionsprogramm gelöscht werden, wenn dieKompression fehlerfrei abgeschlossen wurde.

- Vor der Dekomprimierung einer Datei muss deren Integrität überprüft wer-den, damit z. B. Bitfehler in der komprimierten Datei erkannt werden.


- Passwortschutz komprimierter Dateien

Terminplaner:


- Eine sichere Identifikation und Authentisierung der einzelnen Benutzermuss erzwungen werden, z. B. über Passwörter.

- Eine Zugriffskontrolle für die Terminpläne der einzelnen Mitarbeiter ist er-forderlich.

- Zugriffsrechte müssen für Einzelne, Gruppen und Vorgesetzte getrenntvergeben werden können.

- Eine Unterscheidung zwischen Lese- und Schreibrecht muss möglichsein.


- Eine automatisierte Datensicherung in verschlüsselter Form ist vorzuse-hen.

Reisekostenabrechnungssystem:


- Eine sichere Identifikation und Authentisierung der einzelnen Benutzermuss erzwungen werden, z. B. über Passwörter.

- Eine Zugriffskontrolle muss vorhanden und auch für einzelne Datensätzeeinsetzbar sein.

- Zugriffsrechte müssen für Benutzer, Administrator, Revisor und Daten-schutzbeauftragten getrennt vergeben werden können. Eine Rollentren-nung zwischen Administrator und Revisor muss durchführbar sein.

- Datensicherungen müssen so durchgeführt werden können, dass sie ver-schlüsselt abgelegt werden und nur von Berechtigten wiedereingespieltwerden können.

- Detaillierte Protokollierungsfunktionen müssen verfügbar sein.




- Ein optionaler Integritätscheck für zahlungsrelevante Daten sollte angebo-ten werden.

Beispiel für eine Bewertungsskala:

Eine Fachabteilung will für Datensicherungszwecke ein Komprimierungspro-gramm beschaffen. Nach der Erstellung eines Anforderungskataloges könn-ten die dort spezifizierten Eigenschaften wie folgt bewertet werden:Eigenschaft notwendig wünschens-

wertBedeutung Vertrauens-

anspruch

korrekte Kom-pression undDekompressi-on

X 10 5

Erkennen vonBitfehlern ineiner kompri-mierten Datei

X 10 2

Löschung vonDateien nurnach erfolg-reicher Kom-pression

X 10 3

Windows-PC,x86, 256 MB

X 10 5

Linux-tauglich X 2 1

Durchsatz bei1 GHz über 10MB/s

X 4 3

Kompressi-onsrate über40% bei Text-dateien desProgrammsXYZ

X 4 3

Online-Hilfe-funktion

X 3 1

Maximale Ko-sten 50.- Europro Lizenz

X 10 5

Passwort-schutz fürkomprimierteDateien (Me-chanismen-stärke hoch)

X 2 5

Prüffragen:

- Wird für die Auswahl von einzusetzenden Software-Produkten einAnforderungskatalog erstellt, der Sicherheitsanforderungen umfasst?



- Wurde eine Bewertungsskala zu den einzelnen Anforderungen anSoftware-Produkte erstellt, um die Produkte vergleichen zu können?



M 2.110 Datenschutzaspekte bei derProtokollierung

Verantwortlich für Initiierung: Leiter ITVerantwortlich für Umsetzung: Administrator

Unter Protokollierung beim Betrieb von IT-Systemen ist im datenschutzrecht-lichen Sinn die Erstellung von manuellen oder automatisierten Aufzeichnun-gen zu verstehen, aus denen sich die Fragen beantworten lassen: "Wer hatwann mit welchen Mitteln was veranlasst bzw. worauf zugegriffen?" Außerdemmüssen sich Systemzustände ableiten lassen: "Wer hatte von wann bis wannwelche Zugriffsrechte?"

Art und Umfang von Protokollierungen hängen vom allgemeinen Datenschutz-recht und auch von bereichsspezifischen Regelungen ab.

Die Protokollierung der Administrationsaktivitäten entspricht einer System-überwachung, während die Protokollierung der Benutzeraktivitäten im wesent-lichen der Verfahrensüberwachung dient. Dementsprechend finden sich dieAnforderungen an die Art und den Umfang der systemorientierten Protokollie-rung überwiegend im allgemeinen Datenschutzrecht, während die verfahrens-orientierte Protokollierung oft durch bereichsspezifische Regelungen definiertwird. Beispiele für verfahrensorientierte Protokollierung sind u. a. Meldegeset-ze, Polizeigesetze, Verfassungsschutzgesetze.

Mindestanforderungen an die Protokollierung

Bei der Administration von IT-Systemen sind die folgenden Aktivitäten voll-ständig zu protokollieren:

- Systemgenerierung und Modifikation von SystemparameternDa auf dieser Ebene in der Regel keine systemgesteuerten Protokolle er-zeugt werden, bedarf es entsprechender detaillierter manueller Aufzeich-nungen, die mit der Systemdokumentation korrespondieren sollten.

- Einrichten von BenutzernWem von wann bis wann durch wen das Recht eingeräumt worden ist, dasbetreffende IT-System zu benutzen, ist vollständig zu protokollieren. Fürdiese Protokolle sollten längerfristige Aufbewahrungszeiträume vorgese-hen werden, da sie Grundlage praktisch jeder Revisionsmaßnahme sind.

- Erstellung von RechteprofilenIm Rahmen der Protokollierung der Benutzerverwaltung kommt es insbe-sondere auch darauf an aufzuzeichnen, wer die Anweisung zur Einrich-tung bestimmter Benutzerrechte erteilt hat (siehe auch M 2.31 Dokumen-tation der zugelassenen Benutzer und Rechteprofile).

- Einspielen und Änderung von AnwendungssoftwareDie Protokolle repräsentieren das Ergebnis der Programm- und Verfah-rensfreigaben.

- Änderungen an der DateiorganisationIm Hinblick auf die vielfältigen Manipulationsmöglichkeiten, die sich bereitsbei Benutzung der "Standard-Dateiverwaltungssysteme" ergeben, kommteiner vollständigen Protokollierung eine besondere Bedeutung zu (siehez. B. Datenbankmanagement).

- Durchführung von DatensicherungsmaßnahmenDa derartige Maßnahmen (Backup, Restore) mit der Anfertigung von Ko-pien bzw. dem Überschreiben von Datenbeständen verbunden sind undhäufig in "Ausnahmesituationen" durchgeführt werden, besteht eine er-höhte Notwendigkeit zur Protokollierung.



- Sonstiger Aufruf von Administrations-ToolsDie Benutzung aller Administrations-Tools ist zu protokollieren, um fest-stellen zu können, ob Unbefugte sich Systemadministrator-Rechte erschli-chen haben.

- Versuche unbefugten Einloggens und Überschreitung von Befugnis-senGeht man von einer wirksamen Authentisierungsprozedur und sachge-rechten Befugniszuweisungen aus, kommt der vollständigen Protokollie-rung aller "auffälligen Abnormalitäten" beim Einloggen und der Benutzungvon Hard- und Software-Komponenten eine zentrale Bedeutung zu. Be-nutzer in diesem Sinne ist auch der Systemadministrator.

Bei der Verarbeitung von personenbezogenen Daten sind folgende Benut-zeraktivitäten in Abhängigkeit von der Sensibilität der Verfahren bzw. Datenvollständig bzw. selektiv zu protokollieren:

- Eingabe von DatenDie so genannte Eingabekontrolle erfolgt grundsätzlich verfahrensorien-tiert (z. B. Protokollierung in Akten, soweit vorhanden, Protokollierung di-rekt im Datenbestand, sofern keine Akten geführt werden). Auch wennman davon ausgeht, dass Befugnisüberschreitungen anderweitig proto-kolliert werden, sollte eine vollständige Protokollierung von Dateneinga-ben als Regelfall angesehen werden.

- DatenübermittlungenNur soweit nicht gesetzlich eine vollständige Protokollierung vorgeschrie-ben ist, kann eine selektive Protokollierung als ausreichend angesehenwerden.

- Benutzung von automatisierten AbrufverfahrenIn der Regel dürfte eine vollständige Protokollierung der Abrufe und derGründe der Abrufe (Vorgang, Aktenzeichen etc.) erforderlich sein, um un-befugte Kenntnisnahme im Rahmen der grundsätzlich eingeräumten Zu-griffsrechte aufdecken zu können.

- Löschung von DatenDie Durchführung der Löschung ist zu protokollieren.

- Aufruf von ProgrammenDies kann erforderlich sein bei besonders "sensiblen" Programmen, diez. B. nur zu bestimmten Zeiten oder Anlässen benutzt werden dürfen. Des-halb ist in diesen Fällen eine vollständige Protokollierung angezeigt. DieProtokollierung dient auch der Entlastung der befugten Benutzer (Nach-weis des ausschließlich befugten Aufrufs der Programme).

Zweckbindung bei der Nutzung von Protokolldaten

Protokolldaten unterliegen aufgrund der nahezu übereinstimmenden Regelun-gen im Datenschutzrecht des Bundes und der Länder einer besonderen engenZweckbindung. Sie dürfen nur zu den Zwecken genutzt werden, die Anlass fürihre Speicherung waren. Dies sind in der Regel die in einem Sicherheitskon-zept festgelegten allgemeinen Kontrollen, die in den meisten Datenschutzge-setzen geforderte Überwachung der ordnungsgemäßen Anwendung der Da-tenverarbeitungsprogramme, mit denen personenbezogene Daten verarbeitetwerden und die Kontrollen durch interne oder externe Datenschutzbeauftrag-te. Nur in Ausnahmefällen lassen die bereichsspezifischen Regelungen dieNutzung dieser Daten für andere Zwecke, z. B. zur Strafverfolgung, zu.

Aufbewahrungsdauer

Soweit nicht bereichsspezifische Regelungen etwas anderes vorsehen, rich-tet sich die Aufbewahrungsdauer der Protokolle nach den allgemeinen Lö-schungsregeln der Datenschutzgesetze. Protokolldaten sind unverzüglich zu



löschen, wenn sie zur Erreichung des Zwecks nicht mehr erforderlich sind.Gibt es keinen zwingenden Grund für das weitere Vorhalten von Protokollda-teien, besteht eine Löschungspflicht.

Als Anhaltspunkte können dienen:

- die Wahrscheinlichkeit, dass Unregelmäßigkeiten (noch) offenbar werdenkönnen und

- die Möglichkeit, die Gründe von Unregelmäßigkeiten anhand der Proto-kolle und anderer Unterlagen aufdecken zu können.

Erfahrungsgemäß sollte eine Frist von einem Jahr nicht überschritten werden.

Soweit Protokolle zum Zwecke gezielter Kontrollen angefertigt werden, kom-men kürzere Speicherungsfristen in Betracht. In der Regel reicht eine Aufbe-wahrung bis zur tatsächlichen Kontrolle aus. Auch hier sind die bereichsspe-zifischen Vorschriften zu beachten.

Technische und organisatorische Rahmenbedingungen

Die Effektivität der Protokollierung und ihre Auswertung im Rahmen von Kon-trollen hängt im entscheidenden Maße von den technischen und organisato-rischen Rahmenbedingungen ab. In diesem Zusammenhang sollten folgendeAspekte Berücksichtigung finden:

- Es sollte ein Konzept erstellt werden, das den Zweck der Protokolle undderen Kontrollen sowie Schutzmechanismen für die Rechte der Mitar-beiter und der sonstigen betroffenen Personen klar definiert (siehe auchB 5.22 Protokollierung).

- Die Zwangsläufigkeit und damit die Vollständigkeit der Protokolle mussebenso gewährleistet werden wie die Manipulationssicherheit der Einträgein Protokolldateien.

- Entsprechend der Zweckbindung der Datenbestände müssen wirksameZugriffsbeschränkungen realisiert werden.

- Die Protokolle müssen so gestaltet sein, dass eine effektive Überprüfungmöglich ist. Dazu gehört auch eine IT-Unterstützung der Auswertung.

- Die Auswertungsmöglichkeiten sollten vorab abgestimmt und festgelegtsein.

- Kontrollen sollten so zeitnah durchgeführt werden, dass bei aufgedeck-ten Verstößen noch Schäden abgewendet sowie Konsequenzen gezogenwerden können. Kontrollen müssen rechtzeitig vor dem Ablauf von Lö-schungsfristen von Protokolldateien stattfinden.

- Kontrollen sollten nach dem Vier-Augen-Prinzip erfolgen.- Die Mitarbeiter sollten darüber informiert sein, dass Kontrollen durchge-

führt werden, ggf. auch unangekündigt.- Für Routinekontrollen sollten automatisierte Verfahren (z. B. watch dogs)

verwendet werden.- Personal- bzw. Betriebsräte sollten bei der Erarbeitung des Protokollie-

rungskonzeptes und bei der Festlegung der Auswertungsmöglichkeitender Protokolle beteiligt werden.

Prüffragen:

- Wurde ein Konzept erstellt, das den Zweck der Protokollierung, derenKontrollen sowie Schutzmechanismen für die Rechte der betroffenenPersonen beschreibt?

- Wird die Zweckbindung der Protokolldaten beachtet, insbesondere beiden Zugriffsregelungen?

- Lässt die Form der Protokollierung effektive Auswertungsmöglichkeitenzu?



- Wurden die Auswertungsmöglichkeiten mit dem Datenschutzbeauftragtenund der Personalvertretung abgestimmt?



M 2.273 Zeitnahes Einspielensicherheitsrelevanter Patchesund Updates

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter ITVerantwortlich für Umsetzung: Administrator, IT-Sicherheitsbeauftragter

Häufig werden Fehler in Produkten bekannt, die dazu führen können, dass dieInformationssicherheit des Informationsverbundes, wo diese betrieben wer-den, beeinträchtigt wird. Entsprechende Fehler können Hardware, Firmware,Betriebssysteme und Anwendungen betreffen. Diese Schwachstellen müssenso schnell wie möglich behoben werden, damit sie nicht durch interne oderexterne Angreifer ausgenutzt werden können. Dies ist ganz besonders wich-tig, wenn die betreffenden Systeme mit dem Internet verbunden sind. Die Her-steller von Betriebssystem- oder Software-Komponenten veröffentlichen in derRegel Patches oder Updates, die auf dem jeweiligen IT-System installiert wer-den müssen, um den oder die Fehler zu beheben.

Die Systemadministratoren sollten sich daher regelmäßig über bekannt ge-wordene Schwachstellen informieren (siehe auch M 2.35 Informationsbe-schaffung über Sicherheitslücken des Systems).

Wichtig ist, dass Patches und Updates, wie jede andere Software, nur ausvertrauenswürdigen Quellen bezogen werden dürfen. Für jedes eingesetzteSystem oder Softwareprodukt muss bekannt sein, wo Sicherheitsupdates undPatches erhältlich sind. Außerdem ist es wichtig, dass Integrität und Authen-tizität der bereits installierten Produkte oder der einzuspielenden Sicherheits-updates und Patches überprüft werden (siehe M 4.177 Sicherstellung der In-tegrität und Authentizität von Softwarepaketen), bevor ein Update oder Patchinstalliert wird. Vor der Installation sollten sie außerdem mit Hilfe eines Com-puter-Virenschutzprogramms geprüft werden. Dies sollte auch bei solchen Pa-keten gemacht werden, deren Integrität und Authentizität verifiziert wurde.

Sicherheitsupdates oder Patches dürfen jedoch nicht voreilig eingespielt wer-den, sondern müssen vor dem Einspielen getestet werden. Falls sich ein Kon-flikt mit anderen kritischen Komponenten oder Programmen herausstellt, kannein solches Update sonst zu einem Ausfall des Systems führen. Nötigenfallsmuss ein betroffenes System so lange durch andere Maßnahmen geschütztwerden, bis die Tests abgeschlossen sind.

Vor der Installation eines Updates oder Patches sollte stets eine Datensiche-rung des Systems erstellt werden, die es ermöglicht, den Originalzustand wie-der herzustellen, falls Probleme auftreten. Dies gilt insbesondere dann, wennausführliche Tests aus Zeitgründen oder mangels eines geeigneten Testsy-stems nicht durchgeführt werden können.

In jedem Fall muss dokumentiert werden, wann, von wem und aus welchemAnlass Patches und Updates eingespielt wurden (siehe auch M 2.34 Doku-mentation der Veränderungen an einem bestehenden System). Aus der Do-kumentation muss sich der aktuelle Patchlevel des Systems jederzeit schnellermitteln lassen, um beim Bekanntwerden von Schwachstellen schnell Klar-heit darüber zu erhalten, ob das System dadurch gefährdet ist.

Falls festgestellt wird, dass ein Sicherheitsupdate oder Patch mit einer ande-ren wichtigen Komponente oder einem Programm inkompatibel ist oder Pro-bleme verursacht, so muss sorgfältig überlegt werden, wie weiter vorgegan-



gen wird. Wird entschieden, dass auf Grund der aufgetretenen Probleme einPatch nicht installiert wird, so ist diese Entscheidung auf jeden Fall zu doku-mentieren. Außerdem muss in diesem Fall klar beschrieben sein, welche Maß-nahmen ersatzweise ergriffen wurden, um ein Ausnutzen der Schwachstellezu verhindern. Eine solche Entscheidung darf nicht von den Administratorenalleine getroffen werden, sondern sie muss mit den Vorgesetzten und dem IT-Sicherheitsbeauftragten abgestimmt sein.

Prüffragen:

- Sind Regelungen für das Patchmanagement definiert?- Werden Software-Updates und Patches ausschließlich aus

vertrauenswürdigen Quellen bezogen?- Werden Software-Updates und Patches vor dem Roll-Out getestet?- Ist sichergestellt, dass bei einem fehlgeschlagenem Update der

ursprüngliche Systemzustand wieder hergestellt werden kann?- Wird die Entscheidung, einen Patch aufgrund aufgetretener Probleme

nicht zu installieren, dokumentiert?



M 2.363 Schutz gegen SQL-InjectionVerantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter ITVerantwortlich für Umsetzung: Administrator, Anwendungsentwickler

Um die Ausnutzung von SQL-Injections (siehe G 5.131 SQL-Injection) zu ver-hindern oder zumindest zu erschweren, sind eine Reihe von Maßnahmen zuergreifen. Diese erstrecken sich über alle Komponenten einer Anwendung,von der Applikation selbst über den Server bis hin zum Datenbank-Manage-mentsystem (DBMS).

Maßnahmen bei der Programmierung von Applikationen

Eine der wichtigsten Maßnahmen zur Vermeidung von SQL-Injection ist diesorgfältige Überprüfung und Filterung von Eingaben und Parametern durchdie Applikation. Überprüft werden sollte, ob die übergebenen Daten dem er-warteten Datentyp entsprechen. Wird z. B. ein numerischer Parameter erwar-tet, kann man diesen in PHP ("PHP: Hypertext Preprocessor") mit der Funkti-on is_numeric() prüfen. Die Filterung hingegen muss dafür sorgen, dass Son-derzeichen wie das Quote-Zeichen ('), das Semikolon (;) und doppelte Binde-striche (--) ignoriert werden.

Sicherer ist der Einsatz von Stored Procedures beziehungsweise PreparedSQL-Statements. Diese werden von vielen Datenbank-Managementsystemen(DBMS) angeboten und sind ursprünglich dazu gedacht, häufiger auftreten-de Abfragen zu optimieren. Der Vorteil dieser parametrisierten Statements ist,dass Parameter nicht mehr direkt in ein SQL-Statement eingebunden werden.Vielmehr werden diese getrennt vom SQL-Statement separat an die Daten-bank übergeben. Das Zusammenführen von Statement und Parametern er-folgt durch das DBMS selbst, wobei die oben genannten Sonderzeichen au-tomatisch maskiert werden.

Um potentiellen Angreifern keine Anhaltspunkte für Angriffe zu liefern, solltebesonderes Augenmerk darauf gelegt werden, dass Applikationen möglichstkeine Fehlermeldungen nach außen ausgeben, die Rückschlüsse auf das ver-wendete System oder auf die Struktur der dahinterliegenden Datenbank zu-lassen.

Serverseitige Maßnahmen

Die wichtigste Sicherheitsmaßname auf dem Server ist das Härten des Betrie-bssystems. Um so wenig Angriffspunkte wie möglich zu bieten, werden dabeiMaßnahmen ergriffen wie:

- das Deaktivieren nicht benötigter Dienste,- das Löschen nicht benötigter Benutzerkonten,- das Einspielen relevanter Patches und- das Löschen aller für die Funktion des Servers unnötigen Bestandteile.

Darüber hinaus sollte der Einsatz eines Application-Level-Gateways (ALG)(siehe M 5.117 Integration eines Datenbank-Servers in ein Sicherheitsgate-way) erwogen werden. ALGs können auf Applikationsebene die Daten über-wachen, die zwischen Webbrowser und Anwendung ausgetauscht werden,und verhindern, dass schädliche Daten den Server erreichen.

Eine weitere zusätzliche Sicherheitsmaßnahme stellt der Einsatz von Intrusi-on-Detection-Systemen (IDS) und Intrusion-Prevention-Systemen (IPS) dar.IDS analysieren den über ein Netz übertragenen Datenverkehr und erkennenpotentiell gefährliche Daten. Die dazu eingesetzten Analysetechniken unter-



teilen sich in Misuse und Anomaly Detection. Die Misuse Detection versucht,bereits bekannte Angriffsmuster zu erkennen. Die Anomaly Detection verfolgtden Ansatz, die zulässigen Verhaltensmuster zu lernen und Abweichungendavon als Angriff zu identifizieren. Während ein IDS in der Lage ist, Angriffe zuerkennen und Warnungen auszugeben, ist ein IPS in der Lage, entsprechendeReaktionen auszuführen. Die Reaktion kann beispielsweise darin bestehen,die Verbindung zu blockieren, Daten zu verwerfen oder zu ändern.

Bei erhöhten Sicherheitsanforderungen sollte geprüft werden, ob der Einsatzvon IDS beziehungsweise IPS zweckmäßig ist.

Datenbankseitige Maßnahmen

Ebenso wie beim Betriebssystem sollte auch eine Härtung der Datenbank er-folgen. Im Falle der Datenbank bedeutet dies z. B.:

- das Entfernen nicht benötigter Stored Procedures,- das Deaktivieren nicht benötigter Dienste,- das Löschen nicht benötigter Benutzerkonten und Default Accounts und- das Einspielen relevanter Patches.

In diesem Zusammenhang sollte auch ein speziell für den Datenbankzugriffvorgesehener Account angelegt werden, der mit möglichst eingeschränktenZugriffsrechten auskommen sollte.

Darüber hinaus sollten sensitive Daten, wie z. B. Passwörter, in der Datenbanksoweit möglich nur verschlüsselt gespeichert werden.

Von vielen Herstellern werden mittlerweile sogenannte Schwachstellen-Scan-ner angeboten, die sowohl Applikationen als auch Datenbanken auf Sicher-heitslücken, wie beispielsweise mögliche SQL-Injections, überprüfen können.

Beispiel für prinzipielles Vorgehen zur Erstellung von sicherem Codebei Verwendung von PHP und MySQL:

In PHP verhindert die Funktion mysql_real_escape_sting() die Übergabe vonSonderzeichen an eine MySQL-Datenbank. Die Funktion maskiert die in demübergebenen String enthaltenen Sonderzeichen wie z. B. Quotes und verhin-dert so SQL-Injections.

Anstatt der folgenden Syntax:

$query = "SELECT * FROM usersWHERE username='" . $_POST['username'] . "'AND password='" . $_POST['password'] . "'";

sollte also diese Syntax verwendet werden:

$query = "SELECT * FROM usersWHERE username='" . mysql_real_escape_string($_POST['username']) . "'AND password='" . mysql_real_escape_string($_POST['password']) . "'";



Beispiel für sicheren Code bei Verwendung von ASP mit ADO undSQL-Server:

Die Verwendung eines prepared Statements für das obige Beispiel sieht indiesem Fall folgendermaßen aus:

$query = "SELECT * FROM users WHERE username=?AND password=?"Set cmd = Server.CreateObject("ADODB.Command")cmd.CommandText = querycmd.CommandType = adCmdTextSet param = cmd.CreateParameter("",adVarChar, adParamInput,nMaxUsernameLength, strUsername)cmd.Parameters.AppendSet param = cmd.CreateParameter("",adVarChar, adParamInput,nMaxUsernameLength, strPassword)cmd.Parameters.AppendSet rs = cmd.Execute()

Hierbei ist zu beachten, dass die oben aufgeführten Code-Beispiele nur dengrundsätzlichen Ansatz zur Vermeidung von SQL-Injection veranschaulichensollen.

Prüffragen:

- Werden Eingaben und Parameter durch die Applikation vor Weiterleitungan das Datenbanksystem sorgfältig überprüft und gefiltert?

- Werden Stored Procedures beziehungsweise Prepared SQL Statementseingesetzt?

- Ist gewährleistet, dass keine Fehlermeldungen nach außen ausgebenwerden, welche Rückschlüsse auf das verwendete System oder auf dieStruktur der dahinterliegenden Datenbank zulassen?



M 2.486 Dokumentation der Architekturvon Webanwendungen undWeb-Services

Verantwortlich für Initiierung: Leiter Entwicklung, Verantwortliche dereinzelnen Anwendungen

Verantwortlich für Umsetzung: Administrator, Entwickler

Das Verständnis der Software-Architektur einer Webanwendung beziehungs-weise eines Web-Service ist notwendig, um diese effizient und fehlerfrei zuwarten, zu entwickeln und zu erweitern. Neben der systemspezifischen Doku-mentation (siehe zum Beispiel M 2.25 Dokumentation der Systemkonfigurati-on, M 2.31 Dokumentation der zugelassenen Benutzer und Rechteprofile undM 2.34 Dokumentation der Veränderungen an einem bestehenden System)sind bei der Dokumentation von Webanwendungen und Web-Services einigeBesonderheiten zu berücksichtigen.

Die Dokumentation muss alle Bestandteile berücksichtigen. Dabei sollten min-destens folgende Punkte durch die spezifische Dokumentation abgedeckt wer-den:

- Alle Abhängigkeiten (zum Beispiel zu Frameworks, Bibliotheken, Betrie-bssystemen, Hardware) und Schnittstellen (zum Beispiel zu Hintergrund-systemen) sollten dokumentiert werden. Bei Web-Services muss auch dieInteraktion mit anderen Web-Services dokumentiert werden.

- Für den Betrieb notwendige Komponenten, die nicht Bestandteil der We-banwendung oder des Web-Service sind, müssen als solche gekennzeich-net werden (zum Beispiel Hintergrundsysteme wie eine Datenbank).

- Aus der Dokumentation muss hervorgehen, welche Komponenten Sicher-heitsmechanismen umsetzen. Im Folgenden sind die Sicherheitsfunktio-nen von Webanwendungen und Web-Services aufgeführt, die mindestensberücksichtigt werden sollten:

- Benutzermanagement,- Rollen- und Berechtigungskonzept,- Authentisierung,- Autorisierung,- Session-Management,- Protokollierung und- Transportsicherheit.

- Die Integration in eine gegebenenfalls bestehende Netzinfrastruktur mussin der Dokumentation behandelt werden. Hierbei ist die MaßnahmeM 5.169 Systemarchitektur einer Webanwendung zu beachten.

- Die eingesetzten kryptographischen Funktionen und Verfahren müssendokumentiert sein, siehe Baustein B 1.7 Kryptokonzept.

Die Dokumentation sollte während des Projektverlaufs aktualisiert und ange-passt werden, sodass sie schon während der Entwicklungstätigkeit genutztwerden kann und Entscheidungsfindungen dokumentiert sind.

Prüffragen:

- Ist die Software-Architektur der Webanwendung beziehungsweise desWeb-Service mit allen Bestandteilen und Abhängigkeiten dokumentiert?

- Werden für den Betrieb notwendige Komponenten, die nicht Bestandteilder Webanwendung beziehungsweise des Web-Service sind, als solchegekennzeichnet?



- Ist eine Zuordnung umgesetzter Sicherheitsmechanismen zu denKomponenten der Webanwendung beziehungsweise des Web-Servicedokumentiert?

- Berücksichtigt die Dokumentation eine Integration der Webanwendungbeziehungsweise des Web-Service in bestehende Netzinfrastruktur?

- Sind die eingesetzten kryptographischen Funktionen und Verfahrendokumentiert?

- Erfolgt die Dokumentation der Architektur einer Webanwendungbeziehungsweise eines Web-Service bereits während derEntwicklungstätigkeit?



M 2.487 Entwicklung und Erweiterungvon Anwendungen

Verantwortlich für Initiierung: Fachverantwortliche, Verantwortliche dereinzelnen Anwendungen

Verantwortlich für Umsetzung: Entwickler, Beschaffer, LeiterEntwicklung, Tester

Für die effiziente Entwicklung von Anwendungen (auch Webanwendungen)sollten Regeln festgelegt und eingehalten werden. Das Ziel dabei ist, sowohlKonzeptions- als auch Programmierfehler bereits in der frühen Phase des Ent-wicklungs- und Erweiterungsprozesses zu vermeiden oder zumindest frühzei-tig zu erkennen.

Die folgenden Punkte sollten daher bei der Entwicklung und Erweiterung vonAnwendungen beachtet werden.

Entwicklung nach einem Vorgehensmodell

Es sollte nach einem geeigneten Vorgehensmodell (bzw. V-Modell XT, Was-serfallmodell, Spiralmodell) entwickelt werden. Dabei hat eine Anwendungvor der Inbetriebnahme alle Entwicklungsphasen des Vorgehensmodells zudurchlaufen.

Das verwendete Vorgehensmodell sollte mindestens die folgenden oder ver-gleichbare Phasen abdecken.

Anforderungsanalyse

Unternehmenssicherheitsrichtlinien und unternehmensspezifische Vorgabensollten bei der Erhebung der Anforderungen an die Anwendung berücksichtigtund den Entwicklungsteams zur Verfügung gestellt werden (z. B. Erfüllung vonIndustrie-Standards wie PCI DSS oder Vorgaben zur Barrierefreiheit). Hierzuzählen z. B. auch Vorgaben und Anforderungen an die Verwendung krypto-graphischer Algorithmen und sicherer Programmierrichtlinien (siehe auch Ab-schnitt Umsetzung von Programmierrichtlinien).

In dieser Phase sollten alle von der Anwendung zu verarbeitenden Daten iden-tifiziert und nach dem Schutzbedarf klassifiziert werden. Es müssen adäqua-te Schutzmechanismen der Anwendung festgelegt werden, welche die Datengemäß ihrem Schutzbedarf schützen.

Konzeption und Design

Bei der Konzeption sollten die Architektur und der Aufbau der Anwendung fest-gelegt und dokumentiert werden. Hierbei sollte die Auswahl von Entwicklungs-techniken (z. B. Programmiersprachen, Frameworks) miteinbezogen werden.Auch das Wissen und der Erfahrungsschatz der Entwickler sollten aus Kosten-und Sicherheitsgründen berücksichtigt werden.

Die Architektur sollte vorsehen, dass Komponenten (z. B. zur Autorisierung,Authentisierung) vorzugsweise in Modulen umgesetzt werden, die wiederver-wendet werden können. Durch die zentrale Verfügbarkeit und Nutzung vonModulen können Redundanzen vermieden und die Pflege erleichtert werden.



Bei Client-/Server-Architekturen (z. B. Webanwendung) sollten die zentra-len Sicherheitsmechanismen nach Möglichkeit mindestens serverseitig umge-setzt werden.

Es sollte darauf geachtet werden, dass Sicherheitsanforderungen vollständigdurch Sicherheitsmechanismen erfüllt und zur Erstellung von Testfällen fest-gehalten werden.

Getroffene Entscheidungen sollten dokumentiert werden, sodass später eineeffiziente Weiterentwicklung der Anwendung durch ausreichende Dokumen-tation gewährleistet ist.

Entwicklung

Bei der Umsetzung der Anwendung sollten Programmierrichtlinien (siehe auchAbschnitt Umsetzung von Programmierrichtlinien) für die sichere Entwicklungder Komponenten eingehalten werden.

Es sollte darauf geachtet werden, dass die Dokumentation während der Ent-wicklungstätigkeit fortgeführt wird (z. B. durch Kommentare im Quelltext undWerkzeuge zur Generierung der Dokumentation). Somit ist der Quelltext zueinem späteren Zeitpunkt auch für Dritte nachvollziehbar.

Zum Schutz vor dem Verlust bereits entwickelter und verworfener Lösungensowie zu Dokumentationszwecken sollte die Historie der Änderungen festge-halten werden (z. B. durch ein Revisionssystem).

Tests

Testfälle sollten nicht nur die Geschäftsfunktionen, sondern ebenfalls die Si-cherheitsfunktionalität berücksichtigen. Dazu zählen z. B. Sicherheitskompo-nenten wie Autorisierungs-, Authentisierungs- und Filterkomponenten. NachMöglichkeit sollten Penetrationstests und (für hohen Schutzbedarf) auch Sour-ce-Code-Analysen durchgeführt werden, um die umgesetzten Sicherheitsme-chanismen zu kontrollieren (M 5.150 Durchführung von Penetrationstests).

Vor der Inbetriebnahme einer Anwendung sollte nicht nur die Funktionstüch-tigkeit, sondern auch ein möglicher Missbrauch der angebotenen Funktiona-lität geprüft werden. Dies kann durch Penetrationstests erreicht werden. Da-mit ein Vier-Augen-Prinzip beim Testen umgesetzt wird, sollten die Tests nichtvon den Personen durchgeführt werden, die zuvor an der Konzeption oder derEntwicklung der Anwendung beteiligt waren.

Bei den Tests ist darauf zu achten, dass diese nur mit Testdaten und nicht mitLive-Daten bzw. Kundendaten durchgeführt werden.

Bei Webanwendungen sollten die Webseiten auf Konformität zu dem ver-wendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch kön-nen unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation seitensder Browser vermieden werden. Eine Überprüfung mit verschiedenen Brow-sern kann hier sehr hilfreich sein.

Bei der Planung und Durchführung der Tests sollte die MaßnahmeM 2.62 Software-Abnahme- und Freigabe-Verfahren berücksichtigt werden.

Integration und Softwareverteilung (Deployment)

Vor der produktiven Inbetriebnahme sind die Anwendungen und gegebenen-falls notwendige Hintergrundsysteme sicher zu konfigurieren. Hierbei sollte



die Anbindung möglicher Hintergrundsysteme (z. B. Identitätsspeicher, Da-tenbanken) an die Anwendung berücksichtigt werden. Vor der Inbetriebnah-me der Anwendung ist ebenfalls sicherzustellen, dass der Transportkanal ge-schützt ist.

Sensible Daten der Anwendung sind häufig in Hintergrundsystemen hinter-legt. Daher sollte das Sicherheitsniveau der Anwendung und möglicher Hin-tergrundsysteme einheitlich sein. Der Zugriff auf die Hintergrundsysteme soll-te Benutzern lediglich über die definierten Schnittstellen der Anwendung mög-lich sein.

Darüber hinaus sollte sichergestellt werden, dass die Daten bei der Verteilungder Anwendung nicht durch Dritte manipuliert werden können.

Wartung

Es muss ein Prozess zur Pflege der Anwendung definiert werden, der auchdie regelmäßige Prüfung der Sicherheit der Anwendung auf Schwachstellenbzw. verfügbare Patches berücksichtigt.

Wird die Anwendung angepasst oder erweitert, muss darauf geachtet werden,dass die Wirksamkeit der Sicherheitsmechanismen nicht beeinträchtigt wird.Zusätzlich sollte durch Tests in einer gesonderten Testumgebung die Wirk-samkeit der Sicherheitsmechanismen erneut überprüft werden.

Umsetzung von Programmierrichtlinien

Eine Programmierrichtlinie hilft, einen einheitlichen Programmierstil zu defi-nieren und ein einheitliches Sicherheitsniveau zu etablieren (z. B. durch dieVerwendung von Sicherheitsbibliotheken). Die Qualität und Verständlichkeitdes Quelltexts kann hierdurch verbessert und nachvollziehbarer werden. Inder Folge können Fehler und Schwachstellen einfacher gefunden und einespätere Erweiterung der Anwendung kosteneffektiv umgesetzt werden.

Programmierrichtlinien sollten nicht nur bei der Entwicklung im eigenen Haus,sondern auch beim Outsourcing der Entwicklungstätigkeit umgesetzt werden.

Zukunftssichere Entwicklung von Sicherheitsmechanismen

Wenn Sicherheitsmechanismen entworfen und entwickelt werden, sollten hier-bei auch zukünftige Entwicklungen von Angriffstechniken als auch Standards(z. B. neuer HTML-Standard) berücksichtigt werden. So sollte beispielswei-se eine Filterkomponente, die als schadhaft klassifizierte <script>-Tags filtert,ebenso unbekannte Tags filtern. Unbekannte Tags können gegebenenfalls zu-künftig verwendet werden (z. B. mit der Einführung eines neuen HTML-Stan-dards), um Sicherheitsmechanismen der Webanwendung zu umgehen.

Produktspezifische Sicherheitsfunktionalität

Falls eine Webanwendung ausschließlich mit einem spezifischen Browser (u.U. nur eines Herstellers) genutzt wird, so sollte der Einsatz von produktspezi-fischen Sicherheitsfunktionen des Browsers berücksichtigt werden.

Outsourcing der Anwendungsentwicklung

Im Fall von Outsourcing muss sichergestellt werden, dass das beauftragteDritt-Unternehmen die nötigen Sicherheitsanforderungen bei der Umsetzungder Anwendung erfüllt. Dies kann beispielsweise durch die Vorgabe eines Vor-gehensmodells oder durch Programmierrichtlinien erreicht werden.



Wird für die Entwicklung einer Anwendung mit hohem Schutzbedarf einDienstleister beauftragt, sollte der Quelltext (z. B. das Projektarchiv) unter deradministrativen Kontrolle des Auftraggebers stehen. Dabei sollte der Auftrag-geber jederzeit auf den Quelltext der Anwendung zugreifen und Änderungenam Quelltext nachvollziehen können.

Festlegung der Entwicklungsumgebung

Die Produktiv-, Test- und Entwicklungsumgebungen sind auf getrennten Sy-stemen zu betreiben. In den Umgebungen sollten unterschiedliche Zugangs-daten gewählt werden. Testkonten sollten hierbei, soweit möglich, keine privi-legierten Rechte erhalten. Grundsätzlich dürfen erfolgreiche Angriffe auf dieEntwicklungs- oder Testumgebung keine Auswirkungen auf die Produktivum-gebung haben.

Prüffragen:

- Wird die Anwendung nach einem geeigneten Vorgehensmodellentwickelt?

- Werden alle Phasen bei der Entwicklung von Anwendungen durch dasVorgehensmodell abgedeckt und vor der Inbetriebnahme vollständigdurchlaufen?

- Werden Programmierrichtlinien für die Entwicklung von Anwendungenvorgegeben?

- Werden bei dem Entwurf und der Entwicklung vonSicherheitsmechanismen bei Anwendungen auch zukünftige Standardsund Angriffstechniken berücksichtigt?

- Werden bei der Anwendungsentwicklung die Entwicklungs-, Test- undProduktivsysteme voneinander getrennt?

- Werden für die Anwendung Penetrationstests durchgeführt, bei denen dieAnwendungslogik geprüft wird?

- Werden die Penetrationstests bei Anwendungen nach einem Vier-Augen-Prinzip durchgeführt?



M 2.530 Planung und Vorbereitung vonMigrationen

Verantwortlich für Initiierung: Leiter ITVerantwortlich für Umsetzung: Administrator, Fachverantwortliche

Migrationen von IT-Infrastrukturen sind in der Regel sehr komplexe Vorhabenmit einer großen Anzahl von Einflussfaktoren und möglichen Fehlerquellen.Migrationen verlaufen in aller Regel nur dann erfolgreich, wenn sie im Vorfeldsorgfältig geplant und vorbereitet werden.

Um nicht an der Komplexität des Themas zu scheitern, empfiehlt sich die Wahleines bewährten Vorgehensmodells. In der Praxis haben sich weder reineTop-Down-Ansätze mit einmaliger Komplettumstellung noch ein reines punk-tuell aus den Fachabteilungen getriebenes Bottom-Up-Vorgehen bewährt.Zielführend ist der Mittelweg einer iterativen, priorisierten wechselseitigen Ab-stimmung der Geschäftsprozesse und IT-Modelle aus den Fachabteilungenund aus den Geschäftsanforderungen heraus. Reifegradmodelle können hel-fen, den jeweils nächsten Entwicklungsschritt einer Iteration zu planen.

Nachdem die im nächsten Migrationsschritt zu erreichenden Ziele festgelegtund die zu migrierenden Dienste identifiziert sind, werden im Planungsschrittdie Anforderungen an die IT aus den Geschäftszielen (einschließlich der Si-cherheitsanforderungen) abgeleitet. Die Phase der Migration umfasst die tech-nische Umsetzung dieser Anforderungen in Form von Anwendungen und Sy-stemen, die anschließend in den Betrieb überführt werden. Dieser Zyklus wirdwiederholt, bis der gewünschte Reifegrad erreicht ist. In jeder Iteration ist da-bei zu prüfen, welche Anpassungen an (Alt-)Anwendungen und Schnittstellenvorgenommen werden müssen.

Stehen der zeitliche Rahmen und Umfang der Migration fest, ist die notwendi-ge technische Infrastruktur zu planen. Hier sind insbesondere Fragen der Di-mensionierung wichtig, denn Web-Service-Umgebungen unterscheiden sichhinsichtlich der benötigten Ressourcenparameter im Allgemeinen deutlich vonden bestehenden Umgebungen. Sinnvollerweise werden Lasttests durchge-führt, mindestens aber Fachverstand in Bezug auf die Ressourcenausstattungherangezogen.

Die Migrationsplanung hat zu berücksichtigen, welche Systeme und Anwen-dungen wann migriert werden, ob Ausfallzeiten nötig und vertretbar sind. Fürunerwartete Komplikationen müssen Abbruchkriterien und Rückfallszenariendefiniert werden, mit denen sich die Umgebung in einen betriebsfähigen Zu-stand zurücksetzen lässt.

Besonders zu Berücksichtigen bei der Planung sind die dadurch entstehendenAbhängigkeiten von Anbietern und Standards. Letztere sind sorgfältig auszu-wählen und sollten in ihrer Weiterentwicklung und auch auf möglicherweisebekannt werdende Sicherheitslücken in den Standards selbst beobachtet wer-den.

Wenn besondere Systeme zum Einsatz kommen sollen, die bisher nicht be-nötigt wurden - etwa eine XML-Firewall als Application Level Gateway -, sosind diese vorher ausführlich im Hinblick auf die erforderliche Funktionalität zutesten und in das Sicherheitskonzept mit aufzunehmen.

In dem Maße, wie eine Migration die Chance bietet, zukünftig zentrale Dienstewie Identitätsmanagement oder eine PKI standardisiert nutzbar zu machen,



müssen auch diese Dienste betrachtet und zusätzlich abgesichert werden.Insbesondere wenn ein Single Sign-On geplant wird, sind die Implikationen aufdie Sicherheit genauestens zu prüfen, siehe auch M 4.456 Authentisierung beiWeb-Services, M 4.455 Autorisierung bei Web-Services und M 4.453 Einsatzeines Security Token Service (STS).

Die spezifischen Risiken, die sich durch eine Migration ergeben, beziehen sichzum einen auf die damit verbundenen Änderungen der Architektur. Die fürdie Zielarchitektur erforderlichen Sicherheitsmaßnahmen sind daher (anhandder einschlägigen Bausteine oder einer ergänzenden Sicherheitsanalyse undgegebenenfalls zusätzlichen Risikoanalyse) vorab zu identifizieren und zu be-rücksichtigen. Beachtet werden muss auch, dass durch die Migration Abhän-gigkeiten entstehen können, die die Anforderungen an die Verfügbarkeit deut-lich erhöhen können. Zum anderen birgt auch die Migration selbst Risiken, dadiese sowohl mit hohen Kosten als auch mit einer langen Projektlaufzeit ein-hergehen kann. Beide Klassen von Risiken sind im Zuge der Migrationspla-nung zu analysieren und dokumentieren.

Für eine umfangreiche Migration oder eine tief greifende Umstellung der Ar-chitektur ist es zudem dringend anzuraten, ein eigenes Sicherheitskonzept zuerarbeiten und das Ergebnis der Migration im vorhandenen Sicherheitskon-zept zu behandeln.

Dies trifft insbesondere dann zu, wenn eine Migration auf einen zentralen Ser-vicebus (meist ESB, Enterprise Service Bus) vollzogen wird. Dieser stellt einenmöglichen zentralen Ausfallpunkt dar und sollte daher angemessen in der Not-fallplanung berücksichtigt sein, falls es Anforderungen in Bezug auf die Ver-fügbarkeit der SOA gibt.

Nicht zu vernachlässigen ist auch die Frage des Wissenstransfers: Durch dietief greifende Umstellung der Architektur wird von den Administratoren, letzt-lich aber auch von den Fachverantwortlichen ein Umdenken verlangt, das be-reits in der Planungsphase mit entsprechenden Zeitaufwänden und Schulun-gen zu berücksichtigen ist.

Eine Migration stellt immer ein langfristiges und strategisches Programm dar,das, um Erfolg zu haben, von der Leitungsebene getragen und gesteuert wer-den und von den Beteiligten über die komplette Laufzeit mit Leben gefüllt wer-den muss.

Prüffragen:

- Wurde ein geeignetes Vorgehensmodell für die Migration gewählt?- Wurden die zu migrierenden Dienste identifiziert und deren

Anforderungen, einschließlich der Sicherheitsanforderungen, erhoben unddokumentiert?

- Wurde die notwendige Auslegung der Infrastruktur und der Systemedurch Expertise oder realistische Lasttests bestimmt?

- Wurden notwendige Ausfallzeiten ermittelt, geplant und abgestimmt?- Ist ein Rückfall-Szenario vorbereitet, und sind Abbruchkriterien für die

Migration definiert?- Sind die spezifischen Risiken der Migration analysiert und dokumentiert?- Ist ein Wissenstransfer an das Betriebspersonal und die

Fachverantwortlichen gesichert?- Wird die Migrationsstrategie von der Leitungsebene getragen und die

Migration von ihr gesteuert?



M 2.531 Erarbeitung einerSicherheitsrichtlinie für Web-Services

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter ITVerantwortlich für Umsetzung: Administrator, Entwickler

Um ein angemessenes Sicherheitsniveau für einen Web-Service zu gewähr-leisten, muss entschieden werden, wie die erforderlichen Sicherheitsfunktio-nen konkret realisiert werden, und wer dafür verantwortlich ist. Um die Revisi-onsfähigkeit zu gewährleisten, müssen solche Entscheidungen nachvollzieh-bar dokumentiert sein. Diese Dokumentation erfolgt am besten in einer Sicher-heitsrichtlinie, die sich in das Sicherheitsregelwerk der Institution einfügt (sie-he auch M 2.338 Erstellung von zielgruppengerechten Sicherheitsrichtlinien).

Die Sicherheitsrichtlinie sollte Regelungen zu den folgenden Themen umfas-sen. Sofern Themenbereiche bereits in anderen Dokumenten verbindlich vor-gegeben sind, genügt ein entsprechender Verweis.

Architektur und Plattformen

Übergreifende Aussagen zur Rolle von Web-Services im Rahmen derIT-Strategie

Festlegung der eingesetzten (service-orientierten) Architektur

Beschreibung der Komponenten der Architektur:- Beteiligte Systeme- Beteiligte Softwarekomponenten- Einsatz von Verzeichnissen (Registries und Repositories)- Einsatz eines Enterprise Service Bus- Einsatz von Sicherheitskomponenten (XML-Firewalls, Protokollserver und

ähnliches), Einbeziehung von Sicherheits-Diensten Dritter- Einsatz von Identitäts-Diensten und Authentisierungs- oder Autorisie-

rungsdiensten

Festlegung der eingesetzten- Produkte,- Programmiersprachen und Ablaufumgebungen,- XML-Schemata,- Standards und- Protokolle.

Sicherheitsanforderungen an Web-Services

Einsatzzweck von Web-Services in der Institution- resultierende Anforderungen an die Vertraulichkeit, Verfügbarkeit und In-

tegrität- gegebenenfalls Definition von verschiedenen Sicherheitsklassen je nach

Schutzbedarf- Berücksichtigung der Sicherheitsanforderungen Dritter (zum Beispiel ex-

terner Consumer des Web-Service, siehe M 2.532 Anbieten von Web-Ser-vices für Dritte)



Ableitung von konkreten Anforderungen und Ausarbeitung vonVorgaben für- die Authentisierung (Authentisierungsverfahren, Einbindung Dritter, Föde-

ration),- die Autorisierung,- die Datenhaltung und -integrität,- die Realisierung von Schnittstellen (Anbindung von Backend-Systemen,

Einsatz eines Enterprise Service Bus, eingesetzte Protokolle)- die Verschlüsselung der Kommunikation/der XML-Nachrichten und der

Datenhaltung- die Integritätssicherung der Kommunikation/der XML-Nachrichten und der

Daten,- das Schlüssel- und Zertifikatsmanagement (Anbindung an PKI, Nutzung

von Zertifikaten Dritter, Sicherung der kryptographischen Schlüssel)- die Orchestrierung und Choreographie der Web-Services zur Erfüllung

übergreifender Geschäftsfunktionen,- die Datensicherung,- die Skalierbarkeit,- die Ausfallsicherheit,- die Protokollierung unddie Dokumentation.

Management von Web-Services- Entwicklungsvorgaben,- Test- und Freigabeverfahren,- Lebenszyklus-Management,- Klare Festlegung von Verantwortlichen für jeden Web-Service und jedes

beteiligte System, klare Abgrenzung bei einer Verteilung der Verantwor-tung auf mehrere Bereiche oder Personen (zum Beispiel Entwicklung undBetrieb, Plattform und Web-Service),

- Umsetzung des Benutzer- und Rechtemanagements (Abläufe, Zuständig-keiten, Dokumentation)

- Schulung und Weiterbildung des eingesetzten Personals (Entwickler, Ad-ministratoren) einschließlich Sensibilisierungsmaßnahmen für die Sicher-heit

- Auswertung sicherheitsrelevanter Ereignisse- Durchführung von regelmäßigen Audits- Notfallplanung für Web-Services (siehe auch M 6.154 Notfallmanagement

für Web-Services).

Die Sicherheitsrichtlinie muss mit den beteiligten Stellen in der Institution ab-gestimmt und von einer dazu autorisierten Stelle offiziell in Kraft gesetzt sein.Die gültige Richtlinie muss allen betroffenen Personen bekannt und leicht zu-gänglich sein. Durch geeignete Prozesse und Verantwortlichkeiten muss si-chergestellt werden, dass die Richtlinie bedarfsgerecht fortgeschrieben undaktualisiert wird.

Die Einhaltung der Vorgaben aus der Richtlinie muss, zum Beispiel im Rah-men von Revisionsprüfungen, regelmäßig überwacht werden.

Prüffragen:

- Sind die in dieser Maßnahme aufgeführten Themenbereiche in einemgeeigneten Dokument geregelt?

- Sind die Vorgaben in der Institution verbindlich (Freigabe derRegelungen)?



- Ist die Aktualisierung und Pflege der Regelungen in einem angemessenenZyklus sichergestellt?

- Wird die Einhaltung der Vorgaben regelmäßig in angemessener Formüberprüft?



M 2.532 Anbieten von Web-Services fürDritte

Verantwortlich für Initiierung: Behörden-/UnternehmensleitungVerantwortlich für Umsetzung: Vertrieb, Vertragsmanagement

Web-Services können auf verschiedene Weise bereitgestellt werden. Sie kön-nen entweder als fertige Lösung verkauft (Betrieb durch den Consumer selbst)oder als Dienstleistung bereitgestellt werden (Betrieb durch den Anbieter).Beim Betrieb durch einen Anbieter müssen alle relevanten Modalitäten der Zu-sammenarbeit mit dem Web-Service-Consumer vertraglich geregelt und ge-eignete Service Level Agreements (SLAs) vereinbart werden, zum BeispielAnsprechpartner, Reaktionszeiten, Kontrolle über die Daten, Leistungen, Aus-gestaltung der Sicherheitsvorkehrungen (siehe hierzu M 2.533 VertraglicheAspekte bei der Bereitstellung von Web-Services ).

Folgende Aspekte sind zu berücksichtigen, wenn Web-Services für Dritte be-trieben werden:

Umgebung

Die Bereitstellung von Web-Services durch einen Anbieter kann auf einer ei-genen IT-Infrastruktur des Anbieters, auf der des Kunden oder sogar einesDritten erfolgen. Entsprechend ergeben sich unterschiedliche Zuständigkeitenfür die Sicherheit der eingesetzten Umgebung, aber auch zum Beispiel für dieDurchführung von Datensicherungen und Notfallübungen. Die Verantwortlich-keiten für die Betriebsumgebung, ihre einzelnen Bestandteile und Betriebspro-zesse muss zwischen den beteiligten Parteien festgelegt und nachvollziehbardokumentiert werden.

Ansprechpartner

Alle Parteien (Web-Service-Anbieter und -Consumer) müssen Ansprechpart-ner benennen, mindestens für

- vertragliche Fragen- inhaltliche/fachliche Fragen- die Meldung und Behebung von Störungen sowie die Alarmierung im Not-

fall- die Kommunikation und Behandlung von Sicherheitsvorfällen- die Übermittlung beziehungsweise den Empfang der vereinbarten Berich-

te zu Leistungskennzahlen, sicherheitsrelevanten Ereignissen sowie Än-derungen an den Systemen und Diensten.

Für eine mögliche Nichtverfügbarkeit der Ansprechpartner ist eine Vertretungeinzuplanen und zu benennen.

Benutzer- und Rechteverwaltung

Je nachdem, wer die für die Web-Services erforderlichen Benutzer- und Rech-teprofile pflegt, müssen dafür entsprechende Verfahren, Kommunikations-schnittstellen und Dokumentationswege eingerichtet werden. Sowohl die Ein-richtung von Benutzern als auch die Pflege von Berechtigungen kann jeweilsdurch den Anbieter oder durch den Consumer selbst möglich sein. Denkbarsind auch mehrstufige Modelle, in denen der Anbieter Administrationskontenfür die Consumer einrichtet, mit denen diese eigenständig die Benutzer inner-halb der eigenen Institution verwalten. In komplexeren Umgebungen könnenauch Dritte entsprechende Dienste zur Identifizierung, Authentisierung und



Autorisierung von Benutzern anbieten, die zum Beispiel auch wiederum alsWeb-Service realisiert sein können.

Wartung und Pflege

Maßnahmen zur Wartung und Pflege der Systeme, insbesondere zum Ein-spielen von Patches und Updates für die Web-Services oder zugrunde lie-gende Komponenten, können Auswirkungen auf die Consumer haben. Diesumfasst beispielsweise Änderungen in der Funktionalität oder kurzfristige Ein-schränkungen der Verfügbarkeit. Daher müssen Verfahren eingerichtet sein,um solche Wartungsmaßnahmen vorab mit den betroffenen Consumern abzu-stimmen und zu koordinieren, zum Beispiel durch die Vereinbarung von War-tungsfenstern.

Berichts- und Meldepflichten

Der Web-Service-Anbieter muss Abläufe einrichten, um die mit den Consu-mern vereinbarten Berichts- und Meldepflichten zu erfüllen. Dazu gehörenauch Berichtsformate und Übermittlungswege.

Sicherheitsvorfallsbehandlung

Der Prozess zur Sicherheitsvorfallsbehandlung muss berücksichtigen, dasszur Aufklärung und Behandlung von Vorfällen auch eine übergreifende Zu-sammenarbeit zwischen Web-Service-Anbieter und den Web-Service-Consu-mern erforderlich sein kann. Entsprechend müssen hierfür Schnittstellen, An-sprechpartner, Alarmierungswege und Dokumentationsverfahren eingerichtetwerden.

Notfallplanung

Auch im Bereich der Notfallplanung ist eine Koordination der Aktivitäten vonWeb-Service-Anbieter und Web-Service-Consumer erforderlich. So muss sichinsbesondere die Notfallplanung des Web-Service-Anbieters an den Anforde-rungen der Consumer orientieren. Aber auch bei der Umsetzung der Notfall-vorsorgemaßnahmen ist eine Abstimmung und Koordination erforderlich, zumBeispiel bei der gemeinsamen Durchführung von Notfallübungen.

Prüffragen:

- Sind die Verantwortlichkeiten für die genutzte Betriebsumgebung geklärtund dokumentiert?

- Sind bei allen Partnern die relevanten Ansprechpartner festgelegt undbekannt?

- Sind Verfahren für die Benutzer- und Rechteverwaltung vorhanden?- Sind Verfahren für die Wartung, Pflege und Weiterentwicklung der Web-

Services und der Betriebsumgebung eingerichtet und mit allen Beteiligtenabgestimmt?

- Sind geeignete Abläufe, Formate und Kommunikationswege für dasBerichts- und Meldewesen vorhanden?

- Ist das Zusammenwirken von Anbieter und Consumer in den jeweiligenProzessen zur Sicherheitsvorfallsbehandlung berücksichtigt?

- Sind die Anforderungen der Consumer im Notfallmanagement desWeb-Service-Anbieters berücksichtigt, und werden entsprechendeNotfallvorsorgemaßnahmen untereinander abgestimmt?



M 2.533 Vertragliche Aspekte bei derBereitstellung von Web-Services

Verantwortlich für Initiierung: Behörden-/UnternehmensleitungVerantwortlich für Umsetzung: Vertrieb, Vertragsmanagement

Wenn Web-Services für Dritte bereitgestellt werden, sind zwischen Web-Ser-vice-Anbieter und Web-Service-Consumer schriftliche Regelungen zu treffen,die die Sicherheit der Dienstnutzung, aber auch die Nachvollziehbarkeit undOrdnungsmäßigkeit der Leistungserbringung gewährleisten.

Die konkrete Ausgestaltung muss sich am Schutzbedarf der Anwendungenund Geschäftsprozesse orientieren, die durch den Web-Service abgebildetwerden. Dabei kommt insbesondere der Verfügbarkeit häufig ein besondererFokus zu, da der Ausfall eines Web-Service unter Umständen weitere, abhän-gige Web-Services und Anwendungen betrifft und dadurch einen oder sogarmehrere Geschäftsprozesse beeinträchtigen kann.

Die folgende Liste umfasst Aspekte, die bei der Vertragsgestaltung mit demWeb-Service-Consumer geprüft und gemäß dem jeweiligen Schutzbedarf be-rücksichtigt werden sollten.

Generelle vertragliche Gestaltung

Fachliche Regelungen

- Art und Umfang der Nutzung der Web-Services durch den Consumer, Ein-satzzweck

- Fachliche Beratung und Unterstützung der Web-Service-Consumer durchden Web-Service-Anbieter

- Schulungen und Dokumentation- Kundeninformationen/gesetzliche Änderungen

Technische Leistungsparameter

- Verfügbarkeit (mittlere Verfügbarkeit, Wartungsfenster, maximale Ausfall-zeiten)

- Leistungskennzahlen (Transaktionsgeschwindigkeit, Anzahl gleichzeitigerZugriffe, Bandbreite der Anbindung)

- Datenhaltung (Speicherorte, Verschlüsselung, Datensicherung)

Organisatorische Regelungen

- Festlegung von Kommunikationswegen und Ansprechpartnern- Festlegung von Prozessen, Arbeitsabläufen und Zuständigkeiten- Verfahren zur Behebung von Problemen, Benennung von Ansprechpart-

nern mit den nötigen Befugnissen- regelmäßige Abstimmungsrunden- Archivierung und Löschung von Datenbeständen (insbesondere bei Be-

endigung des Vertragsverhältnisses)- Erfordernis und Ausgestaltung von Zutritts- und Zugriffsberechtigungen für

Mitarbeiter des Benutzers zu den Räumlichkeiten und IT-Systemen desWeb-Service-Anbieters

- Abrechnungsmodell und Abrechnungsgrundlagen für die Nutzung

Personal- Festlegung und Abstimmung von Vertretungsregelungen



Notfallvorsorge und Notfallreaktion- Kategorien zur Einteilung von Fehlern und Störfällen nach Art, Schwere

und Dringlichkeit- Erforderliche Handlungen beim Eintreten eines Störfalls- Kontakte für die Alarmierung einschließlich Kontaktwegen und Vertretern- Reaktionszeiten und Eskalationsstufen- Mitwirkungspflicht des Nutzers bei der Behebung von Notfällen- Art und zeitliche Abfolge von regelmäßigen und adäquaten Notfallübungen- Art und Umfang der Datensicherung- Vereinbarung, ob und welche Systeme redundant ausgelegt sein müssen- Regelungen bei Schäden durch höhere Gewalt- Regelungen zur Vertragsbeendigung im Falle einer Insolvenz oder Aufga-

be der Geschäftstätigkeit von Web-Service-Anbieter oder -Consumers, in-klusive Regelungen zum Umgang mit beim Anbieter gespeicherten Daten.

Sicherheitskonzept

Ein Sicherheitskonzept inklusive eines Notfallvorsorgekonzepts ist nachzuwei-sen und Sicherheitsmaßnahmen zum Schutz der Informationen sind umzu-setzen und zu dokumentieren. Der Web-Service-Anbieter muss hierüber demConsumer einen geeigneten Nachweis führen, insbesondere zur Umsetzungder technisch-organisatorischen Maßnahmen bei Auftragsdatenverarbeitung.Der Web-Service-Anbieter sollte sich auf die Einhaltung aller relevanten Ge-setze und Vorgaben, vor allem aber des Datenschutzes nach dem Bundesda-tenschutzgesetz (BDSG) verpflichten.

Entwicklung und Erweiterung von Web-Services

Für die effiziente Entwicklung von Web-Services sollten Regeln festgelegt wer-den, die von allen Partnern eingehalten werden. Das Ziel dabei ist es, sowohlKonzeptions- als auch Programmierfehler frühzeitig zu erkennen, um dieserechtzeitig zu vermeiden. Es sollte nach einem geeigneten Vorgehensmodell(zum Beispiel V-Modell XT) entwickelt werden.

Änderungs- und Patchmanagement- Es müssen Regelungen gefunden werden, die es ermöglichen, dass der

Web-Service Consumer in der Lage ist, sich neuen Anforderungen anzu-passen. Es ist festzulegen, wie geänderte Anforderungen des Consumersbehandelt werden.

- Der Zeitrahmen für die Behebung von Fehlern ist festzulegen.- Testverfahren für neue Soft- und Hardware sind zu vereinbaren. Dabei

sind folgende Punkte einzubeziehen:

- Informationspflicht und- Absprache vor wichtigen Eingriffen ins System

Kontrolle- Es ist zu vereinbaren, inwieweit dem Consumer Auditrechte für die Syste-

me und Abläufe des Web-Service-Anbieters eingeräumt werden. Wennder Web-Service-Anbieter im Rahmen von Sicherheitszertifizierungen au-ditiert wird, ist zu klären, dass dem Consumer die Auditberichte zur Verfü-gung gestellt werden (mindestens als Auszug der für ihn relevanten Pas-sagen).

- Anforderungen an die Protokollierung und Auswertung von Protokolldatei-en müssen festgelegt werden.

- Es ist zu vereinbaren, inwieweit der Web-Service-Consumer Protokollda-ten anfordern oder einsehen darf, und welche weiteren Informationen oderZugriffe ihm zur Aufklärung von Sicherheitsvorfällen zugänglich sind.



Die zu diesen Punkten getroffenen Regelungen müssen zwischen den be-teiligten Parteien wirksam vereinbart werden, also einen Bestandteil der Ver-tragsbeziehung für die Erbringung beziehungsweise Nutzung der Dienste aus-machen.

Prüffragen:

- Sind alle Vereinbarungen schriftlich fixiert?- Enthält der Vertrag alle hier aufgeführten Punkte, die für die konkrete

Anbieter-Nutzer-Beziehung relevant sind?- Sind die entsprechenden Regelungen rechtswirksam zwischen Web-

Service-Anbieter und -Nutzer vereinbart worden?

Maßnahmenkatalog Personal M 3.5 Bemerkungen


M 3.5 Schulung zuSicherheitsmaßnahmen

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, VorgesetzteVerantwortlich für Umsetzung: IT-Sicherheitsbeauftragter, Vorgesetzte

Wie sich an vielen konkreten Beispielen wie den Schadensstatistiken vonElektronik-Versicherern belegen lässt, resultieren Schäden oft schlicht aus derUnkenntnis elementarer Sicherheitsmaßnahmen. Um dies zu verhindern, istjeder einzelne Mitarbeiter zum sorgfältigen Umgang mit geschäftsrelevantenInformationen und der IT zu schulen und zu motivieren. Nur durch die Vermitt-lung der notwendigen Kenntnisse kann ein Verständnis für die erforderlichenMaßnahmen zur Informationssicherheit geweckt werden.

Im Folgenden werden die Kernthemen, die bei einer Schulung zu Sicher-heitsmaßnahmen vermittelt werden sollten, vorgestellt. Eine ausführliche undzielgruppengerichtete Beschreibung von Schulungsinhalten findet sich inM 3.45 Planung von Schulungsinhalten zur Informationssicherheit.

- Sensibilisierung für InformationssicherheitJeder Mitarbeiter ist auf die Bedeutung der Sicherheitsbelange hinzuwei-sen. Ein geeigneter Einstieg in die Sensibilisierung ist es beispielsweise,die Abhängigkeit der Behörde bzw. des Unternehmens und damit der Ar-beitsplätze vom reibungslosen Funktionieren der Geschäftsprozesse auf-zuzeigen. Darüber hinaus ist der Wert von Informationen unter den Ge-sichtspunkten Vertraulichkeit, Integrität und Verfügbarkeit herauszuarbei-ten. Diese Sensibilisierungsmaßnahmen sind in regelmäßigen Zeitabstän-den zu wiederholen.

- Mitarbeiterbezogene InformationssicherheitsmaßnahmenZu diesem Thema sollen die Sicherheitsmaßnahmen vermittelt werden,die in einem Informationssicherheitskonzept erarbeitet wurden und vonden einzelnen Mitarbeitern umzusetzen sind. Je nach Geschäftsprozessoder Fachaufgabe kann es andere Werte geben, die zu schützen sind,oder einen anderen Schutzbedarf haben. Den Mitarbeitern sollte vermit-telt werden, welche Bedeutung Informationen oder andere Objekte für dieInstitution haben und was sie beim Umgang mit diesen beachten sollten.Dieser Teil der Schulungsmaßnahmen hat eine große Bedeutung, da vie-le Sicherheitsmaßnahmen erst nach einer entsprechenden Schulung undMotivation effektiv umgesetzt werden können.

- Produktbezogene SicherheitsmaßnahmenZu diesem Thema sollen die Sicherheitsmaßnahmen vermittelt werden,die inhärent mit einem Produkt wie beispielsweise einem IT-System ver-bunden sind und häufig bereits im Lieferumfang enthalten sind. Dieskönnen neben Passwörtern zur Anmeldung auch Möglichkeiten zur Ver-schlüsselung von Dokumenten oder Datenfeldern sein. So können bei-spielsweise Hinweise und Empfehlungen über die Strukturierung und Or-ganisation von Dateien den Aufwand zur Datensicherung deutlich redu-zieren.

- Verhalten bei Auftreten von SchadsoftwareHier soll den Mitarbeitern vermittelt werden, wie mit Computer-Viren oderanderer Schadsoftware umzugehen ist. Mögliche Inhalte dieser Schulungsind (siehe M 6.23 Verhaltensregeln bei Auftreten von Schadprogram-men):

- Erkennen einer Schadsoftware-Infektion- Wirkungsweise und Arten von Schadsoftware- Sofortmaßnahmen im Verdachtsfall



- Maßnahmen zur Eliminierung von Schadsoftware- Vorbeugende Maßnahmen

- AuthentikationMitarbeiter sollten mit den vorhandenen Authentikationsmechanismen undden hierfür genutzten Authentikationsmitteln (z. B. Passwörtern oder To-ken) korrekt umgehen gehen können. Beispielsweise sollen die Bedeu-tung von Passwörtern für die Informationssicherheit sowie die Randbedin-gungen erläutert werden, die einen wirksamen Einsatz eines Passworteserst ermöglichen (siehe auch M 2.11 Regelung des Passwortgebrauchs).

- Bedeutung der Datensicherung und deren DurchführungDie regelmäßige Datensicherung ist eine der wichtigsten Sicherheitsmaß-nahmen in jedem Informationsverbund. Vermittelt werden soll das Daten-sicherungskonzept (siehe Baustein B 1.4 Datensicherungskonzept) derBehörde bzw. des Unternehmens und die von jedem einzelnen durchzu-führenden Datensicherungsaufgaben. Besonders wichtig ist dies für sol-che Bereiche, in denen Benutzer selbst die Datensicherungen durchfüh-ren müssen.

- Umgang mit personenbezogenen DatenAn den Umgang mit personenbezogenen Daten sind besondere Anforde-rungen zu stellen. Mitarbeiter, die mit personenbezogenen Daten arbei-ten, sind für die gesetzlich erforderlichen Sicherheitsmaßnahmen zu schu-len. Dies betrifft beispielsweise den Umgang mit Auskunftsersuchen, Än-derungs- und Verbesserungswünschen der Betroffenen, gesetzlich vorge-schriebene Fristen zur Datenlöschung, Schutz der Vertraulichkeit und dieÜbermittlung der Daten.

- Einweisung in NotfallmaßnahmenSämtliche Mitarbeiter sind in bestehende Notfallmaßnahmen einzuweisen.Dazu gehört die Erläuterung der Fluchtwege, die Verhaltensweisen beiFeuer oder anderen Notfällen, der Umgang mit Feuerlöschern und dasNotfall-Meldesystem (wer als erstes wie zu benachrichtigen ist).

- Vorbeugung gegen Social EngineeringDie Mitarbeiter sollen auf die Gefahren des Social Engineering hingewie-sen werden. Die typischen Muster solcher Versuche, über gezieltes Aus-horchen an vertrauliche Informationen zu gelangen, ebenso wie die Me-thoden, sich dagegen zu schützen, sollten erläutert werden. Da SocialEngineering oft mit der Vorspiegelung einer falschen Identität einhergeht,sollten Mitarbeiter regelmäßig darauf hingewiesen werden, die Identitätvon Gesprächspartnern zu überprüfen und insbesondere am Telefon kei-ne vertraulichen Informationen weiterzugeben.

Bei der Durchführung von Schulungen sollte immer beachtet werden, dasses nicht reicht, einen Mitarbeiter einmal während seines gesamten Arbeitsver-hältnisses zu schulen. Für nahezu alle Formen von Schulungen - insbeson-dere Front-Desk-Schulungen - gilt, dass sehr viele neue Informationen auf dieTeilnehmer einstürzen. Diese gelangen nur zu einem kleinen Teil ins Langzeit-gedächtnis, 80% des vermittelten Wissens sind meist schon bei Schulungs-ende wieder vergessen.

Daher sollten Mitarbeiter immer wieder zu Themen rund um die Informations-sicherheit geschult bzw. sensibilisiert werden. Dies kann beispielsweise

- in kürzeren Veranstaltungen zu aktuellen Sicherheitsthemen,- im Rahmen regelmäßiger Veranstaltungen wie Abteilungsbesprechungen,

oderdurch interaktive Schulungsprogramme, die allen Mitarbeitern zur Verfü-

gung stehen, erfolgen.



Prüffragen:

- Werden die Mitarbeiter zu Themen rund um dieInformationssicherheitsmaßnahmen geschult?

- Wird den Mitarbeitern vermittelt, welche Bedeutung Informationen oderandere Objekte haben und was sie beim Umgang mit diesen beachtensollten?

- Werden Mitarbeiter, die mit personenbezogenen Daten arbeiten, für diegesetzlich erforderlichen Sicherheitsmaßnahmen geschult?

- Werden die Mitarbeiter regelmäßig zu Themen der Informationssicherheitgeschult bzw. sensibilisiert?

Maßnahmenkatalog Hard- und Software M 4.78 Bemerkungen


M 4.78 Sorgfältige Durchführung vonKonfigurationsänderungen


Die Durchführung von Änderungen an einem IT-System im Echtbetrieb ist im-mer als kritisch einzustufen und entsprechend sorgfältig muss hierbei vorge-gangen werden.

Bevor mit Änderungen am System begonnen wird, muss als erstes die alteKonfiguration gesichert werden, sodass sie schnell verfügbar ist, wenn Pro-bleme mit der neuen Konfiguration auftreten.

Bei vernetzten IT-Systemen müssen die Benutzer rechtzeitig über die Durch-führung von Wartungsarbeiten in geeigneter Weise, wie z. B. durch einen Ein-trag im Intranet oder per E-Mail, informiert werden, damit sie zum einen ihrePlanung auf eine zeitweise Systemabschaltung einrichten können, und zumanderen nach Änderungen auftretende Probleme richtig zuordnen können.

Die Konfigurationsänderungen sollten immer nur schrittweise durchgeführtwerden. Zwischendurch sollte immer wieder überprüft werden, ob die Ände-rungen korrekt durchgeführt wurden und das IT-System sowie die betroffenenApplikationen noch lauffähig sind.

Bei Änderungen an Systemdateien ist anschließend ein Neustart durchzufüh-ren, um zu überprüfen, ob sich das IT-System korrekt starten lässt. Für Pro-blemfälle sind alle für einen Notstart benötigten Datenträger vorrätig zu halten,z. B. Boot-Medien, Start-CD-ROM.

Vor Konfigurationsänderungen sollten von allen eventuell betroffenen Dateienund Verzeichnissen Datensicherungen angefertigt werden. Komplexere Kon-figurationsänderungen sollten möglichst nicht in den Originaldateien vorge-nommen werden, sondern in Kopien. Alle durchgeführten Änderungen solltennach dem Vier-Augen-Prinzip überprüft werden, bevor sie in den Echtbetriebübernommen werden.

Bei IT-Systemen mit hohen Verfügbarkeitsanforderungen ist auf Ersatzsyste-me zurückzugreifen bzw. zumindest ein eingeschränkter IT-Betrieb zu ge-währleisten. Das Vorgehen kann sich dabei idealerweise nach dem Not-fall-Handbuch richten.

Die durchgeführten Konfigurationsänderungen sollten Schritt für Schritt notiertwerden, so dass bei auftretenden Problemen das IT-System durch sukzessiveRücknahme der Änderungen wieder in einen lauffähigen Zustand gebrachtwerden kann (siehe auch M 2.34 Dokumentation der Veränderungen an einembestehenden System).

Prüffragen:

- Werden die Benutzer über Wartungsarbeiten in geeigneter Weiseinformiert?

- Werden von allen Dateien, an denen Änderungen vorgenommen werdenmüssen, Datensicherungen angelegt?



M 4.393 Umfassende Ein- undAusgabevalidierung beiWebanwendungen und Web-Services


Alle an eine Webanwendung oder einen Web-Service übergebenen Daten,unabhängig von Kodierung oder Form der Übermittlung, müssen als potenziellgefährlich behandelt und entsprechend gefiltert werden. Durch eine zuverläs-sige und gründliche Filterung der Ein- und Ausgabedaten mittels einer Validie-rungskomponente kann ein wirksamer Schutz vor gängigen Angriffen erreichtwerden. Hierbei sollten sowohl die Eingabedaten von Benutzern an die We-banwendung als auch die Ausgabedaten der Webanwendung an die Clientsoder an nachgelagerte Systeme wie zum Beispiel Datenbanken gefiltert undtransformiert (output encoding) werden. Entsprechendes gilt für die Aufrufpa-rameter und Rückgabewerte von Web-Services. Dadurch wird sichergestellt,dass nur erwartete und keine schadhaften Daten verarbeitet oder ausgegebenwerden.

Ist es für einzelne Funktionen notwendig, den Datenfilter weniger restriktiv zusetzen, muss dies explizit beim Zugriff auf die Daten definiert und dokumentiertwerden. Zusätzlich ist es möglich, kontextsensitive Filter in der Geschäftslogikder Anwendung oder in den Hintergrundsystemen zu nutzen.

Für eine sichere Verarbeitung der Daten sollten folgende Punkte bei der Um-setzung und der Konfiguration der Validierungskomponente berücksichtigtwerden:

Identifizierung der Daten

Damit die Ein- und Ausgabedaten umfassend validiert werden können, müs-sen zunächst alle zu verarbeitenden Datenstrukturen (zum Beispiel E-Mail-Adresse) und die darin zulässigen Werte identifiziert werden. Für jede Daten-struktur sollte eine entsprechende Validierungsroutine umgesetzt werden. Ne-ben der Datenstruktur sollte auch die Art und Weise der Datenverarbeitungerfasst werden (zum Beispiel Weiterleitung an einen Interpreter, Rückgabe anden Client, Speicherung in einer Datenbank).

Berücksichtigung aller Daten und Datenformate

Die Validierungskomponente sollte alle zu verarbeitenden Datenformate undverwendeten Interpreter berücksichtigen. Typische Datenformate bei Weban-wendungen sind zum Beispiel personenbezogene Daten (Name, Telefonnum-mer, Postleitzahl), Bilder, PDF-Dateien und formatierte Texte. Typische In-terpreter für Daten, die von Webanwendungen und Web-Services verarbeitetoder ausgegeben werden, sind zum Beispiel HTML-Renderer, SQL-, XML-,JSON-, LDAP-Interpreter und das Betriebssystem.

Daten können durch unterschiedliche Techniken auf ihre Gültigkeit geprüftwerden. So kann die Validierungskomponente den Wertebereich der Einga-ben überprüfen oder es können beispielsweise reguläre Ausdrücke verwen-det werden, um erlaubte Zeichen und die Länge der erwarteten Daten zu va-lidieren. Die Gültigkeit von XML-Daten kann unter anderem mithilfe des ent-sprechenden XML-Schemas überprüft werden. Darüber hinaus stellen Fra-



meworks und Bibliotheken für gängige Datenformate entsprechende Validie-rungsfunktionen bereit.

Die folgenden Zeichen werden gewöhnlich von in Webanwendungen oderWeb-Services eingesetzten Programmen interpretiert und können daher fürdas Einschleusen von schadhaftem Code genutzt werden. Aus diesem Grundsollten sie bei der Filterung berücksichtigt werden:

Nullwert, Zeilenvorschub, Wagenrücklauf, Hochkommata, Kommas, Schräg-striche, Leerzeichen, Tabulator-Zeichen, größer als und kleiner als, XML- undHTML-Tags.

Diese Aufzählung erhebt keinen Anspruch auf Vollständigkeit. Zudem könnendie Interpreter-Zeichensätze (zum Beispiel SQL-Syntax) bei unterschiedlichenProdukten variieren. Beispiele für kritische Zeichen werden im Abschnitt Po-tenziell gefährliche Zeichen für Interpreter in Hilfsmittel zum Baustein Weban-wendungen aufgeführt.

Neben den eigentlichen Nutzdaten (zum Beispiel Formular-Parameter in GET-oder POST-Variablen) sind auch Daten anderer Herkunft (Sekundärdaten) zuvalidieren. Dazu zählen beispielsweise:

- Namen von Form-Variablen (Sie können ebenso wie der Wert der Form-Variablen beliebig manipuliert werden),

- HTTP-Header-Felder (Header-Felder in HTTP-Requests und -Responsessollten ausschließlich ASCII-Zeichen enthalten und zum Beispiel keineZeilenvorschubzeichen wie \r\n),

- Session-IDs (zum Beispiel aus Cookies).

Automatisierte Aufrufe durch den Client zum Beispiel durch Ajax- beziehungs-weise Flash-Skripte oder JSON-Requests sind ebenfalls zu prüfen.

Bei den Hintergrundsystemen ist eine (gegebenenfalls erneute) Validierungder Daten vorzunehmen. Dies gilt auch dann, wenn Daten beispielsweise nacheinem erfolgten Schreibvorgang in die Datenbank wieder ausgelesen werden,da die Daten auch in der Datenbank zwischenzeitlich geändert worden seinkönnen.

Schadhafter Code kann aber auch über einen Weg übermittelt werden, dernicht von der Webanwendung oder dem Web-Service kontrolliert werden kann(zum Beispiel FTP, NFS). Kann ein Angreifer über diese Dienste Dateien än-dern oder erzeugen, die von der Webanwendung oder dem Web-Service in-tegriert werden, so kann Schadcode über diesen Umweg eingebettet werden.Bei dem sogenannten Cross-Channel-Scripting wird auf diese Weise JavaS-cript-Code eingefügt, der ähnlich wie bei persistentem Cross-Site-Scriptingvom Browser ausgeführt wird. Daher sollten unabhängig von der Quelle im-mer alle Daten vor der Ausgabe an die Benutzer oder der Weiterverarbeitungdurch die Anwendung validiert werden.

Serverseitige Validierung

Üblicherweise greifen die Benutzer mit generischen Clients (zum BeispielWeb-Browser) auf die Webanwendung zu. Diese Clients befinden sich nichtim Sicherheitskontext der Webanwendung, sondern stehen unter der Kontrol-le der Benutzer. In gleicher Weise kann sich auch ein Web-Service nicht dar-auf verlassen, dass die aufrufende Anwendung die Daten überprüft hat. DieDatenvalidierung ist daher als serverseitiger Sicherheitsmechanismus auf ei-nem vertrauenswürdigen IT-System umzusetzen.



Werden Daten zusätzlich durch Code von der Webanwendung clientseitig ver-arbeitet (zum Beispiel JavaScript-Code), so sollten diese Daten auch auf demClient validiert werden. Die ausgelieferten Skripte der Webanwendung solltenhierbei die entsprechenden Validierungsroutinen mitliefern. Werden die Datenim nachgelagerten Verarbeitungsprozess an den Server gesendet, so ist zubeachten, dass die clientseitige Prüfung die serverseitige Validierung nicht er-setzen kann.

Validierungsansatz

Bei der Datenvalidierung wird zwischen dem White-List- und dem Black-List-Ansatz unterschieden.

Bei dem White-List-Ansatz werden ausschließlich solche Daten zugelassen,die in der Liste enthalten sind. Dabei werden, ausgehend von einer möglichstkleinen Zeichenmenge, Regeln erstellt, die Daten in einem festgelegten Zei-chenraum zulassen und Daten zurückweisen, die abweichende Zeichen ent-halten. Hierbei sollten komplexe Regeln durch die sequenzielle Verwendungeinfacher Regeln abgebildet werden.

Dagegen werden bei einem Black-List-Ansatz solche Daten als unzulässig ein-gestuft und abgewiesen, die in der Liste enthalten sind. Alle Daten, die nichtexplizit verboten sind, werden bei diesem Ansatz akzeptiert.

Bei dem Black-List-Ansatz besteht jedoch die Gefahr, dass nicht alle Variatio-nen unzulässiger Daten berücksichtigt und somit erkannt werden. Daher sollteder White-List-Ansatz dem Black-List-Ansatz vorgezogen werden.

Kanonisierung vor der Validierung

Daten können in verschiedenen Kodierungen (zum Beispiel UTF-8, ISO8859-1) und Notationen (zum Beispiel bei UTF-8 ist "." = "2E" = "C0 AE")vorliegen. Abhängig vom angewendeten Kodierungsschema kann der gleicheWert demnach unterschiedlich interpretiert werden. Findet eine Validierungder Daten ohne Berücksichtigung der Kodierung und der Notation statt, sowerden gegebenenfalls schadhafte Daten nicht erkannt und gefiltert. Dahersollten alle Daten vor der Validierung in eine einheitliche, normalisierte Formüberführt werden. Dieser Vorgang wird als Kanonisierung der Daten bezeich-net. Die so dargestellten Daten werden dann weiterverarbeitet. Bei der Ver-wendung von AJAX sollte zudem für das Nachladen die Eigenschaft textCon-tent anstatt von innerHTML genutzt werden, da textContent automatisch eineEnkodierung vornimmt.

Darüber hinaus sollte das Kodierungsschema bei der Auslieferung von Da-ten durch die Webanwendung explizit gesetzt werden (zum Beispiel über denContent-Type-Header: charset=ISO-8859-1). Auch bei Web-Services solltendie verwendeten Kodierungen den Client-Systemen mitgeteilt werden, bei-spielsweise in den entsprechenden XML-Tags.

Kontextsensitive Maskierung der Daten

Falls potenziell schadhafte Daten von einer Webanwendung oder einem Web-Service verarbeitet werden müssen (zum Beispiel Zeichen mit einer Bedeu-tung für verwendete Interpreter) und somit eine Filterung nicht durchgeführtwerden kann, müssen diese Daten maskiert und so in eine andere Darstel-lungsform überführt werden. In dieser maskierten Form werden die Daten nichtmehr als ausführbarer Code interpretiert. Da die Maskierung Interpreter-spe-zifisch ist, müssen alle verwendeten Interpreter berücksichtigt werden (zum



Beispiel SQL, LDAP). Die Maskierung muss demnach kontextsensitiv für daserwartete Ein- und Ausgabeformat und die Interpretersprache durchgeführtwerden. Aufgrund der Komplexität und der spezifischen Anforderungen unter-schiedlicher Interpretersprachen wird empfohlen, für die Maskierung speziali-sierte Bibliotheken einzusetzen.

Es sollte eine Maskierung aller Zeichen vorgenommen werden, die als unsi-cher für den beabsichtigten Interpreter eingestuft werden. Dazu zählen zumBeispiel:

- unerwartetes JavaScript und HTML zur Auslieferung an den Client (zumBeispiel den Web-Browser),

- unerlaubt eingefügte SQL-Statements an die Datenbank (zum Beispielaus Eingaben in Formularfeldern),

- Befehle an das Betriebssystem (zum Beispiel in manipulierten HTTP-Va-riablen).

Eine Maskierung kann durch eine Überführung der betroffenen Daten bezie-hungsweise Metazeichen der jeweiligen Interpretersprache in sogenannte Zei-chenreferenzen erfolgen. Das folgende Beispiel zeigt ausgewählte HTML-Zei-chen mit den entsprechenden Zeichenreferenzen (engl. HTML-Entities):

- & => &- < => <- > => >- " => "- ' => '

Hier ist darauf zu achten, dass &-Zeichen im ersten Durchlauf ersetzt werdenund dass keine Mehrfach-Maskierung erfolgt, da dieses Zeichen in anderenZeichenreferenzen als Metazeichen wiederverwendet wird.

Verwendung eines eigenen Markups zur Filterung von HTML-Tags

Falls die Webanwendung HTML-Formatierungstags in Benutzereingaben er-fordert (zum Beispiel zur Formatierung von Benutzer-Beiträgen), sollten er-laubte HTML-Tags von problematischen Tags unterschieden und gefiltert wer-den (siehe auch Abschnitt Kontextsensitive Maskierung der Daten).

Bei diesem Ansatz besteht das hohe Risiko, problematische Tags (beispiels-weise <script>) zu übersehen. Auch scheinbar harmlose Tags lassen sich teil-weise über Attribute wie "onMouseOver" zur Ausführung von Code missbrau-chen. Daher sollte der alternative Ansatz, für das Markup des Benutzers ei-gene Markup-Tags zu definieren (zum Beispiel BBCode), vorgezogen wer-den. Diese Markup-Tags werden dann von der Anwendung in die zugehörigenHTML-Tags übersetzt. Herkömmliche Tags beziehungsweise problematischeZeichen werden nach wie vor gefiltert.

Ein mögliches Verfahren, wenn ein einfaches Markup zugelassen werden soll,ist die Verwendung von { und } statt < und >. Fett würde dann als {F}Dies istfett{/F} geschrieben und ein Bild könnte auf diese Weise platziert: {img src=/images/img.gif width=1 height=1 img}.

Hierbei darf die Umwandlung in HTML nicht einfach geschweifte Klammerndurch spitze Klammern ersetzen, sondern muss jedes Tag als Ganzes anse-hen:

- {img nach <img,- img} nach >,- src=Datei nach src="Datei" (wobei Datei zusätzlich zu filtern ist).



Wenn HTML-Tags zugelassen sind, ist grundsätzlich darauf zu achten, dassmindestens die folgenden Tags nicht erlaubt sind:

- applet- base- iframe- link- object- script- style

Mithilfe dieser Tags können beliebige Inhalte in die Webseite eingefügt wer-den. Diese dürfen daher nicht genutzt werden können.

Behandlung von Fehleingaben (Sanitizing)

Anstatt Daten aufgrund eines unerwarteten Datenformats oder Zeichens ab-zulehnen, können Fehleingaben korrigiert und automatisch transformiert wer-den (engl. sanitize). Dadurch soll eine benutzerfreundliche Eingabe der Datenin unterschiedlichen Schreibweisen ermöglicht werden. Für eine Weiterverar-beitung lassen sich die Daten von unerwarteten Zeichen säubern (zum Bei-spiel die Telefonnummer (0049)-201-12345678 kann in das nur aus Zahlenbestehende Format 004920112345678 überführt werden).

Eine Säuberung kann darin bestehen, Zeichen zu löschen, zu ersetzen oderzu maskieren (siehe auch Abschnitt Kontextsensitive Maskierung der Daten).

Beim Sanitizing besteht die Gefahr, dass Änderungen an den Daten zu einerneuen Komplexität, neuen Angriffsvektoren oder einer Missinterpretation füh-ren. Daher sollte Sanitizing nach Möglichkeit vermieden und nur in Fällen an-gewendet werden, in denen ein Missbrauch des Sanitizing ausgeschlossenwerden kann.

Falls die Webanwendung oder der Web-Service fehlerhafte Daten erkannt hat,sollten Fehler, die auf eine bewusste Manipulation hindeuten (zum Beispieleine veränderte Session-ID) nicht automatisch korrigiert, sondern abgelehntwerden. Darüber hinaus sollten Eingabedaten, die mit bestimmungsgemäßerBrowser- beziehungsweise Client-Bedienung nicht eintreten können, grund-sätzlich abgelehnt werden. Dazu zählen zum Beispiel:

- Zusätzliche oder fehlende Formular-Parameter,- Session-Cookies mit unerwarteten Zeichen oder ungültiger Länge,- Unerwartete Werte bei der Übertragung von Formular-Parametern aus

vordefinierten HIDDEN-, SELECT- oder CHECKBOX-Feldern,- Abweichender oder unerwünschter Übertragungsweg der Parameter (zum

Beispiel GET, POST, Cookie).

Bei einer Säuberung der Daten sollte die geschachtelte Eingabe von Angriffs-vektoren berücksichtigt werden. Problematisch ist zum Beispiel der auf den er-sten Blick vernünftig erscheinende Filter s/<script>//g; (hier in Perl RegEx-Syn-tax geschrieben), um <script>-Tags im Eingabestrom zu löschen. Dieser kannjedoch mit einer geschachtelten Eingabe (zum Beispiel <sc<script>ript>) um-gangen werden. Es ist daher rekursiv zu filtern. Im Zweifelsfall sind die Einga-bedaten abzulehnen.

Grundsätzlich sollte bei einer Ablehnung der Daten die angeforderte Aktionebenfalls abgebrochen und eine neutrale Fehlermeldung ausgegeben werden(siehe auch M 4.400 Restriktive Herausgabe sicherheitsrelevanter Informatio-nen bei Webanwendungen und Web-Services). Bei Webanwendungen oder



Web-Services mit hohem Schutzbedarf sollte zusätzlich die Sitzung invalidiert(abgebrochen) werden.

Prüffragen:

- Werden alle Daten (Ein- und Ausgabedaten) und Datenströme derWebanwendung oder des Web-Service (zum Beispiel zwischen Benutzer,Webanwendung, Clientsystemen und Hintergrundsystemen) bei derValidierung berücksichtigt?

- Werden auch Sekundärdaten (wie beispielsweise Session-IDs) bei derValidierung berücksichtigt?

- Führt die Webanwendung oder der Web-Service eine serverseitigeValidierung der Daten auf einem vertrauenswürdigen IT-System durch?

- Führt die Webanwendung oder der Web-Service vor der Validierung eineKanonisierung der Daten durch?

- Findet in der Webanwendung oder dem Web-Service einekontextsensitive Validierung der Daten unter Berücksichtigung deserwarteten Interpreters der Daten statt?

- Bei Webanwendungen/Web-Services mit automatischer Behandlung vonFehleingaben (engl. Sanitizing): Wird die Behandlung von Fehleingabensicher umgesetzt?



M 4.394 Session-Management beiWebanwendungen und Web-Services


Webanwendungen und Web-Services verwenden in der Regel das zustands-lose Protokoll HTTP zur Übertragung der Daten. Es unterstützt keine Zuord-nung zusammengehörender Anfragen zu einem Benutzer wie zum Beispieleinzelne Seitenaufrufe zur Füllung eines virtuellen Warenkorbs. Um zusam-mengehörende Anfragen eines Benutzers zu erkennen und einer Sitzung zu-zuordnen, wird eine Session-ID (zum Beispiel nach erfolgreicher Anmeldung)vergeben, die anschließend bei jedem Seitenaufruf, oder bei jeder Interaktionmit dem Web-Service, übertragen wird. Die Session-ID wird typischerweisevon der Webanwendung oder dem Web-Service selbst erzeugt. Verwendetein Web-Service den Standard WS-SecureConversation, kann der SecurityContext, und damit auch der Identifikator für die Sitzung, auch von einem de-dizierten Security Token Service erzeugt werden.

Wenn sich der Benutzer bei der Webanwendung oder dem Web-Service an-gemeldet hat, ist die Session-ID vergleichbar mit seinen Zugangsdaten. DieWebanwendung identifiziert mit ihr bei jedem Seiten- oder Dienstaufruf denBenutzer und ordnet ihn einer (gegebenenfalls privilegierten) Sitzung zu. Nut-zen Unbefugte die Session-ID, werden sie als legitime Benutzer identifiziertund können die Anwendung oder den Dienst im Namen des Opfers verwen-den.

Das Session-Management einer Webanwendung oder eines Web-Service hatzur Aufgabe, die Sitzungen zu verwalten und neue Session-IDs zu vergeben.Dabei sollten die folgenden Anforderungen und Aspekte berücksichtigt wer-den.

Anforderungen an die Session-ID

Es ist zu beachten, dass die Gültigkeitsdauer einer Session-ID (siehe auchAbschnitt Beschränkte Sitzungsdauer) deutlich kleiner sein sollte als die Zeit,die ein Angreifer zum Erraten einer Session-ID benötigt. Dies kann mit einerFormel für eine Webanwendung oder einen Web-Service individuell bewertetwerden (siehe Formel zur Berechnung der Bewertungsgrundlage für Sessi-on-IDs in Hilfsmittel zum Baustein Webanwendung).

Die Session-ID sollte mindestens folgende Anforderungen erfüllen:

- Die Session-ID muss mithilfe kryptografischer Zufallszahlengeneratorenzufällig erzeugt werden und sollte eine Entropie von mindestens 64 Bithaben, damit sie von einem potentiellen Angreifer nicht erraten werdenkann. Um die Entropie der Session-ID zu erhöhen, kann beispielsweisedie Länge erhöht (zum Beispiel 128 Bit) und der Zeichenraum der Ses-sion-ID (zum Beispiel alphanumerische Zeichen und Sonderzeichen) ver-größert werden. Als Richtwert sollte hierbei die Länge der Session-ID min-destens die doppelte Anzahl an Bits haben wie die Anzahl an Entropie-Bitsder Session-ID. Demzufolge sollte die Session-ID mindestens 128 Bit langsein. Unter der Annahme, dass ein Zeichen durch 8 Bit dargestellt wird,bestünde eine solche Session-ID aus mindestens 16 Zeichen (128 Bit / 8= 16 Byte).



- Es sollten keine extern bekannten oder erratbaren Daten (zum BeispielRFC-Adresse, Uhrzeit) in die Berechnung der Session-ID einfließen, so-fern dies die Entropie nicht tolerierbar verringert.

- Unterstützt das der Webanwendung zugrunde liegende Framework dieGenerierung von Session-IDs, sollte vorzugsweise die Funktion des Fra-meworks verwendet werden. Die Funktionalität von führenden Frame-works ist in der Regel getestet und unterstützt die sichere Erzeugung vonSession-IDs. Eine fehleranfällige Neuentwicklung sollte daher vermiedenwerden.

- Wird ein Framework zur Verwaltung und Erzeugung der Session-IDs ver-wendet, so ist auf eine sichere Konfiguration des Frameworks zu achten,sodass die zuvor genanten Anforderungen an die Session-ID erfüllt sind.

Schutz vor unbefugtem Zugriff auf die Session-ID

Die Session-ID kann sowohl in der URL eines Requests (GET-Methode),im Rumpf des Requests (POST-Methode) oder als Cookie im Header desRequests übertragen werden. Wird bei Web-Services der Standard WS-Se-cureConversation eingesetzt, so ist die Session-ID Teil des XML-Elementswsc:SecurityContextToken, welches innerhalb der SOAP-Header übertragenwird.

Wenn Daten mithilfe der GET-Methode übermittelt werden, können sie vonbeteiligten IT-Systemen gespeichert und dadurch von Dritten eingesehen wer-den (zum Beispiel im Browser-Verlauf, auf Bildschirmfotos, Seitenkopien oderAusdrucken). Daher sollte die Session-ID nicht über die GET-Methode (also inder URL) übertragen werden. Für Webanwendungen oder Web-Services mithohem Schutzbedarf ist dies nicht erlaubt. Stattdessen sollte die Session-IDvorzugsweise in Cookies übertragen werden.

Erfordert die Anwendung die GET-Methode (zum Beispiel aus Gründen derKompatibilität mit Clients, die keine Cookies verarbeiten können), sind folgen-de Punkte zu beachten:

- Benutzer sollten auf die genannten Gefahren hingewiesen werden undbeim Verlassen des Rechners die Sitzung beenden oder den Rechnersperren.

- Die Benutzer sollten angewiesen werden, keine gespeicherten Seiten oderBildschirmfotos von Seiten der Webanwendung zu versenden, bei der dieSession-ID in der URL sichtbar ist.

- Bei Nutzung der Webanwendung über einen öffentlichen Rechner sollteeine Meldung darauf hinweisen, dass der Browser-Verlauf nach Beendender Sitzung gelöscht werden sollte.

- Durch sehr lange Session-IDs kann das Abschreiben und das zufälligeMitlesen erschwert werden.

- Bei der Verlinkung auf externe Seiten darf die Session-ID nicht übertra-gen werden. Dies gilt sowohl für die Übertragung in der URL als auch fürdas Referrer-Feld. Daher sollte bei Verlinkungen auf externe Seiten eineerzwungene Weiterleitung erfolgen, welche das Referrer-Feld bereinigt.

Zum Schutz vor unbefugtem Mitlesen der Session-ID sollte nach einer erfolg-reichen Anmeldung die Kommunikation über eine sichere Verbindung statt-finden. Dies kann über eine Transportsicherung, beispielsweise mittels SSL/TLS(siehe M 5.66 Clientseitige Verwendung von SSL/TLS) oder mittels WS-SecureConversation realisiert werden. Die Session-ID kann über eine unge-sicherte Verbindung übertragen werden, wenn mit der bestehenden Sitzungkeine zugriffsgeschützten Bereiche der Webanwendung verwendet werdenkönnen. Gewöhnlich ist der Benutzer in diesem Fall noch nicht authentisiert.



Der Zugriff auf die Session-ID als Authentisierungsmerkmal sollte streng re-glementiert werden. Wird die Session-ID in einem Cookie übertragen, sollteder clientseitige Zugriff auf diesen Cookie nach Möglichkeit durch das Setzenfolgender Flags eingeschränkt werden (für eine detaillierte Beschreibung derCookie-Flags siehe M 4.401 Schutz vertraulicher Daten bei Webanwendun-gen):

- Path (zum Beispiel /webapp/),- Secure und- HttpOnly.

Beschränkte Sitzungsdauer

Eine Webanwendung oder ein Web-Service muss Benutzern die Möglichkeitgeben, eine bestehende Sitzung nach ihrer Nutzung explizit zu beenden. Da-her muss auf allen Webseiten, für deren Abruf eine Authentisierung des Be-nutzers notwendig ist, eine deutlich sichtbare Abmeldemöglichkeit bestehen.Bei der Verwendung von WS-SecureConversation sollte der Security Contexteiner Sitzung nach der Nutzung des Dienstes explizit durch das Senden einerNachricht "WS-Trust Cancel" invalidiert werden. Nach erfolgter Abmeldungsollte die Sitzung vollständig beendet werden und die Session-ID ihre Gültig-keit verlieren. Darüber hinaus sollte der Benutzer bei der Verwendung vonWebanwendungen und Web-Services für folgende Verhaltensweisen sensibi-lisiert werden:

- Ist der Benutzer angemeldet, sollte er sich nach Abschluss der Tätigkeitenvon der Webanwendung ordnungsgemäß abmelden.

- Falls beim letzten Besuch keine Abmeldung erfolgt ist, sollte der Benutzerbei dem nächsten Anmeldevorgang an der Webanwendung darauf hinge-wiesen werden, sich zukünftig abzumelden.

Ungenutzte, bestehende Sitzungen bieten eine Angriffsfläche für Brute-For-ce-Angriffe auf die Session-ID. Daher sollten Sitzungen nach einem Zeitin-tervall der Inaktivität ihre Gültigkeit verlieren (Idletime). Darüber hinaus sollteeine maximale Gültigkeits-Lebensdauer vergeben werden (Timeout), sodassauch die Session-IDs von aktiven Sitzungen eine begrenzte Gültigkeit haben.Diese sollte für die Sitzungen so gering wie möglich gewählt werden, sodassBrute-Force-Angriffe erschwert werden, wobei die Benutzbarkeit der Weban-wendung hierbei nicht unnötig eingeschränkt werden sollte. Die Formel ausdem Abschnitt Anforderungen an die Session-ID kann für die Ermittlung einerangemessenen Gültigkeitsdauer herangezogen werden.

Treten bei der Nutzung der Webanwendung oder des Web-Service schwer-wiegende Fehler auf, sollten angeforderte Aktionen abgebrochen und zusätz-lich die Sitzung beendet werden. Schwerwiegende Fehler sind zum Beispielauftretende Ausnahmefehler (Exceptions) und erkannte Angriffsversuche. Beieinem hohen Schutzbedarf sollten noch engere Kriterien in Erwägung gezo-gen werden, die zur Invalidierung der Sitzung führen (zum Beispiel ungültigeEingaben, Aufruf fehlender Seiten).

Bei der Invalidierung sollten die Sitzungsdaten server- und clientseitig voll-ständig gelöscht werden, sodass die Sitzung serverseitig nicht weiter akzep-tiert wird und clientseitig keine Informationen über zuvor aufgebaute Sitzun-gen verbleiben. Dies kann zum Beispiel durch Löschen des Cookies mit derSession-ID erfolgen.

Darüber hinaus können mehrere parallele Sitzungen unter dem gleichen Be-nutzerkonto verhindert werden. Eine bestehende Sitzung kann bei erneuterAnmeldung invalidiert werden, sodass nur die neue Sitzung gültig bleibt. Al-



ternativ ist es beispielsweise möglich, die erste Sitzung über einen begrenztenZeitraum (zum Beispiel 15 Minuten) aufrechtzuerhalten, bevor sie invalidiertwird. Dabei sollte dem Benutzer bei der Anmeldung über eine parallele, zweiteSitzung eine Meldung über die ablaufende, erste Sitzung eingeblendet wer-den. Auf diese Weise können noch bestehende, aber nicht mehr verwendeteSitzungen nach erneuter Anmeldung nicht oder nur eingeschränkt unbefugtvon Dritten genutzt werden.

Zum Schutz vor Session-Fixation-Angriffen sollte nach erfolgter Anmeldungeine bereits bestehende Session-ID durch eine neue ersetzt werden.

Ebenso sollte nach einem Wechsel von einem ungesicherten Kommunikati-onskanal (HTTP) auf einen gesicherten Kommunikationskanal (HTTPS) eineneue Session-ID vergeben werden, da die Session-ID bei der Übertragungüber einen ungesicherten Kanal mitgelesen worden sein könnte.

Schutz der Sitzungsdaten

Zum Schutz der Vertraulichkeit sollten die anfallenden Sitzungsdaten (zumBeispiel Warenkorb) ausschließlich serverseitig auf einem vertrauenswür-digen IT-System gespeichert werden. Darüber hinaus sollten die Datenvor unbefugtem Zugriff von anderen Benutzern durch eine Zugriffskontrol-le geschützt werden. Falls die Webanwendung oder der Web-Service ei-ne clientseitige Speicherung der Sitzungsdaten erfordert, sollte ebenfallsM 4.401 Schutz vertraulicher Daten bei Webanwendungen für die Speiche-rung von Daten auf dem Client beachtet werden.

Zuordnung einer Sitzung anhand zusätzlicher Attribute

Neben der Session-ID können weitere Merkmale zur Zuordnung zwischen Be-nutzer und Sitzung verwendet werden (zum Beispiel die IP-Adresse). Hier-durch kann die unbefugte Nutzung bestehender Sitzungen erschwert werden,da ein Angreifer für eine erfolgreiche Übernahme der Sitzung neben einer gül-tigen Session-ID die zusätzlichen Merkmale kennen muss. Die Verwendungvon zusätzlichen Attributen zur Zuordnung einer Sitzung ist zumindest bei We-banwendungen mit hohem Schutzbedarf zu berücksichtigen.

Wird die IP-Adresse als zusätzliches Merkmal für die Sitzungszuordnung ver-wendet, so ist diese serverseitig zu speichern und zu prüfen. Wechselt die IP-Adresse im Laufe einer Sitzung, so sollte dies bei Anwendungen mit hohemSchutzbedarf als Angriffsversuch gewertet und demzufolge die Sitzung inva-lidiert werden. Dabei ist jedoch zu berücksichtigen, dass die IP-Adresse nichtimmer einem Benutzer eindeutig zugeordnet werden kann. Erfolgt die Verbin-dung einiger Benutzer der Webanwendung über einen Proxy mit gleicher (zumBeispiel Reverse-Proxy) oder wechselnder IP-Adresse (zum Beispiel wech-selnde, ausgehende Proxys), besteht die Gefahr, dass die IP-Adressen dieserBenutzer nicht eindeutig einer Sitzung zugeordnet werden können. Es solltesomit bedacht werden, dass einige Benutzer die Webanwendung möglicher-weise nur eingeschränkt oder gar nicht nutzen können.

Wenn der Referrer als Identitätsmerkmal verwendet wird, kann auf einen fe-sten Teil des Referrer-Pfades geprüft werden, der für alle Zugriffe identischbleibt (zum Beispiel die Domäne der Webanwendung). Die Benutzer müssendemnach eine Webseite der Webanwendung im Referrer vorweisen. Hierbeiist zu berücksichtigen, dass einige Browser eine Deaktivierung oder benut-zerseitige Manipulation der Referrer-Übermittlung erlauben und Content-Filterdieses Feld gegebenenfalls filtern.



Die Identitätsmerkmale können zum Schutz vor unbefugter Nutzung der Sit-zung auf mehrere Eigenschaften des HTTP-Headers verteilt werden. Denkbarsind zum Beispiel HTTP-Header-Informationen wie

- die Browsertypenbezeichnung (User-Agent-Header),- unterstützte Formate und Sprachen des Clients (Accept- und Accept-Lan-

guage-Header) undder Referrer (Referrer-Header).

Aufgrund der teilweise geringen Variationsbreite der genannten Merkmale desHTTP-Headers ist der zusätzlich erreichte Schutz begrenzt. Dagegen erhöhtsich der Umsetzungsaufwand und unter Umständen die Komplexität bei derFehlersuche. Aus diesem Grund sollte im Einzelfall abgewogen werden, obder zusätzlich erreichte Schutz den Umsetzungsaufwand rechtfertigt.

Eigenimplementierungen vermeiden

Kann für die Sitzungsverwaltung einer Web-Anwendung oder eines Web-Ser-vice auf eine erprobte Implementierung in einem Framework oder einen ver-breiteten Standard (wie WS-SecureConversation) zurückgegriffen werden, soist dies gegenüber einer Eigenimplementierung in jedem Fall zu bevorzu-gen, da sich Eigenimplementierungen dieser sicherheitskritischen, komplexenFunktion sehr häufig als angreifbar erweisen.

Prüffragen:

- Hat die Session-ID der Webanwendung beziehungsweise des Web-Service eine ausreichende Entropie, um dem Erraten der Session-ID(zum Beispiel durch einen Brute-Force-Angriff) standzuhalten?

- Wird die Vertraulichkeit der Session-ID bei der Übertragung undclientseitigen Speicherung ausreichend geschützt?

- Hat die Sitzung eine begrenzte Gültigkeit (Timeout) und ist diesegemessen an den Anforderungen zur Nutzung der Webanwendung oderdes Web-Service möglichst kurz gewählt worden?

- Erfolgt ein Wechsel der Session-ID nach erfolgreicher Authentisierung?- Werden alle Sitzungsdaten (sowohl server- als auch clientseitig) nach der

Invalidierung der Sitzung ungültig und gelöscht?- Kommt für die Sitzungsverwaltung eine erprobte Implementierung oder

ein verbreiteter Standard zum Einsatz?



M 4.395 Fehlerbehandlung durchWebanwendungen und Web-Services


Tritt während des Betriebs einer Webanwendung oder eines Web-Services einFehler auf, sollte dieser so behandelt werden, dass ein konsistenter Zustandder Webanwendung gewährleistet ist und somit etwa der Schutz der Datenaufrechterhalten wird.

Eine Webanwendung oder ein Web-Service ist in einem inkonsistenten Zu-stand, wenn sie aufgrund eines Fehlers in einen unerwarteten Zustand über-führt wird und dadurch Daten unkontrolliert verarbeitet werden (zum Beispielkeine Fehlermeldung bei erfolgloser Speicherung von Daten).

Der konsistente Zustand einer Webanwendung oder eines Web-Service kannunter anderem durch folgende Ereignisse gefährdet werden:

- Absturz der Anwendung- unvollständig durchgeführte Transaktionen auf Anwendungsebene- Durchführung einer Aktion trotz Fehler (zum Beispiel bei unvollständigen

Prüfungen durch Sicherheitskomponenten)- Verhinderung von Diensten (Denial-of-Service)- Rechteausweitung (privilege escalation)- Ausführen von Schadcode (code execution)

Folgende Punkte sollten bei der Fehlerbehandlung berücksichtigt werden:

Vermeidung vertraulicher Informationen in Fehlermeldungen

Die Webanwendung muss dem Benutzer im Falle eines Fehlers neutrale, an-gepasste Fehlerseiten ausgeben, die keine vertraulichen Informationen bein-halten. Auch die Rückmeldungen von Web-Services sollten im Fehlerfall kei-ne vertraulichen Informationen, wie etwa interne Pfade oder die Versionsnum-mern von verwendeten Softwarekomponenten, enthalten. Siehe hierzu auchM 4.400 Restriktive Herausgabe sicherheitsrelevanter Informationen bei We-banwendungen und Web-Services.

Protokollierung der Fehler

Für eine vollständige Nachvollziehbarkeit aufgetretener Fehler müssen dieseals Ereignis gemäß M 4.397 Protokollierung sicherheitsrelevanter Ereignissevon Web-Anwendungen und Web-Services protokolliert werden.

Abbruch des Vorgangs nach Auftreten eines Fehlers

Treten Fehler im Zusammenhang mit Sicherheitskomponenten der Weban-wendung oder des Web-Service auf (zum Beispiel während der Autorisierungoder Authentisierung), muss die veranlasste Aktion abgebrochen und der Zu-griff auf die angeforderte Ressource oder Funktion abgewiesen werden. Esmuss gewährleistet sein, dass durch provozierte Fehler keine Sicherheitsme-chanismen umgangen werden können.

Für Webanwendungen oder Web-Services mit einem hohen Schutzbedarfsollte zusätzlich die Invalidierung einer gegebenenfalls bestehenden Sitzung



in Betracht gezogen werden (siehe auch M 4.394 Session-Management beiWebanwendungen und Web-Services).

Freigabe von reservierten Ressourcen

Im laufenden Betrieb belegen Webanwendungen und Web-Services Ressour-cen wie zum Beispiel Netz- oder Datei-Streams, um auf Hintergrundsysteme,zwischengespeicherte Zustände oder sonstige Daten zuzugreifen. Solangedie Webanwendung oder der Web-Service auf diese Ressourcen zugreift, sinddiese in der Regel für deren exklusiven Zugriff reserviert und können von an-deren Prozessen nicht verwendet werden.

Tritt ein Fehler auf, sollten zuvor reservierte Ressourcen (zum Beispiel ein Da-tei-Handle auf eine temporäre Datei) im Rahmen der Fehlerbehandlung frei-gegeben werden. Darüber hinaus sind zwischengespeicherte Daten bei derFehlerbehandlung zu löschen.

Unmittelbare Behandlung von Fehlern

Interne Fehler sollten von der Webanwendung oder dem Web-Service selbstbehandelt werden. Die Weiterleitung eines unbehandelten Fehlers an ande-re Komponenten (zum Beispiel Applikationsserver oder nachgelagerte Web-Services) kann zu einem Verlust von Informationen führen, die zur Behand-lung des Fehlers notwendig sind (zum Beispiel zur Freigabe von gebundenenRessourcen). Daher sollten unbehandelte Fehler nicht weitergeleitet werden.

Vermeidung einer zu hohen Fehlertoleranz

Sind Ursachen von Fehlerzuständen nicht vollständig geklärt, sollte der Fehlernicht zum Beispiel aufgrund der Bedienungsfreundlichkeit toleriert, sonderndie Aktion im Zweifelsfall abgebrochen werden. Schwerwiegende Fehler soll-ten immer zum Abbruch der Aktion führen.

Das Ziel sind robuste und fehlertolerante Webanwendungen und Web-Ser-vices, die bestimmungsgemäße Bedienung durch den Anwender von offen-sichtlichen Missbrauchsversuchen und schwerwiegenden Fehlern unterschei-den und dann angemessen reagieren können.

Prüffragen:

- Werden von der Webanwendung oder dem Web-Service ausschließlichFehlermeldungen ausgegeben, die keine vertraulichen Informationenbeinhalten?

- Ist eine Protokollierung von Fehlern vorgesehen?- Wird eine veranlasste Aktion im Fehlerfall abgebrochen und in der Folge

der Zugriff auf die angeforderte Ressource oder Funktion abgewiesen?- Sieht die Fehlerbehandlung eine Freigabe gebundener Ressourcen vor?- Werden Fehler möglichst von der gleichen Komponente behandelt, in der

der Fehler aufgetreten ist?



M 4.397 Protokollierungsicherheitsrelevanter Ereignissevon Web-Anwendungen undWeb-Services


Sicherheitsrelevante Ereignisse (zum Beispiel Zugriffe auf Ressourcen, Au-thentisierungsversuche) müssen nachvollziehbar protokolliert werden, damitim Stör- oder Fehlerfall oder nach Angriffsversuchen die Protokolldaten zurUrsachenfindung herangezogen werden können.

Neben den Empfehlungen in den Maßnahmen M 5.9 Protokollierung am Ser-ver und M 2.110 Datenschutzaspekte bei der Protokollierung sollten zusätzlichdie folgenden Punkte bei der Protokollierung sicherheitsrelevanter Ereignissevon Web-Anwendungen und Web-Services beachtet werden.

Zu protokollierende Ereignisse bei Web-Anwendungen und Web-Services

Zusätzlich zur Protokollierung auf den Server- und Hintergrundsystemen(zum Beispiel Betriebssystem, Web- und Applikationsserver, Datenbank) soll-te auch die Anwendung sicherheitsrelevante Ereignisse protokollieren. Minde-stens folgende Ereignisse sollten auf Anwendungsebene erfasst werden:

- erfolgreiche und erfolglose Anmeldeversuche an der Webanwendung oderdem Web-Service,

- fehlgeschlagene Autorisierungsversuche beim Zugriff auf Ressourcen(zum Beispiel Datenbankzugriffe) und Funktionen der Webanwendungoder des Web-Service,

- fehlgeschlagene Validierung von Ein- und Ausgabedaten,- fehlgeschlagene XML-Schema-Validierungen,- XML-Parser-Fehler,- aufgetretene Fehler (zum Beispiel Exceptions),- Änderungen von Berechtigungen für Benutzer oder Benutzergruppen der

Webanwendung oder des Web-Service (zum Beispiel Zugriffsrechte, Än-derung an der Web-Service-Policy),

- Änderungen an Benutzerkonten (zum Beispiel Passwortänderung),- Löschvorgänge der Webanwendung (zum Beispiel Beiträge),- erkannte Manipulationsversuche und unerwartete Änderungen (zum Bei-

spiel Anmeldeversuche mit ungültigen oder abgelaufenen Session-IDs),- administrative Funktionsaufrufe und Änderungen an der Konfiguration

(zum Beispiel Abruf von Benutzerdaten, Aktivierung und Deaktivierung derProtokollierung),

- Starten und Stoppen von Diensten,- Produktionsübernahme (Deployment) neuer oder bestehender Web-Ser-

vices.

Zu protokollierende Merkmale von Ereignissen

Um sicherheitsrelevante Vorgänge anhand von Protokolldaten nachvollziehenzu können, müssen grundlegende Merkmale der Ereignisse verfügbar sein.Daher sollten mindestens die folgenden Merkmale protokolliert werden:

- Datum,- Uhrzeit mit Zeitzone,



- assoziierter Benutzername,- betroffenes Objekt (zum Beispiel Benutzerkonto, Datei, Datenquelle),- Status der Aktion (zum Beispiel fehlgeschlagen, erfolgreich),- Ort des Auftretens (zum Beispiel Komponente),- Aktion (zum Beispiel Authentisierung, Autorisierung),- Schweregrad (zum Beispiel Information, Warnung, Fehler).

Darüber hinaus kann es auch hilfreich sein, folgende Merkmale zu protokol-lieren:

- Source-IP-Adresse,- Referenzen auf die SessionID (nicht die SessionID selbst),- IT-System, an dem der Fehler aufgetreten ist,- Softwarestand (Version) der Webanwendung.

Vertrauliche und sicherheitsrelevante Daten (zum Beispiel SessionID, Zu-gangsdaten) sollten nicht protokolliert werden.

Geeignete Datenformate und Mechanismen

Die protokollierten Daten sollten in einem einheitlichen Format gespeichertwerden, damit eine effiziente Auswertung möglich ist. Die Protokollierungs-komponente der Webanwendung oder des Web-Service sollte aus diesemGrund ein Datenformat verwenden, das in bestehende Lösungen integriertwerden kann. Wird beispielsweise eine zentrale Komponente für die Auswer-tung der Protokolldaten verwendet, so sollten Datenformate gewählt werden,die diese Komponente unterstützt.

Serverseitige Protokollierung durch eine zentrale Komponente

Die Protokollierung der Webanwendung oder des Web-Service ist ausschließ-lich serverseitig durchzuführen, da nur auf diese Weise die Protokolldatenzentral ausgewertet werden können. Die Protokolldaten sollten von einer ein-zigen, zentralen Protokollierungskomponente der Webanwendung oder desWeb-Service und nicht von unterschiedlichen Protokollierungskomponentenerhoben werden.

Eine fehleranfällige Neuentwicklung der Protokollierungskomponente solltevermieden werden. Stattdessen sollte auf die Funktionalität etablierter Frame-works zurückgegriffen werden, die in der Regel einen zentralisierten Protokol-lierungsansatz und die Protokollierung in verbreiteten Protokolldatenformatenunterstützen (siehe Abschnitt Geeignete Datenformate und Mechanismen).

Schutz vor unbefugtem Zugriff und der Manipulation vonProtokolldaten

Da die Protokolldaten vertrauliche Informationen (zum Beispiel über das Be-nutzerverhalten und den Aufbau beziehungsweise die Konfiguration der We-banwendung oder des Web-Service) enthalten können, muss der Zugriff aufdie Protokolldaten reglementiert und nur befugten Benutzern ermöglicht wer-den. Der Zugriff auf Protokolldaten sollte nicht über öffentliche Schnittstellenmöglich sein. Protokolldaten sollten daher in dedizierten Logverzeichnissen(zum Beispiel außerhalb des Web-Root-Verzeichnisses des Web-Servers) ge-speichert werden.

Werden die Protokolldaten in einer Datenbank abgelegt, so sollten die Proto-kolldaten von den eigentlichen Nutzdaten getrennt werden. Diese Trennungkann mittels einer separaten Datenbanktabelle erreicht werden. Darüber hin-aus kann ein eigener Datenbankbenutzer für die Protokollierung den Schutz



der Protokolldaten erhöhen. In diesem Fall darf der Datenbankbenutzer für dieNutzdaten keine Zugriffsrechte auf die Protokolldaten haben.

Alternativ können die Protokollierungsdaten mit hohem Schutzbedarf auch ineiner separaten Datenbankinstanz gespeichert werden.

Sichere Protokollauswertung

Ein Angreifer kann bewusst Protokoll-Einträge provozieren (zum Beispielwenn Eingabefelder protokolliert werden), die schadhaften Programmcodebeinhalten. Daher sollte bei der Auswertung der Protokolldaten sichergestelltwerden, dass Schadcode in Protokoll-Einträgen vom Auswertungsprogrammnicht interpretiert wird (zum Beispiel durch die Ansicht in einem Browser undder Interpretation von JavaScript-Code in den Protokolldaten).

Da bei der Protokollauswertung keine Änderungen an den Protokolldaten vor-genommen werden dürfen, sind die Protokolldaten ausschließlich in einemschreibgeschützten Modus zu analysieren.

Zeitsynchronisation

Die Protokolldaten verschiedener Komponenten einer Webanwendung odereines Web-Service (zum Beispiel Applikationsserver, Webserver, Datenbank-server) müssen in der Regel korreliert werden, um komponentenübergreifen-de Vorgänge vollständig nachvollziehen zu können. Dazu sollte die Zeit aufden Systemen synchronisiert sein, um anhand der Uhrzeiten Vorgänge in denProtokollen konsistent nachverfolgen zu können. Hierzu sollte M 4.227 Einsatzeines lokalen NTP-Servers zur Zeitsynchronisation beachtet werden.

Prüffragen:

- Werden sicherheitsrelevante Ereignisse mit den erforderlichen Merkmalenvon der Webanwendung oder dem Web-Service protokolliert?

- Werden keine vertraulichen Daten (zum Beispiel Zugangsdaten)protokolliert?

- Wird die Protokollierung ausschließlich serverseitig von einer zentralenKomponente der Webanwendung oder des Web-Service durchgeführt?

- Ist der Zugriff auf die Protokolldaten nur befugten Benutzern ermöglicht?- Wird der Zugriff auf die Protokolldaten über die öffentliche Schnittstelle

unterbunden?- Verwendet die Webanwendung oder der Web-Service Datenformate und

Mechanismen zur Protokollierung, die eine Integration in bestehendeLösungen ermöglicht?

- Wird eine Zeitsynchronisation für die Komponenten der Webanwendungoder des Web-Service umgesetzt?

- Wird das Ausführen von Schadcode bei der Protokollauswertungverhindert?



M 4.400 Restriktive HerausgabesicherheitsrelevanterInformationen beiWebanwendungen und Web-Services

Verantwortlich für Initiierung: Fachverantwortliche, Verantwortliche dereinzelnen Anwendungen


Webseiten und Rückantworten von Webanwendungen und Web-Serviceskönnen sicherheitsrelevante Informationen beinhalten, mit deren Hilfe Angrei-fer Sicherheitsmechanismen umgehen und Schwachstellen ausnutzen kön-nen. Daher dürfen keine sicherheitsrelevanten Informationen angezeigt wer-den, die nicht zwingend für den Betrieb und die Nutzung der Webanwendungoder des Web-Service notwendig sind.

Die folgenden Beispiele verdeutlichen, welche Informationen sicherheitsrele-vante Hinweise enthalten können und wie verhindert werden kann, dass dieseoffengelegt werden.

Keine sicherheitsrelevanten Informationen in Fehlermeldungen

Tritt bei der Bedienung der Webanwendung oder des Web-Service ein Feh-ler auf (zum Beispiel Zugriffsfehler), sollten dem Benutzer neutrale Fehlermel-dungen übermittelt werden. Die Fehlermeldungen dürfen keine direkten Rück-schlüsse auf eingesetzte Techniken, Sicherheitsmechanismen und Zuständeder Webanwendung ermöglichen.

Die folgenden Beispiele zeigen Informationen, die nicht in Fehlermeldungenenthalten sein sollten:

- Stacktraces und Debugging-Informationen,- Meldungen wie "Benutzername ungültig" oder "Passwort ungültig" (anstel-

le von allgemeinen Fehlermeldungen wie "Benutzername oder Passwortungültig"),

- von Hintergrundsystemen weitergereichte Fehlermeldungen wie zum Bei-spiel SQL-Fehlermeldungen einer Datenbank statt einer Meldung "Fehlerbei der Überprüfung der Zugangsdaten",

- Fehlercodes statt zum Beispiel der Meldung "Ein Fehler ist aufgetreten".

Im Fall einer fehlgeschlagenen Authentisierung sollte beispielsweise unab-hängig von der Gültigkeit des Benutzernamens stets eine allgemeingültigeMeldung wie "Falsche oder ungültige Zugangsdaten" ausgegeben werden,damit ein Angreifer nicht auf die Existenz von Benutzerkonten rückschließenkann (user enumeration).

Grundsätzlich kann unterschiedlicher HTML-Code zur gleichen Ausgabe imWebbrowser führen. Beispielsweise werden zwei HTML-Seiten mit einer un-terschiedlichen Anzahl von Leerzeichen im Browser gleich dargestellt, obwohlsie sich im HTML-Code unterscheiden. Es ist daher darauf zu achten, dass dieFehlermeldungen nicht nur in der Darstellung im Browser, sondern auch imHTML-Code identisch sind. Hiermit soll verhindert werden, dass ein Angreiferaufgrund eines veränderten HTML-Codes auf die Gültigkeit von Teil-Eingaben(zum Beispiel gültiger Benutzername bei falschem Passwort) schließen kann.



Weitere Informationen zur Fehlerbehandlung finden sich in M 4.395 Fehlerbe-handlung durch Webanwendungen und Web-Services.

Vermeidung von sicherheitsrelevanten Kommentaren in ausgeliefertenWebseiten oder Web-Service-Antworten

Bei der Entwicklung von Webanwendungen werden möglicherweise Kommen-tare in den HTML-Code geschrieben. Diese Kommentare können sicherheits-relevante Informationen (zum Beispiel Todo-Listen, Versionsnummern, Zu-gangsdaten oder uninterpretierter Quellcode) enthalten, die als HTML-Kom-mentare in der Webseite vom Benutzer leicht eingesehen werden können.Auch die Rückantworten von Web-Services können Kommentare mit sicher-heitsrelevanten Informationen enthalten, beispielsweise Kommentare in XML-Antworten eines SOAP-Dienstes. Aus diesem Grund ist darauf zu achten,dass in den Kommentaren keine sicherheitsrelevanten Informationen enthal-ten sind. Idealerweise sollten in in den ausgelieferten Webseiten oder Rück-antworten einer produktiven Webanwendung oder eines Web-Service keineKommentare verwendet werden.

Eingeschränkter Zugriff auf Dokumentation

Informationen in der Dokumentation einer Webanwendung oder eines Web-Service (zum Beispiel Dokumente zur Administration der Webanwendung)können einem Angreifer auf potentielle Schwachstellen (zum Beispiel Stan-dardbenutzer nach der Installation) hinweisen und missbraucht werden, umAngriffe vorzubereiten. Daher sollte verzichtbare Dokumentation zur Weban-wendung oder zum Web-Service und den zugehörigen Komponenten (zumBeispiel Datenbank) gelöscht werden. Ist die Dokumentation online verfügbar,so sollte ausschließlich der entsprechende Adressatenkreis darauf zugreifenkönnen. Beispielsweise sollte die Dokumentation zur Administration einer We-banwendung oder eines Web-Service nicht aus dem Internet heraus erreich-bar sein.

Löschen nicht benötigter Dateien

Im laufenden Betrieb einer Webanwendung oder eines Web-Service fallenhäufig Dateien an, die nicht für den produktiven Betrieb benötigt werden (zumBeispiel temporäre Dateien, oder Backup-Dateien). Diese Dateien können si-cherheitskritische Informationen beinhalten (zum Beispiel Test-Ergebnisse)oder Funktionen anbieten (zum Beispiel Testwerkzeuge zur Ermittlung vonVersionsnummern der eingesetzten Bibliotheken), die für Angriffe auf die We-banwendung genutzt werden können.

Darüber hinaus ist zu beachten, dass insbesondere bei temporären Dateienoder Backup-Dateien häufig andere Dateiendungen (zum Beispiel *.bak-Da-teien als Sicherheitskopien eines Editors) verwendet werden. Werden dieseDateien vom Webserver abgerufen, wäre es möglich, dass die Dateien auf-grund der unbekannten Dateiendung nicht mehr interpretiert werden und statt-dessen der Quelltext der Webanwendung ausgeliefert wird.

Versionsverwaltungssysteme legen zumeist Dateien oder Ordnerstrukturenfür die von ihnen verwalteten Objekte an (zum Beispiel Ordner wie .svnoder .git). Diese Dateien oder Ordner enthalten häufig detaillierte Informatio-nen zu den verwalteten Projekten und ermöglichen unter Umständen einenkompletten Zugriff auf den Quellcode. Aus diesem Grund sollten Anwendun-gen oder Anwendungskomponenten grundsätzlich nicht über die Versionsver-waltung auf Produktivsysteme aufgespielt werden. Zumindest sollte der Zu-



griff auf von der Versionsverwaltungssoftware angelegte Dateien und Ordnerblockiert werden.

Aus den genannten Gründen sind alle Dateien zu löschen, die für den produk-tiven Betrieb nicht benötigt werden. Darüber hinaus sollte regelmäßig kontrol-liert werden, ob neue Dateien angefallen sind und ob diese gelöscht werdenkönnen. Ist dies nicht möglich, kann der Zugriff auf diese Dateien gesperrtwerden.

Sichere Erfassung durch externe Suchmaschinen

Suchmaschinen setzen sogenannte Agenten (auch Robots oder Crawler ge-nannt) ein, um neue oder geänderte Inhalte im Netz zu indizieren. Diese Agen-ten können durch die Datei robots.txt im Wurzelverzeichnis der Webanwen-dung instruiert werden, ausgewiesene Ressourcen (zum Beispiel Pfade) derWebanwendung zu ignorieren. Auf diese Weise können schützenswerte In-formationen von der Indizierung in der Suchmaschine ausgenommen werden.Die vertraulichen Ressourcen (zum Beispiel Verzeichnis-Pfade) sollten in derDatei robots.txt unter der Direktive "Disallow" aufgeführt werden. So werdendie Agenten veranlasst, die gelisteten Ressourcen nicht zu indizieren.

Damit die Einträge in der Datei robots.txt einem Angreifer keine Hinweiseauf sicherheitskritische Ressourcen der Webanwendung geben, sollten allezu schützenden Verzeichnisse nach Möglichkeit in einem gesonderten Ver-zeichnis der Webanwendung zusammengefasst werden. Ausschließlich die-ses Verzeichnis sollte in die Datei robots.txt eingetragen werden, sodass die-se keine internen Verzeichnisstrukturen mit sicherheitsrelevanten Informatio-nen enthält.

Vermeidung von Produkt- und Versionsangaben

Häufig enthalten Antworten und Ausgaben der einzelnen Komponenten derWebanwendung Angaben zu Produktnamen und Versionsnummern. Diese In-formationen können zum Beispiel in HTTP-Headern oder in Kommentaren imHTML-Quelltext der ausgelieferten Webseiten, aber auch in XML- oder JSON-Antworten von Web-Services enthalten sein. Auf der Grundlage dieser Anga-ben kann ein Angreifer gezielt nach bekannten Schwachstellen des Produktssuchen und über diese die Webanwendung oder den Web-Service angreifen.Daher sollten Angaben zu verwendeten Produkten und Versionen vermiedenwerden (zum Beispiel Applikationsframework, Webserver).

Verzicht auf absolute Pfadangaben

Absolute Pfadangaben ermöglichen oft Rückschlüsse auf die interne Strukturund den Aufbau der Webanwendung. So kann beispielsweise der Speicherortschützenswerter Informationen ermittelt werden. Daher sollten nach Möglich-keit keine absoluten Pfadangaben der Webanwendung oder des Web-Serviceveröffentlicht werden.

Prüffragen:

- Werden ausschließlich Informationen veröffentlicht, die für den Betrieboder die Nutzung der Webanwendung oder des Web-Service erforderlichsind?

- Werden von der Webanwendung oder dem Web-Service ausschließlichneutrale Fehlermeldungen ausgegeben und sind diese im Quelltextidentisch?



- Werden sicherheitsrelevante Informationen in Webseiten (zum Beispiel inKommentaren) oder Web-Service Antworten vor der Auslieferung an dieBenutzer gelöscht?

- Ist nur dem entsprechenden Adressatenkreis der Zugriff aufsicherheitsrelevante Dokumentation der Webanwendung oder des Web-Service möglich?

- Werden vor der produktiven Inbetriebnahme alle Dateien gelöscht,die nicht für den Betrieb der Webanwendung oder des Web-Servicenotwendig sind, und wird eine entsprechende Prüfung auf nicht benötigteDateien regelmäßig durchgeführt?

- Enthält die Datei robots.txt ausschließlich URLs, die keinesicherheitsrelevanten Informationen enthalten?



M 4.405 Verhinderung der Blockadevon Ressourcen (DoS) beiWebanwendungen und Web-Services


Webanwendungen und Web-Services bieten häufig ressourcenintensiveFunktionen an, die zum Beispiel komplexe Datenbankabfragen oder Daten-übermittlungen auslösen. Werden diese rechenintensiven Operationen be-wusst gehäuft aufgerufen oder die Webanwendungen und Web-Services mitAnfragen überflutet, können hierdurch Ressourcen im Übermaß belegt undder Betrieb bis zur Unerreichbarkeit eingeschränkt werden. Dieses Vorgehenwird als Denial-of-Service-Angriff (DoS) bezeichnet.

DoS-Angriffe beruhen in den meisten Fällen ebenso wie Brute-Force- undEnumeration-Angriffe auf Automation (siehe M 4.396 Schutz vor unerlaubterautomatisierter Nutzung von Webanwendungen). Daher sollten zur Vorbeu-gung gegen DoS-Angriffe ähnliche Schutzmechanismen umgesetzt werden.Dazu zählen beispielsweise folgende Maßnahmen:

- Grenzwerte festlegen (zum Beispiel die vorübergehende Blockierung einerRessource oder des Benutzerkontos nach wiederholten Fehlzugriffen),

- die Zeitspanne zwischen Anfrage und Verarbeitung durch die Webanwen-dung künstlich verzögern (zum Beispiel bei wiederholt erfolgloser Anmel-dung),

- die aufrufende IP-Adresse bei Verdacht auf einen Angriff temporär sper-ren,

- CAPTCHAs verwenden,- Eingaben bei Eingabefeldern verifizieren, bevor rechenintensive Opera-

tionen angestoßen werden,- XML-Filtermechanismen und XML-Validitätsprüfungen einsetzen.

Zusätzlich geben die folgenden Beispiele Hinweise auf spezifische Schutz-maßnahmen, um Denial-of-Service-Angriffe bei Webanwendungen und Web-Services zu erschweren:

- Ressourcenintensive Operationen sind besonders anfällig für DoS-Angrif-fe. Daher kann die Ressourcennutzung pro Benutzer auf ein Maximum ein-geschränkt werden. Darüber hinaus können bestimmte Operationen nurangemeldeten Benutzern zugänglich gemacht werden (zum Beispiel kom-plexe Datenbankaufrufe).

- Pro Benutzer sollte nur eine Anfrage zur gleichen Zeit bearbeitet wer-den. Mehrere Anfragen desselben Benutzers sollten sequenziell bearbei-tet werden.

- Die Last durch DoS-Anfragen kann teilweise durch Zwischenspeichern(cachen) der Webseitenaufrufe deutlich verringert werden. Somit wird dieangeforderte, rechenintensive Operation nicht bei jedem Aufruf ausge-führt, sondern lediglich das zwischengespeicherte Resultat zurückgege-ben. Stark Ressourcen belastende Anfragen können auch in lastarmenZeiten vorberechnet werden (Voraggregation).

- Die Architektur und Flusskontrolle der Webanwendung sollten darauf aus-gelegt sein, rechenintensive Operationen zu vermeiden (zum Beispiel beider Erstellung der Session-ID oder anderen kryptographischen Mecha-nismen sollten ressourcenintensive Operationen gemieden werden). Zur



Erkennung rechenintensiver Operationen können Lasttests durchgeführtwerden.

- Ein Überlauf von Speicherplatz, zum Beispiel im Rahmen der Protokollie-rung, kann dazu führen, dass keine Schreibzugriffe mehr auf den Daten-träger möglich sind. Werden Speichervorgänge von der Webanwendungoder dem Web-Service durchgeführt, kann dies den Betrieb gefährden.Daher sollte der Zugriff auf Datenspeicher begrenzt und die Kapazität derDatenspeicher regelmäßig geprüft werden. Ebenso sollte auch der Ver-brauch von Arbeitsspeicher (RAM) pro Thread begrenzt werden.

- SOAP-Nachrichten müssen gemäß dem entsprechenden XML-Schemavalidiert werden. Ist die Validierung nicht erfolgreich, da sie zum Beispieleine undefinierte Zahl an Elementen enthält, darf die SOAP-Nachrichtnicht weiter verarbeitet werden, da diese ansonsten zu Problemen bei derVerarbeitung durch den XML-Parser führen kann.

Bei Web-Anwendungen und Web-Services, bei denen aufgrund ihrer Naturmit gezielten, zum Beispiel politisch motivierten DoS-Angriffen aus dem Inter-net zu rechnen ist, kann auch die Zusammenarbeit mit einem Dienstleistersinnvoll sein, der sich auf die Abwehr von DoS-Angriffen spezialisiert hat. Sol-che Dienstleister leiten den IP-Verkehr im Angriffsfall über eigene Systeme,die Zugriffe filtern und/oder die Zielsysteme durch andere Maßnahmen wiezum Beispiel Zwischenspeicher (Caching) entlasten. Dabei ist im Vorfeld ab-zuwägen, ob durch die Umleitung der Datenströme über die Systeme Dritterzusätzliche Gefährdungen oder Anforderungen entstehen. Eine beliebte An-griffsmethode für zwischengespeicherte Web-Seiten ist beispielsweise, dassder Angreifer nicht vorhandene Unterseiten aufruft. Wenn dies der Dienstlei-ster nicht abfängt und die Anfrage nach der vermeintlich neuen Unterseitean die ursprüngliche Seite weiterleitet, kommt es zu einem unbeabsichtigtenDoS-Angriff des Dienstleisters. Solchen neuen Angriffsvektoren muss bei derAuswahl des Anti-DoS-Dienstleisters begegnet werden.

Prüffragen:

- Werden der Einsatz und die Nutzung ressourcenintensiver Operationenbei Webanwendungen und Web-Services gemieden, und werden diesebesonders geschützt?

- Wird ein möglicher Überlauf von Protokolldaten bei Webanwendungenund Web-Services überwacht und verhindert?

- Werden SOAP-Nachrichten anhand eines entsprechenden XML-Schemasvalidiert?

- Wurde bei kritischen Diensten und Anwendungen die Zusammenarbeitmit einem Anti-DoS-Dienstleister geprüft?



M 4.450 Absicherung derKommunikation bei Web-Services

Verantwortlich für Initiierung: Leiter IT, Verantwortliche der einzelnenAnwendungen

Verantwortlich für Umsetzung: Administrator, Leiter IT

Da die Kommunikation mit Web-Services nicht immer zwingend intern, son-dern auch extern über fremde Netze und weitere beteiligte Stellen ablaufenkann, muss sichergestellt werden, dass die Daten über einen sicheren Kanalübertragen werden. Ziel dabei ist es, die Vertraulichkeit und die Integrität derübertragenen Daten zu gewährleisten. Zur Absicherung der Kommunikationbei Web-Services können unterschiedliche Methoden und Standards ange-wendet werden, die sich in zwei grundlegende Strategien gliedern lassen:

- Transportbasierte Verschlüsselung und- Nachrichtenbasierte Verschlüsselung.

Transport-basierte Verschlüsselung mittels SSL-/TLS

Durch die Anwendung des SSL-/TLS-Protokolls können die Kommunikations-wege von Web-Services auf Transportebene abgesichert werden. Durch dieVerschlüsselung des Datenstroms zwischen zwei Endpunkten ist sicherge-stellt, dass die Daten während der Übertragung geschützt sind und nicht mit-gelesen werden können. Durch die Verschlüsselung wird ebenfalls sicherge-stellt, dass die Nachrichtenintegrität bewahrt wird. Zusätzlich zur Verschlüs-selung birgt die Nutzung von SSL-/TLS den Vorteil, dass dadurch mehrereFormen der Authentisierung relativ problemlos umgesetzt werden können:

- Serverauthentisierung: Der Server authentisiert sich gegenüber dem Web-Service-Client auf der Grundlage eines kryptographischen Zertifikats.

- Clientauthentisierung: Zusätzlich zum Server authentisiert sich auch derClient gegenüber dem Server anhand eines maschinenspezifischen Zer-tifikats.

- Benutzerauthentisierung: Die client-seitige Authentisierung kann auch mitbenutzerbezogenen Zertifikaten erfolgen und so gleichzeitig zur Authenti-sierung des jeweiligen Benutzers verwendet werden.

Der Vorteil einer Verschlüsselung mit SSL-/TLS besteht insbesondere darin,dass die Umsetzung weitgehend unabhängig von der Realisierung der Web-Services selbst erfolgen kann, im einfachen Fall durch entsprechende Konfi-guration der Web- oder Applikationsserver.

Der Nachteil in der Verwendung von SSL-/TLS liegt darin, dass nur die Ver-bindung zwischen zwei direkten Endpunkten verschlüsselt wird. Komplexe-re Szenarien, in denen zum Beispiel eine Nachricht über mehrere Zwischen-stationen gesendet werden muss und der jeweilige Empfänger nur einen be-stimmten Teil einer Nachricht lesen darf, lassen sich nicht abbilden.

Bei einer Verschlüsselung mittels SSL-/TLS sind die Daten nur bei der Über-tragung selbst verschlüsselt. Während sich die Daten zum Beispiel noch inder Warteschlange für die Nachrichtenverarbeitung auf dem Server befinden,liegen diese unverschlüsselt auf dem System vor. Der Einsatz von SSL-/TLSmuss daher vor dem Hintergrund des konkreten Anwendungsszenarios ge-prüft werden. Weitere Informationen zur Nutzung von SSL-/TLS finden sichin M 5.66 Clientseitige Verwendung von SSL/TLS und M 5.177 ServerseitigeVerwendung von SSL/TLS.



Nachrichten-basierte Verschlüsselung mittels WS-Standards

Da bei Web-Services Nachrichten über mehrere Intermediäre gehen könnenund eine Direktverbindung nicht immer möglich ist, erhält der Intermediäreventuell Informationen, die gar nicht für ihn bestimmt sind. Um die Sicherheitder Nachrichten gewährleisten zu können, müssen Nachrichten so behandeltwerden können, dass Teilnachrichten nur von den rechtmäßigen Empfängerngelesen werden können, weshalb in diesem Fall auf eine nachrichtenbasier-te Verschlüsselung, zum Beispiel auf XML-Ebene, zurückzugreifen ist. Dafürstehen verschiedene Standards zur Verfügung:

- XML-Encryption (XMLEnc)- XML-Signaturen (XMLSig)- WS-Security- WS-SecureConversation

Eine nähere Beschreibung dieser Standards und ihrer Einsatzmöglichkeitenfindet sich in der W-Maßnahme M 4.451 Aktuelle Web-Service Standards.

Für die Implementierung von kryptographischen Mechanismen sollte auf eineetablierte Softwarebibliothek (Framework) und bestehende Kryptobibliotheken(zum Beispiel für Java die Krypto-Bibliotheken IAIK-JCE oder Bouncy Castle,Letztere ist auch für C#/Microsoft .NET verfügbar) zurückgegriffen werden, daeine eigenständige Kryptoimplementierung sehr fehlerträchtig ist und erfah-rungsgemäß Schwachstellen beinhaltet.

Verfügbarkeit

Da durch Web-Services ermöglicht wird, dass Geschäftsprozesse organisa-tionsübergreifend realisiert werden, ist hierbei auch ein besonderes Augen-merk auf die Verfügbarkeit zu legen. Ein Ausfall einer Komponente kann zueinem Ausfall des gesamten Geschäftsprozesses führen, was sich auf meh-rere Parteien auswirken kann. Aus diesem Grund müssen im Hinblick auf dieVerfügbarkeit der Systeme Maßnahmen wie eine Lastverteilung oder Redun-danzen der eingesetzten Applikationsserver mit betrachtet werden, um eineausreichend hohe Verfügbarkeit erzielen zu können. Das Ziel muss dabei sein,den Verlust der Verfügbarkeit durch Ausfall einer einzigen Komponente (engl.Single Point of Failure) zu vermeiden. Abhängig von der Menge der durch dasSystem verarbeiteten Nachrichten muss das System so skalierbar sein, dassdieses auch mit einem vermehrten Aufkommen von Anfragen umgehen kann.

Zusätzlich müssen Sicherheitsmaßnahmen getroffen werden, um das Risikoeines Ausfalls eines Web-Service durch gezielte Angriffe (Denial of Service)zu minimieren. Weitere Informationen hierzu finden sich in der MaßnahmeM 4.405 Verhinderung der Blockade von Ressourcen (DoS) bei Webanwen-dungen und Web-Services.

Prüffragen:

- Wird ein geeignetes Transport-basiertes oder Nachrichten-basiertesVerschlüsselungsverfahren eingesetzt, um den Nachrichtenaustauschabzusichern?

- Wurde für die Implementierung kryptographischer Funktionen auf eineetablierte Softwarebibliothek zurückgegriffen?

- Wurden für die Kommunikationsschnittstellen des Web-Servicedie Verfügbarkeitsanforderungen berücksichtigt und entsprechendumgesetzt?



M 4.451 Aktuelle Web-Service StandardsVerantwortlich für Initiierung: Leiter IT, Verantwortliche der einzelnen

AnwendungenVerantwortlich für Umsetzung: Administrator, Leiter IT

Web-Services sind Softwareanwendungen, die über ein Netz bereitgestelltwerden. Sie stellen vielfältige IT-basierte Dienste zur Verwendung durch na-hezu beliebige Clients bereit.

Im Zusammenspiel komplexer IT-Landschaften spielen Web-Services zuneh-mend eine bedeutende Rolle. Dabei sind Sicherheitsaspekte in der Verwen-dung solcher Dienste von großer Relevanz.

Um eine reibungslose Integration von Web-Services in eine Service-Orien-tierte Architektur (SOA) zu gewährleisten, wurden verschiedene Standardsentwickelt, die die unterschiedlichen Aspekte von Web-Services betrachten.Vor allem die Organization for the Advancement of Structured InformationStandards (OASIS) und das World Wide Web Consortium (WC3) bieten eineVielzahl von sich ergänzenden und aufeinander aufbauenden Standards zumThema.

Basierend auf bewährten Internet-Transportprotokollen werden neben techni-schen und organisatorischen Themen auch Sicherheitsaspekte in Standardsabstrahiert, um den komplexen Anforderungen der Geschäftsprozessmodel-lierung gerecht zu werden.

Die wichtigsten Standards mit Sicherheitsbezug sind in der folgenden Gra-fik visualisiert und werden in den nächsten Abschnitten kurz vorgestellt. Auf-grund der Komplexität des Themas und der beständigen Weiterentwicklungder Standards kann dies nur eine Auswahl darstellen, die keinen Anspruch aufVollständigkeit erhebt.

XML-Encryption

Abbildung: XML-Encryption ist eine Spezifikation zur Verschlüsselung vonXML-Dokumenten. Sie wird vom WC3 verwaltet.

Die XML-Encryption-Spezifikation definiert verschiedene Möglichkeiten derVerschlüsselung. Es können ganze XML-Dokumente verschlüsselt werden,einzelne Elemente mit ihren Unterelementen oder der Inhalt einzelner XML-Elemente. Damit ist eine fein granulierte Verschlüsselung der XML-Datenmöglich. Die verschlüsselten Daten sind wiederum XML-Dokumente oder Tei-le davon.



Durch die Verschlüsselung einzelner Elemente eignet sich XML-Encryptioninsbesondere dann, wenn mehrere nicht vertrauenswürdige Instanzen an derNachrichtenübermittlung beteiligt sind, diese aber keine Kenntnis über dieNachrichten der anderen Empfänger haben dürfen. Das folgende Beispiel il-lustriert die Verschlüsselung von Kreditkartendaten innerhalb einer Nachricht:

<?xml version='1.0'?>

<PaymentInfo xmlns='http://example.org/paymentv2'>

<Name>John Smith</Name>

<EncryptedData Type='http://www.w3.org/2001/04/xmlenc#Element'

xmlns='http://www.w3.org/2001/04/xmlenc#'>

<CipherData>

<CipherValue>A23B45C56</CipherValue>

</CipherData>

</EncryptedData>

</PaymentInfo>

Zu verschlüsselnde Daten werden durch die Anwendung von XML-Encryptionimmer durch das übergeordnete Element EncyptedData ersetzt.

Neben den verschlüsselten Daten können auch Informationen zum verwen-deten Verschlüsselungsalgorithmus, dem Schlüssel und zum beabsichtigtenEmpfänger mit eingebettet werden. Damit ist auch eine Verschlüsselung fürmehrere Empfänger möglich (zum Beispiel mit asymmetrischer Verschlüsse-lung im Rahmen einer Public-Key-Infrastruktur).

Die Verschlüsselung kann sowohl mit symmetrischen als auch asymmetri-schen Verfahren realisiert werden. Zu beachten bei der Nutzung von XML-Encryption ist, dass sichere kryptographische Algorithmen eingesetzt wer-den müssen. Weitere Hinweise zu kryptografischen Algorithmen und Schlüs-sellängen sind in der Technischen Richtlinie des BSI Kryptografische Ver-fahren: Empfehlungen und Schlüssellängen - Teil 2 Verwendung von TLS(TR-02102-2) und M 2.164 Auswahl eines geeigneten kryptographischen Ver-fahrens enthalten.

XMLSignature

XML-Signature definiert eine XML-Syntax für elektronische Signaturen. Funk-tionell ähnelt XML Signature dem Krypto-Standard PKCS#7, ist aber leichtererweiterbar und speziell auf XML-Dokumente zugeschnitten.

Mit XML-Signaturen können beliebige Ressourcen signiert werden. Typischer-weise sind das XML-Dokumente oder Teile davon, aber es ist auch möglich,beliebige Daten zu signieren, die über eine URL adressierbar sind.

Wird eine XML-Signatur verwendet, um eine Ressource außerhalb des um-gebenden XML-Dokuments zu signieren, wird sie als detached signature be-zeichnet, werden Teile des umgebenden Dokuments signiert, ist das eine en-veloped signature, sind die signierten Daten in der XML-Signatur enthalten,eine enveloping signature.



Da eine logische XML-Struktur je nach Umgebung unterschiedliche, gleicher-maßen gültige Darstellungsformen haben kann, muss für eine zuverlässige Si-gnierung eine standardisierte Transformation in eine kanonische Darstellungerfolgen (Canonical XML).

Beim Einsatz von XML-Signature ist wie auch bei der Anwendung von XML-Encryption auf die Auswahl starker kryptographischer Verfahren zu achten.

XML Key Management Specification

Die XML Key Management Specification (XKMS) basiert auf SOAP, XML-Si-gnature und XML-Encryption und erlaubt es, asymmetrische kryptografischeSchlüssel auf Basis von XML über Web-Services zu validieren und zu verwal-ten. Damit wird eine einfache Einbindung einer PKI (Public-Key-Infrastruktur)in die SOA ermöglicht.

Mittels XML Key Registration Service Specification (X-KRSS) werden der Le-benszyklus von Schlüsseln (Registrierung, Widerruf, Neuauflage) sowie dieWiedergewinnung von zugehörigen privaten Schlüsseln beschrieben.

XML Key Information Service Specification (X-KISS) definiert den Zugriff aufdie Verifizierung von öffentlichen Schlüsseln und zugehörigen Zertifikaten.

Eine vertrauenswürdige Zwischeninstanz (TrustPoint, ebenfalls ein Web-Ser-vice) verarbeitet die Anfragen der Clients und bildet die Schnittstelle zu be-stehenden Public-Key-Infrastrukturen. Dabei kann ein zentrales Trust Mana-gement realisiert werden, um die jeweiligen Anforderungen an Zugriffsschutz,Teilnehmerkreis und Vertrauenswürdigkeit umzusetzen.

SAML

Die Security Assertion Markup Language (kurz SAML) ist ein XML-basiertesDatenformat zum Austausch von Authentisierungs- und Autorisierungsinfor-mationen. Damit können sicherheitsrelevante Informationen beschrieben undtransferiert werden.

Die Entwicklung erfolgte durch das OASIS-Konsortium in Hinsicht auf Sicher-heitsanforderungen in verteilten IT-Umgebungen. Neben der Nutzung ver-schiedener Anwendungen auf der Basis einer einmaligen Benutzeranmeldung(Single Sign-On) können auch verteilte Transaktionen mit mehreren Beteilig-ten und Autorisierungsdienste abgebildet werden.

Eine SAML Assertion enthält eine gekapselte Sicherheitsinformation, die grobvereinfacht folgendes besagt: "Zusicherung A wurde geprüft zur Zeit t von Prü-fer R bezüglich Subjekt S unter der Bedingung C." Damit können neben Au-thentisierungsinformationen auch Zusicherungen über Eigenschaften von Ob-jekten übertragen werden, die bei der Prüfung von Zugriffsrechten und demAblauf von Transaktionen eine Rolle spielen.

SOAP

SOAP (Simple Object Access Protocol) ist ein Netzprotokoll zum Austauschstrukturierter Daten zwischen Systemen und zur Interprozesskommunikation.Es baut auf bekannte Internet-Protokolle wie zum Beispiel HTTP oder SMTPauf und basiert auf der W3C-Spezifikation XML Information Set zur Repräsen-tation der Daten. Es ist ein industrieller Standard des World Wide Web Con-sortium (W3C).



SOAP stellt ein Rahmenwerk dar, das die Struktur von Nachrichten beschreibtund festlegt, wie Daten in Nachrichten einzubetten und auszulesen sind. Dakeine Vorgaben für eine Semantik der Nutzdaten definiert sind, können belie-bige applikationsspezifische Inhalte übertragen werden. Somit können nebenXML auch andere Datenformate (wie zum Beispiel CSV) Verwendung finden.

Zwar kann mittels SOAP über beliebige Transportprotokolle kommuniziertwerden, aber in der Praxis wird aufgrund der Kompatibilität mit üblichen Netz-architekturen meist auf die Nutzung von HTTP und HTTPS zurückgegriffen.

REST

Representational State Transfer (REST) beschreibt ein Entwurfsparadigma fürWeb-Anwendungen und kann im Großen und Ganzen auf Web-Services an-gewendet werden. REST basiert auf einfachen Prinzipien, die beim Entwurfund der Umsetzung einer REST-konformen Web-Anwendung berücksichtigtwerden müssen.

Ursprünglich wurde REST in Hinsicht auf das HTTP-Protokoll entworfen, legtjedoch keine Details für die Implementierung fest. Es werden also auch keineProtokolle oder Standards vorgeschrieben. REST kann gut mit HTTP- bezie-hungsweise SOAP-basierten Web-Services umgesetzt werden.

Im Zentrum der Betrachtung steht bei REST neben den Ressourcen, die eineWeb-Anwendung bereitstellt, die Uniformität der Kommunikationsschnittstelle.Daneben wird eine simplifizierte Struktur der Netzkommunikation entworfen,um die Unabhängigkeit, Skalierbarkeit und Vernetzbarkeit der Komponentenzu erhöhen.

Im Einzelnen gelten folgende Prinzipien:

- Client-Server: Die Zuständigkeiten zwischen Server und Client werdenklar aufgeteilt (Separation of Concerns). Dies gilt insbesondere für die Da-tenhaltung.

- Zustandslosigkeit: Die Kommunikation ist zustandslos. Jede REST-Anfra-ge enthält alle Informationen, die der Server benötigt, um die Anfrage ord-nungsgemäß zu verarbeiten. Der Server muss keine Client-bezogenen In-formationen aus Kommunikationsvorgängen speichern, um zukünftige An-fragen zu bearbeiten.

- Cachefähigkeit: Ressourcen können vom Server als cachefähig gekenn-zeichnet werden. Damit können alle Stationen der Netzkommunikation bishin zum Client die Serverantwort zwischenspeichern und für Interaktionenwiederverwenden.

- Einheitliche Schnittstelle: Auf die Schnittstelle zwischen Client und Serverwird das aus der Softwareentwicklung bekannte Prinzips der Generalisie-rung angewendet. Dadurch wird die Standardisierung von Adressierung,Kommunikation, Datenstrukturen und Transaktionen verpflichtend für eineREST-konforme Web-Anwendung.

- Mehrschichtigkeit: Durch die Einführung einer geschichteten Web-Archi-tektur wird die Skalierbarkeit und Flexibilität weiter erhöht. Dabei kenntjede Komponente nur ihre unmittelbaren Kommunikationspartner und hatkeine Informationen über die weitere Struktur des Gesamtsystems. Zudemkönnen durch Zwischenschichten und Proxys auch Dienste gekapselt, Alt-systeme eingebunden, Sicherheitsanforderungen umgesetzt und Aufga-ben und Lasten verteilt werden.

- Code on Demand: Dem Server wird ermöglicht, den Clients Softwarebe-standteile zur Verfügung zu stellen, mit denen die clientseitige Funktiona-



lität erweitert werden kann. Damit werden dem Client serverunabhängigeAktivitäten auf der Basis der übermittelten Daten ermöglicht.

Das für die Standardisierung der Schnittstelle relevante Prinzip der einheitli-chen Schnittstelle enthält folgende Vorgaben:

- Adressierung: Bereitgestellte Ressourcen müssen eindeutig identifizierbarsein. Dafür bieten sich URIs (Uniform Resource Identifier) oder URLs (Uni-form Resource Locator) an.

- Manipulation von Ressourcen über Repräsentationen: Aktionen über Res-sourcen (Anlegen, Abrufen, Ändern, Löschen) werden durch den Aus-tausch von Repräsentationen der Ressourcen durchgeführt. Dabei kön-nen die gewünschten Daten in verschiedenen Darstellungsformen (MediaType) transferiert werden (zum Beispiel HTML, XML, JSON, PDF). Diegewünschte Aktion wird über Operationen wie zum Beispiel POST (Erzeu-gen von Ressourcen), GET (Abrufen von Ressourcen), PUT (Aktualisierenvon Ressourcen), DELETE (Löschen von Ressourcen) festgelegt. WeitereOperationen zu Status, Zugriffsrechten, Historie der Ressource oder an-deren Funktionen sind möglich.

- Selbstbeschreibende Nachrichten: Jede Anfrage eines Clients und jedeServerantwort ist eine Nachricht und muss selbstbeschreibend sein, dasheißt die Nachricht enthält alle Informationen, die der Empfänger benötigt,um seine Aufgabe ordnungsgemäß durchzuführen.

- Verwendung von Hypermedia: Hypermedia ist der Antrieb einer Web-An-wendung. Jede Manipulation des Anwendungszustandes und jeder Res-sourcenabruf erfolgt über Hypermedia. Hypermedia bedeutet in diesemZusammenhang, dass alle für den Client relevanten Web-Service-internenVerweise auf andere Repräsentationen der Ressourcen sowie alle ange-botenen Aktivitäten durch den Web-Service selbst zur Verfügung gestelltwerden müssen, der Client also keine umfassende Kenntnis der Web-Ser-vice-Struktur benötigt, um diesen nutzen zu können. Die Bereitstellung die-ser Informationen kann zum Beispiel als in eine XML-Struktur eingebun-dene URL erfolgen.

Folgende Vorteile ergeben sich aus der Anwendung von REST für Web-Ser-vices:

Durch die strikte Aufgabenteilung können Client und Server leichtgewichtigausgelegt sein, ein hoher Grad an Interoperabilität wird ermöglicht, und al-le Komponenten können unabhängig voneinander weiterentwickelt oder so-gar ausgetauscht werden. Die Zustandslosigkeit der Kommunikation verein-facht die beidseitige Datenhaltung. Hypermedia ermöglicht die Nutzung vonWeb-Services ohne genaue Kenntnis der zugrunde liegenden Implementie-rung und erleichtert die Orchestrierung einer SOA-Landschaft. Die Einheit-lichkeit der Schnittstellen erfordert ein hohes Maß an Standardisierung, dieVoraussetzung für eine systemübergreifende SOA-Integration ist. Die Mehr-schichtigkeit erlaubt eine transparente Kommunikation auch in komplexen Sy-stemlandschaften mit hohen Anforderungen an Verfügbarkeit.

Web Services Description Language (WSDL)

WSDL ist eine XML-basierte Metasprache zur Beschreibung von XML-basier-ten Webservices. Eine WSDL-Datei stellt eine maschinenlesbare Beschrei-bung der Aufrufe, Parameter, Datenstrukturen und Rückgabewerte einesWeb-Service dar. Es sind neben der Schnittstellenbeschreibung und den Zu-gangsprotokollen alle notwendigen Informationen für den Zugriff auf den Web-Service enthalten.



WSDL wird häufig mit SOAP und XML Schema eingesetzt, um XML-basier-te Web-Services in einer verteilten IT-Landschaft zu orchestrieren. Ein Cli-ent kann aus der WSDL-Datei ermitteln, welche Funktionen auf dem Serververfügbar sind. Aus der WSDL-Spezifikation des Dienstes kann automatisiertQuellcode für die Verwendung des Web-Service mittels SOAP-Nachrichtengeneriert werden.

UDDI (Universal Description, Discovery and Integration)

UDDI bezeichnet im SOA-Umfeld einen standardisierten Verzeichnisdienst fürWeb-Services. Er spielt eine zentrale Rolle bei der dynamischen Bindung vonClientanforderungen an Web-Services.

Die benötigten Informationen werden in drei Katalogen angeboten. In denWhite Pages werden die Basisinformationen vorgehalten, sie beschreiben dieIdentität des Serviceanbieters. Die Yellow Pages kategorisieren die angebo-tenen Dienste nach einer standardisierten Taxonomie. Dabei können interna-tional anerkannte Standards zum Einsatz kommen (zum Beispiel UNSPSC- United Nations Standard Products and Services Code). Die Green Pagesschließlich halten die Schnittstellenbeschreibungen der Web-Services vor.

Die technischen Aspekte des Dienstes werden strukturiert im sogenanntentModel abgelegt. Um eine Anforderung einem konkreten Dienst zuzuordnen,werden die tModel-Beschreibungen (tModel-Keys) von Client und Web-Ser-vice miteinander abgeglichen. Die Binding-Informationen (bindingTemplate)werden dann dem Client dynamisch hinzugefügt.

WS-*

Eine eigene Gruppe industrieller Standards sind die WS-*-Spezifikationen. Siewerden überwiegend vom W3C und OASIS betreut und schließen die Lückezwischen den eher technisch ausgerichteten Web-Service-Standards und denhohen Anforderungen der Geschäftsprozess-Ebene. Sie richten sich an je-weils genau ein Anwendungsgebiet, bauen teilweise aufeinander auf, und kön-nen kombiniert werden, um komplexe Anforderungen abzubilden. Dazu gehö-ren neben Adressierung, Kontext, Koordination, Zuverlässigkeit, Metadatenund Transaktion insbesondere auch Vertraulichkeit, Integrität und Verfügbar-keit, aber auch Zugriffssteuerung und Rechtemanagement.

Die Standardisierung ermöglicht die plattformunabhängige und systemüber-greifende Abbildung komplexer Geschäftsprozesse auf der Basis von SOAPund WSDL. Es folgt eine Auswahl von WS-*-Spezifikationen mit besondererRelevanz für die Sicherheit von Web-Services.

WS-Policy

WS-Policy ist ein Standard, der es Web-Services erlaubt, Auskunft über ihreRichtlinien bezüglich Sicherheit, Qualität oder andere Anforderungen zu ge-ben. Es ist die grundlegende Spezifikation für ein Rahmenwerk, das die De-finition erforderlicher und optionaler Richtlinien für Dienste und Dienstnutzerermöglicht.

Mittels WS-PolicyAssertions wird eine Menge an Standardzusicherungen be-schrieben, die innerhalb einer Policy verwendet werden können. Eine PolicyAssertion beschreibt eine Verhaltenseigenschaft, eine Pflicht oder eine Mög-lichkeit. Eine Menge dieser Richtlinien kann in der WSDL einer Web-Ser-vice-Entität (Operation, Nachricht, Endpunkt) zugeschrieben werden. In derWS-Policy-Spezifikation wird nicht festgelegt, welche Richtlinien existieren,



das geschieht in speziellen Domänen-spezifischen Spezifikationen (Sicher-heit, Transaktion und andere).

WS-PolicyAttachment standardisiert das Verknüpfen von Policies mit WSDLund UDDI, wahlweise innerhalb der Beschreibungselemente oder extern undreferenzierbar.

WS-Security

Die Web Services Security Language (WS-Security, WSS) basiert auf XML-Signature und XML-Encryption. Ziel vom WS-Security ist es, den sicherenAustausch von SOAP-Nachichten zu gewährleisten und somit die Vertraulich-keit und Integrität von Nachrichten sicherzustellen. Als Erweiterung für SOAPschreibt sie genau vor, auf welche Weise Verschlüsselungsinformationen, Si-gnaturen und Authentisierungstoken in Nachrichten eingebettet werden. Da-bei werden verschiedene Modelle von Authentisierungstoken unterstützt, un-ter anderem X.509-Zertifikate, Kerberos-Tickets, Benutzername/Password-Kombinationen und SAML-Assertions. Die Nachricht ist somit durchgehendgeschützt, wenn die Übertragung durch mehrere Instanzen erfolgt.

Ein einfaches Authentisierungstoken für eine Authentisierung mit Benutzerna-me und Passwort sieht bei WS-Security zum Beispiel so aus:

<wsse:UsernameToken>

<wsse:Username>manfred.testheimer</wsse:Username>

<wsse:Password Type="wsse:PasswordDigest">

59xi0qBCwKxwgmMxU38nOouyqDA=

</wsse:Password>

<wsse:Nonce>Sd7rTLv5W/mLa9eX2a0+rk==</wsse:Nonce>

<wsu:Created xmlns:wsu=

"http://schemas.xmlsoap.org/ws/2002/07/utility">

2013-07-12T14:12:45Z

</wsu:Created>

</wsse:UsernameToken>

Die Zufallszahl (Nonce) und der Generierungszeitpunkt, die beide in denPassword-Hash eingehen, sind optional. Von diesen Möglichkeiten sollte Ge-brauch gemacht werden, da damit die Robustheit gegen Angriffe erhöht wird.

Ein Kerberos-Ticket sieht in WS-Security dagegen zum Beispiel so aus:

<wsse:BinarySecurityToken

ValueType="wsse:Kerberosv5ST"

EncodingType="wsse:Base64Binary">

SGllciBrb2VubnRlIElocmUgV2VyYnVuZyBzdGVoZW4hCg==

</wsse:BinarySecurityToken>



WS-Transfer

WS-Transfer ist die Spezifikation eines SOAP-basierten Protokolls für denAustausch von XML-basierten Repräsentationen von Entitäten über eine Web-Service-Infrastruktur. Entitäten sind dabei:

- Ressourcen, die über einen Web-Service adressierbar sind und eine XML-Repräsentation haben

- Web-Services, die entsprechend einer XML-Repräsentation neue Res-sourcen generieren (Resource Factories)

Dabei werden Anfrage und Antwort zu einer Transaktion jeweils als XML-Dokumente übertragen. Eine direkte Einbettung der XML-Repräsentation istmöglich.

Als Operationen für Ressourcen sind GET (verpflichtend) sowie PUT und DE-LETE (jeweils optional) vorgeschrieben. Für Resource Factories ist die Ope-ration CREATE (optional) vorgesehen.

WS-MetaDataExchange

Web-Services benutzen Metadaten, um zu beschreiben, auf welche Art ande-re Endpunkte auf sie zugreifen können, und was dabei zu beachten ist. Dazuwerden vor allem XML-Schema, WSDL, WS-Policy und WS-PolicyAttachmentverwendet. Um den automatisierten Zugriff auf diese Metadaten zu erleichtern,definiert WS-MetaDataExchange Metadata Resources, die Consumern erlau-ben, die für eine korrekte Nutzung der Web-Services erforderlichen Metadatenabrufen zu können. Dafür werden Ressourcen nach dem WS-Transfer-Stan-dard verwendet, die die entsprechenden Informationen in XML verpackt ent-halten.

WS-Agreement

In einer SOA-Landschaft sind Aussagen über Verfügbarkeit, Qualität und an-dere Eigenschaften von Web-Services von entscheidender Bedeutung für dieKonsumenten. WS-Agreement beschreibt Protokolle und Datenstrukturen zurRepräsentation von Service Level Agreements für Web-Services.

Unter anderem können Übereinkünfte angeboten, akzeptiert, abgelehnt oderterminiert werden, und der Status einer Übereinkunft kann abgefragt werden.

Großer Wert wurde auf Flexibilität und Erweiterbarkeit gelegt, um die domä-nenspezifischen Anforderungen in unterschiedlichen Umgebungen abbildenzu können.

WS-ReliableMessaging

WS-ReliableMessaging widmet sich der zuverlässigen Nachrichtenübermitt-lung. Damit kann sichergestellt werden, dass Nachrichten auch im Falle einesVersagens einzelner Komponenten verlässlich den Empfänger erreichen. Da-mit kann die Anwendung einerseits auf Fehler oder Probleme in der Kommuni-kation reagieren, andererseits kann für die übermittelten Nachrichten nachge-wiesen werden, dass sie den Empfänger erreicht haben (Schutzziel der Nich-tabstreitbarkeit).

Das wird erreicht, indem zwischen Sender und Empfänger eine Vermittler-schicht eingezogen wird, die von den Kommunikationsteilnehmern praktischtransparent genutzt wird. Die Nachricht wird über die Reliable MessagingSource an die Zwischenschicht übergeben, durch entsprechende Mechanis-men abgesichert zugestellt und von der Reliable Messaging Destination dem



eigentlichen Empfänger übergeben. Die Kommunikation basiert auf SOAP undWSDL. An die Übermittlung können unterschiedliche Anforderungen gestelltwerden: AtLeastOnce (mindestens einmal), AtMostOnce (höchstens einmal),ExactlyOnce (genau einmal) sowie, kombinierbar mit jedem der anderen, In-Order (in der ursprünglichen Reihenfolge). Wenn die geforderte Übermittlungnicht möglich ist, wird dem Absender ein Fehler gemeldet.

Zu WS-ReliableMessaging gehört auch WS-Reliable Messaging Policy Asser-tion, womit sich Richtlinien rund um die verlässliche Nachrichtenübermittlungbeschreiben lassen, die in WS-Policy eingebunden werden können.

WS-Transaction

WS-Transaction ist ein Standard, der das aus der Datenbankwelt bekannteKonzept der Transaktion für Web-Services bereitstellt. Ziel ist, bei Operatio-nen in komplexen Umgebungen gemeinsame Aktivitäten zu koordinieren undein transparentes und konsistentes Verhalten aller beteiligten Dienste zu ge-währleisten.

Dafür werden drei Unterspezifikationen bereitgestellt: WS-Coordination zurKoordinierung von Aktivitäten, WS-AtomicTransaction für kurz laufendeTransaktionen und WS-BusinessActivity für länger laufende Transaktionen.

WS-Coordination

WS-Coordination bietet einen erweiterbaren Rahmen, der Protokolle be-schreibt, die die Koordinierung von Web-Service-Aktivitäten in verteilten Sy-stemen erlauben. Damit kann zwischen mehreren Beteiligten eine Überein-kunft hergestellt werden, wie das Ergebnis ihrer aus einzelnen Aktivitäten be-stehenden Transaktion aussehen soll. Es stellt auch eine Abstraktionsmög-lichkeit für bestehende Koordinationssysteme wie zum Beispiel Arbeitsabläu-fe (Workflows) dar.

Eine zentrale Stelle (Coordination Service) übernimmt die Koordination underlaubt die Registrierung der Teilnehmer innerhalb eines Koordinationskon-textes.

WS-AtomicTransaction

WS-AtomicTransaction basiert auf WS-Coordination und spezifiziert nur nochdie Protokolle für kurz laufende Transaktionen, für die die ACID-Eigenschaf-ten wichtig sind: Atomicity (Abgeschlossenheit), Consistency (Konsistenzer-haltung), Isolation (Isolation), Durability (Dauerhaftigkeit).

Dafür werden folgende Protokolle vorgesehen: Completion (für den Initiatorder Transaktion), Volatile Two-Phase Commit (für Teilnehmer mit flüchtigenRessourcen wie zum Beispiel Caches) und Durable Two-Phase Commit (fürTeilnehmer mit nicht flüchtigen Ressourcen wie zum Beispiel Datenbanken).

Eine Atomic Transaction kann nur erfolgreich beendet werden, wenn alle Tei-laufgaben erfolgreich beendet wurden. Da vorausgesetzt wird, dass sich al-le Teilnehmer kooperativ verhalten, sollten Atomic Transactions nur in einemvertrauenswürdigen Umfeld eingesetzt werden.

WS-BusinessActivity

WS-BusinessActivity basiert ebenfalls auf WS-Coordination und definiert denKoordinationstyp Business Activity. Dieser Koordinationstyp ist für den Einsatz



bei langlebigen Aktivitäten mit Teilnehmern unterschiedlicher Vertrauenswür-digkeit (Trust Domains) gedacht.

Eine Business Activity erlaubt den Teilnehmern die wechselseitige Überein-kunft bezüglich verteilt auszuführender Operationen. Ein wesentliches Merk-mal ist, dass Operationen beliebig verschachtelt werden können (Nested Sco-pes). Dabei kann auch auf Atomic Transactions zurückgegriffen werden.

Im Unterschied zur Atomic Transaction kann eine Business Activity auch dannerfolgreich beendet werden, wenn einzelne, untergeordnete Aktivitäten schei-tern. Die Entscheidung darüber ist vom Initiator der Aktivität zu treffen. Damitsind auch komplexe Geschäftsprozesse und Entscheidungsabläufe abbildbar,und es können Teilnehmer unterschiedlicher Kooperationsfähigkeit eingebun-den werden.

WS-Trust

WS-Trust ist eine Erweiterung von WS-Security und ermöglicht den Aus-tausch von zugesicherten Eigenschaften bestimmter Subjekte innerhalb undzwischen Domänen (Trust Domänen). Dabei geht es um das Herausgeben,Erneuern und Validieren von Security Tokens sowie die Vermittlung, den Auf-bau und die Bewertung eines sicheren Nachrichtenaustauschs.

WS-Trust umfasst die Beschreibung eines Web-Service, der mit WS-Securitykompatible Security Tokens herausgibt (Security Token Services, STS). Zu-dem wird das Format von Nachrichten festgelegt, die für die Kommunikationrund um Security Tokens Verwendung finden, sowie Mechanismen zum Aus-tausch kryptografischer Schlüssel.

WS-SecureConversation

WS-SecureConversation verfolgt den Ansatz einer sitzungsbasierten Sicher-heit. Somit unterstützt WS-SecureConversation einen Sicherheitskontext, dernach der ersten Authentisierung generiert wird. Der Sicherheitskontext erlaubteine fortdauernde abgesicherte Kommunikation über mehrere Nachrichtenoder Transaktionen hinweg und senkt damit den Aufwand für die Absicherungder Kommunikation. Dieser Standard sollte insbesondere dann angewendetwerden, wenn eine hohe Anzahl an Nachrichten zwischen Web-Services aus-getauscht werden muss.

Der durch WS-Secure-Conversation generierte Sicherheitskontext bestehtaus einem gemeinsamen Sitzungsschlüssel, der auch als SecurityContextTo-ken-Element bezeichnet wird. Der Austausch des Tokens zwischen den Par-teien erfolgt durch das Diffie-Hellmann-Verfahren und wird dann für die Ver-und Entschlüsselung verwendet. Zur Generierung des Sicherheitskontextesstehen die folgenden Möglichkeiten bereit:

- Nutzung eines Security Token Services (STS) mit WS-Trust: Die Kommu-nikationspartner vertrauen einem externen Dienst, der für das Erzeugender Token verantwortlich ist.

- Erzeugung und Verteilung durch einen Kommunikationspartner: Ein Kom-munikationspartner ist für das Erzeugen und Verteilen des Tokens verant-wortlich. Das setzt voraus, dass alle Beteiligten dem Aussteller vertrauen.

- Erzeugung mit einem Challenge/Response-Verfahren.

Zusätzlich existieren Mechanismen, um einen Sicherheitskontext zu erneuern,abzuändern, zu erweitern oder aufzukündigen.



WS-Federation

WS-Federation steht in engem Zusammenhang mit WS-Security und be-schreibt eine flexible Infrastruktur für föderierte Identitäten. Bei diesem Kon-zept werden Identitäten nicht von einer zentralen Instanz verwaltet, sondernvon verteilten Instanzen, die jeweils für eine bestimmte Gruppe von Identi-täten zuständig sind (zum Beispiel Für die Mitarbeiter einer Institution). Dieeinzelnen Instanzen zur Identitätsverwaltung sind miteinander verbunden undvertrauen sich gegenseitig. WS-Federation erlaubt die Vermittlung von Identi-täten, Attributen und Authentisierungsvorgängen zwischen unterschiedlichenSicherheitskontexten. Dabei wird auf WS-Trust und WS-MetadataExchangezurückgegriffen.

WS-SecurityPolicy

Web Service Security Policy Language (WS-SecurityPolicy) beschreibt sicher-heitsbasierte Policy Assertions. Damit sind spezielle Zusicherungen gemeint,die Web-Services erfüllen müssen, damit sicherheitsrelevante Aspekte erfülltsind.

Die Spezifikation erweitert die fundamentalen Sicherheitsprotokolle, die inWS-Security, WS-Trust und WS-SecureConversation spezifiziert sind, indemMechanismen angeboten werden, die Anforderungen und Fähigkeiten vonWeb-Services als Zusicherungen (Policies) darzustellen.

Web Single Sign-On

Web Single Sign-On Interoperability Profile und Web Single Sign-On Metada-ta Exchange Protocol sind Spezifikationen zum Identitätsmanagement, die dieInteroperabilität mit Protokollen der WS-Federation und der Liberty Alliancesicherstellen sollen. Sie basieren unter anderem auf SAML und WS-Metada-taExchange.

Ziel ist es, das Identitätsmanagement bestehender Lösungen in Web-Serviceszu integrieren und den Zugriff auf Eigenschaften der hinterlegten Identitätenzu ermöglichen. Damit ist eine plattformübergreifende, zentralisierte Identitäts-verwaltung möglich, die eine Zugriffssteuerung für Web-Services mit einbe-zieht.

WS-BPEL

Die Web Services Business Process Execution Language (WS-BPEL) ist ei-ne Sprachdefinition zur Spezifizierung von Web-Service-Aktivitäten innerhalbvon Geschäftsprozessen. Sie wird zur Beschreibung der Orchestrierung vonWebservices verwendet und basiert auf WSDL. Die Beschreibung selbst wirdwiederum als Web-Service bereitgestellt.

Neben Basic Activities (grundlegende Aktivitäten) und Structured Activities(komplexe Abläufe von Aktivitäten) sind auch Scopes (gebündelte Aktivitäten)vorgesehen, die auch eine Fehlerbehandlung, eine Ereignisbehandlung, ei-ne Terminationsbehandlung sowie eine Kompensationsbehandlung erlauben.Damit werden auch langandauernde Transaktionen ermöglicht.

Durch funktionale Aufspaltung und die Komposition von Web-Services ist einhohes Maß an Flexibilität gewährleistet.

Mit den Erweiterungen WS-BPEL4People und WS-HumanTask lässt sichauch menschliche Interaktion in Geschäftsprozessen adressieren.



WS-CDL

Web Services Choreography Description Language (WS-CDL oder auch WS-Choreography) wird zur Choreografie von Web-Services eingesetzt. Die XML-basierte Sprache beschreibt die unmittelbare Kommunikation zwischen Web-Service-Akteuren aus der Beobachterperspektive, indem das Verhalten derAkteure definiert wird.

Dabei werden mit der Kommunikationsstruktur die nicht-funktionalen Eigen-schaften eines Web-Service beschrieben. Das Ziel ist, ein globales Szenariozu beschreiben, dem die Akteure in ihrem Verhalten folgen, das aber keinezentrale Kontrollinstanz kennt.

Eine Choreografie definiert wiederverwendbare allgemeine Regeln, die denNachrichtenaustausch zwischen Akteuren steuern, und die möglichen Musterkollaborativen Verhaltens, die zwischen zwei oder mehr zusammenwirkendenTeilnehmern vereinbart sind. Die Wiederverwendbarkeit der Vorschriften er-laubt die vereinfachte Komposition auch komplexer Choreografien.

OSCI

Online Services Computer Interface (OSCI) ist eine Protokollspezifikation fürdie öffentliche Verwaltung in Deutschland. Sie basiert auf bereits bestehendenStandards wie zum Beispiel den Sicherheitsstandards für XML (XML-Encryp-tion und XML Signature), SOAP, SAML und einigen WS-*-Standards. Für dieAnforderungen der öffentlichen Verwaltung wurden spezielle Erweiterungendefiniert. Ziel ist die sichere, vertrauliche und rechtsverbindliche Übertragungelektronischer Daten über das Internet. Das Protokoll wird vom Bundesmini-sterium des Inneren als obligatorischer Standard für elektronische Transak-tionen mit der Bundesverwaltung gesetzt und ist die Basis für viele weitereSpezifikationen für XML in der öffentlichen Verwaltung (XÖV), zum Beispielzur elektronischen Datenübermittlung im Meldewesen.

Außerhalb von E-Government-Anwendungen der öffentlichen Verwaltung hatOSCI praktisch keine Bedeutung.

Als wesentliche Anforderungen an die Kommunikation wurden fünf Sicherheit-saspekte identifiziert und umgesetzt: Authentizität, Integrität und Vertraulich-keit sowie Nichtabstreitbarkeit und Zurechenbarkeit. Dabei wurden auch Er-fordernisse nach dem Signaturgesetz berücksichtigt. So ist es möglich, zwi-schen fortgeschrittener und qualifizierter elektronischer Signatur mit und ohneAnbieterakkreditierung gemäß Signaturgesetz zu wählen.

Mit der Version 2 des Standards wurde besonderes Gewicht auf die Anforde-rungen bei der Verwendung mit Web-Services gelegt. Die Erweiterung berück-sichtigte dementsprechend vor allem international anerkannte WS-Standards.



M 4.452 Überwachung eines Web-Service


Verantwortlich für Umsetzung: Administrator

Um den Sicherheitszustand eines Web-Service nachvollziehen zu können, istes notwendig, diesen kontinuierlich zu überwachen. Ziel einer solchen Über-wachung ist es, Verstöße gegen die geltenden Sicherheitsvorschriften zu ent-decken, bestehende Sicherheitslücken aufzudecken oder Fehlkonfiguratio-nen, die zu Sicherheitslücken führen können, zu erkennen.

Als Bestandteil des Sicherheitskonzeptes für einen Web-Service muss des-halb ein Überwachungskonzept entwickelt werden.

Komplexe Systeme wie Web-Services können in der Regel nicht mehr durcheinzelne Administratoren überwacht werden, sondern die Kontrolle muss au-tomatisch durch entsprechende Systemkomponenten oder Produkte erfolgen.Die Überwachung eines Web-Service muss bei Veränderungen entsprechendangepasst werden.

Des Weiteren müssen in der Planung zur Überwachung eines Web-Servicegrundsätzlich alle relevanten Komponenten berücksichtigt werden. Daher soll-ten im Überwachungskonzept beispielsweise auch Datenbanken und Ver-zeichnisdienste, abhängige und genutzte Web-Services sowie die relevantenIT-Systeme enthalten sein. Dies ist von besonderer Bedeutung, wenn unter-schiedliche Services über einen Enterprise Service Bus (ESB) miteinanderverbunden sind.

Überwachung von Verfügbarkeit und Leistung

Wenn Dienste ausfallen, ihre Schnittstellen ändern oder ihr Antwortzeitverhal-ten verschlechtern, kann das weitreichende Folgen auf eine Vielzahl von ab-hängigen Systemen haben. Die Verfügbarkeit und Leistung von Web-Servicesmüssen daher geeignet überwacht werden.

Neben der generellen Erreichbarkeit und Aktivität des Web-Service sowie derrelevanten Schnittstellen-Dienste und Abhängigkeiten sollten daher auch Lei-stungsparameter überwacht werden. Hierzu gehören beispielsweise:

- Antwortzeiten von Anfragen,- Anzahl der Anfragen beziehungsweise Anforderungen,- Größe von Anforderungen und Antworten oder- Füllstände von Speichern (zum Beispiel Speicher der JVM, Messa-

ge-Queues).

Dadurch können zum einen Fehlkonfigurationen oder technisch bedingte Eng-pässe sowie zum anderen Denial-of-Service-Angriffe frühzeitig erkannt undzeitnah behandelt werden.

Insbesondere bei höheren Anforderungen an die Verfügbarkeit und bei derVerteilung eines Web-Service über mehrere Systeme sollte die Lastverteilungüberwacht werden.



Meldungen

Des Weiteren sollten die Protokolldateien und Systemmeldungen (Notifica-tions) hinsichtlich relevanter Meldungen kontinuierlich ausgewertet werden.Hierzu sollte ein am Schutzbedarf ausgerichtetes Log-Level im jeweiligenWeb-Service konfiguriert werden (siehe auch M 4.397 Protokollierung sicher-heitsrelevanter Ereignisse von Web-Anwendungen und Web-Services). Fürdie Überwachung können beispielsweise die folgenden Meldungen relevantsein:

- Fehler- oder Warnmeldungen,- Meldungen zu Berechtigungsverstößen oder -änderungen (zum Beispiel

Vergabe von Administratorberechtigungen),- Meldungen zur Änderung von sicherheitsrelevanten Einstellungen,- Meldungen zu ungültigen XML-Nachrichten oder- Fehlermeldungen zur Inkonformität von Schnittstellen.

Meldungen mit einer höheren Kritikalität müssen zu einer Alarmierung einesverantwortlichen Mitarbeiters führen, um eine Reaktion in einem angemesse-nen Zeitraum sicherzustellen. Hierfür empfiehlt sich der Einsatz eines Alar-mierungssystems.

Überwachung von Policies

In diesem Zusammenhang sollten auch die unterschiedlichen Meldungen zuVerstößen gegen die eingesetzten Policies (zum Beispiel WS-Policies, WS-SecurityPolicies) berücksichtigt werden. Diese könnten beispielsweise bein-halten:

- Verstöße gegen die vordefinierte Nachrichtengröße,- Verstoß gegen die Verschlüsselungsanforderung an Nachrichten,- Fehler in der Ver- oder Entschlüsselung von Nachrichteninhalten,- Fehler in der Signatur von Nachrichteninhalten oder- fehlerhafte Authentisierung.

Überwachung der Verschlüsselung des Service

Werden aufgrund höherer Vertraulichkeitsanforderungen Verschlüsselungs-maßnahmen eingesetzt (zum Beispiel TLS), sollten diese hinsichtlich ihrerFunktionalität überwacht werden. Gerade durch die automatisierte Funktioneines Web-Service besteht die Gefahr, dass Fehler in der Verschlüsselungnicht rechtzeitig bemerkt werden.

Ansatzpunkte für eine Überwachung der Verschlüsselung sind beispielsweise:

- Aktualität und Gültigkeit des Zertifikats des Web-Service,- Aktualität und Gültigkeit der Zertifikate von anfragenden Diensten,- Fehler- oder Warnmeldungen beim Aufbau von verschlüsselten Verbin-

dungen (zum Beispiel Warnmeldungen bei veralteten SSL-Versionen)

Auswertung durch Schwellwerte und Trends

Um Bedrohungen und Schwachstellen rechtzeitig erkennen zu können, ist eserforderlich, Schwellwerte zu definieren sowie Trends aus den überwachtenWerten abzuleiten, zum Beispiel für den belegten Speicherplatz, die Syste-mauslastung oder die genutzte Bandbreite. Anhand der Schwellwerte und je-weils kritischen Trendrichtungen sollten im Rahmen des Überwachungskon-zepts Handlungsanweisungen definiert werden.



Prüffragen:

- Existiert ein Überwachungskonzept für Web-Services?- Existiert eine angemessene Verfügbarkeits- und Leistungs-

Überwachung?- Werden Meldungen der Betriebssysteme und Dienste angemessen

überwacht? Ist eine zeitnahe Reaktion auf kritische Meldungensichergestellt?

- Werden die eingesetzten Policies hinsichtlich ihrer Einhaltung überwacht?- Werden die Verschlüsselungsfunktionen angemessen überwacht?- Wurden Schwellwerte und Trends definiert und mit

Handlungsanweisungen untersetzt?



M 4.453 Einsatz eines Security TokenService (STS)

Verantwortlich für Initiierung: Leiter ITVerantwortlich für Umsetzung: Administrator

Ein Security Token Service (STS) ist ein Web-Service, über den Identitäts-und Berechtigungsinformationen angefordert, erneuert und überprüft werdenkönnen. Das Prinzip ist das eines Claims-based (deutsch etwa anspruchsba-sierten) Identitätsmodells, wobei ein Anspruch (Claim) eine Aussage einer En-tität über eine andere Entität oder sich selbst bedeutet, etwa über einen Be-nutzernamen oder ein bestimmtes Recht. Ein STS kann genutzt werden, umdie Authentisierung und Autorisierung auszulagern oder, wenn mehrere An-wendungen oder Dienste den STS nutzen, einen Single Sign-on zu realisie-ren. Grundsätzlich wird eine Entkopplung von Diensten und ihren Aufrufernvorgenommen, nach der ein Dienst nicht mehr jedem einzelnen Aufrufer hin-sichtlich der übermittelten Identitätsinformationen direkt vertrauen muss, son-dern lediglich einem STS. Der Aufrufer kann dabei ebenfalls ein Web-Servicesein (Web-Service-Authentisierung), aber auch eine Client-Anwendung oderein Browser (passiver Client), wobei in letzterem Fall der STS als Webanwen-dung auftritt (Web-SSO).

Eine Vereinfachung entsteht dadurch, dass nicht mehr jede Anwendung oderjeder Dienst die Authentisierung von Benutzern, die Verwaltung von Benutzer-konten und Kennwörtern, die Anbindung an Verzeichnisdienste und die Inte-gration in weitere Identitäts- und Zugriffskontrollsysteme der Institution beherr-schen muss. Naturgemäß hat dieser Architekturwechsel jedoch bedeutendeAuswirkungen auf Sicherheitsfragen.

Da der STS selbst auch einen Web-Service darstellt, sind für ihn die Maßnah-men des Bausteins B 5.24 Web-Services ebenfalls umzusetzen. Diese Maß-nahme umfasst im Folgenden zusätzlich die Aspekte der Nutzung eines STSdurch einen anderen Web-Service, gegebenenfalls auch aus einer anderenInstitution heraus.

In der Praxis ist häufig ein STS bereits gegeben. Wird ein nicht selbst betrie-bener STS genutzt, handelt es sich um ein Outsourcing von Authentisierungs-funktionen. Es sind daher auch die Maßgaben des Bausteins B 1.11 Outsour-cing und gegebenenfalls des Bausteins B 1.17 Cloud-Nutzung zu beachten.Bei einer Individualvereinbarung mit dem STS-Anbieter sind vertragliche Re-gelungen derart zu treffen, dass der Schutz der durch die Zugriffskontrolle ge-sicherten Daten gewährleistet ist. Andernfalls sind die Vertragsbedingungendes Anbieters genau daraufhin zu prüfen, ob diese dem Schutzbedarf gerechtwerden. Ob ein bestimmter STS für eine Anwendung verwendet werden darf,hängt vom Schutzbedarf der Anwendung und der Möglichkeit weiterer Maß-nahmen ab, den Schutz der Zugriffskontrolle eventuell noch zu verstärken,zum Beispiel durch eine Zwei-Faktor-Authentisierung. Hier ist das Vertrauenin den Anbieter durch klare Kriterien und die Stichhaltigkeit ihrer Einhaltungzu begründen.

Aber auch, wenn der STS innerhalb der eigenen Institution betrieben wird, fin-det durch die Auslagerung der Authentisierung eine Vererbung des Schutzbe-darfs auf den STS statt, der mit Kumulationseffekten einhergeht, wenn meh-rere Anwendungen oder Dienste als Konsumenten auftreten.



Es ist davon auszugehen, dass ein STS seinen Schutzbedarf bezüglich Ver-traulichkeit und Integrität nach dem Maximumprinzip von den Daten erbt, aufdie durch seine Verwendung zugegriffen werden kann. Bezüglich der Verfüg-barkeit ist das ebenfalls der Fall, wenn die Nutzung des STS die einzige effek-tiv nutzbare Möglichkeit der Authentisierung darstellt. Zusätzlich sind Kumu-lationseffekte zu berücksichtigen, falls der STS die Authentisierung für einehohe Anzahl von Diensten oder institutionen übernimmt.

Hinzu kommt, dass am STS nicht nur die Information vorliegen muss, wel-cher Benutzer welche Ansprüche hat, sondern durch die Anfragen nach To-kens auch Daten anfallen, welcher Benutzer welchen Dienst wie oft und inwelchem Kontext nutzt. Bei menschlichen Benutzern ist hier die Privatsphärezu betrachten (etwa durch Beachtung von Baustein B 1.5 Datenschutz), beimaschinellen die Vertraulichkeit der Metadaten.

Die Realisierung eines STS ist mittels verschiedener Techniken (zum BeispielREST) möglich, praktisch werden STS allerdings häufig mittels SOAP imple-mentiert. Hierbei kommen im Allgemeinen Standards aus der WS-*-Familiezum Einsatz, um die Funktionalität und Interoperabilität zu gewährleisten.

Der Begriff des Security Tokens ist im Standard WS-Security definiert als jeg-liches Datenobjekt, das einen oder mehrere Claims, also verbürgte Aussagenüber eine Entität, enthält und einer SOAP-Nachricht hinzugefügt werden kann.Häufig werden Security Tokens digital signiert, um die Aussagekraft krypto-graphisch nachzuweisen.

WS-Security unterstützt verschiedene Typen von Security Tokens, etwa dasUsernameToken für die Authentisierung mittels Benutzername und Passwort.Das Passwort wird dabei als Hashwert übertragen, in dessen Berechnung ei-ne Nonce (Zufallswert) und ein Zeitstempel einfließen, um Replay-Angriffe zuverhindern. Ein anderer vorgesehener Tokentyp ist das BinarySecurityTokenfür nicht XML-basierte Formate wie etwa X.509-Zertifikate. Weitere Tokenty-pen sind über einen Erweiterungsmechanismus vorgesehen.

Die meisten STS nutzen heute Token, die in der Security Assertion MarkupLanguage (SAML) beschrieben werden. Dabei handelt es sich um einen ver-breiteten Standard zur Beschreibung von Claims. Ein SAML Security Token(genauer eine SAML Assertion; die Spezifikation enthält außerdem noch wei-tere Elemente, die jedoch vor allem für Web-SSO benötigt werden) ist eineBeschreibung von Identitätsinformationen, Attributen, Authentisierungs- undAutorisierungsentscheidungen in XML, welche für eigene Zwecke erweiterbarist.

Der SAML-Standard hat sich von Version 1.1 zu Version 2.0 bedeutend er-weitert und umfasst nun weitere Protokolle und Einsatzszenarien (Profiles),welche sich vor allem um Web-SSO drehen. In jedem Fall ist eine grundlegen-de Entscheidung für einen in ausgereiften und in interoperablen Implementa-tionen vorliegenden Satz von Standards zu treffen, die miteinander und mitden geplanten Kommunikationspartnern kompatibel sind und den jeweiligenSicherheitsanforderungen gerecht werden.

In der Spezifikation WS-Trust, welche auf WS-Security aufbaut, wird der STSselbst mit seinen Aktionen definiert. Wenn ein Server eine Authentisierungverlangt, schickt der Client einen Request for Security Token (RST), zum Bei-spiel mit seinem Benutzernamen und Passwort in Form eines UsernameTo-ken, an den STS. Hierin kann spezifiziert werden, welcher Tokentyp benötigtwird, welche Claims im Token enthalten sein sollen und wie das auszustel-



lende Token zu sichern ist. Der STS liefert eine Request for Security TokenResponse (RSTR) zurück, die das Security Token enthält, welches der Clientnun dem Server präsentieren kann. Dieser kann es je nach Szenario entwederanhand der Signatur selbst überprüfen oder wiederum dem STS zur Überprü-fung vorlegen.

Damit Sicherheitstoken als vertrauenswürdig gelten können, sollten sie ent-weder verifizierbar signiert sein, oder die Übertragung muss auf anderem Wegdurchgängig abgesichert sein, etwa auf Transportebene. Da die Signatur ei-nes STS allerdings auch der Bestätigung der Claims in einem Security Tokendient, müsste ihr Fehlen durch andere Maßnahmen wie etwa eine sichere Au-thentisierung während des Austauschs ausgeglichen werden.

Vertrauliche Daten wie etwa Passwörter dürfen nie ungesichert zu einem STSoder von diesem zum Konsumenten übertragen werden. Hier ist immer einsicheres Hash-Verfahren mit Zufallskomponente (Salt, zum Beispiel mit Non-ce) einzusetzen. Zusätzlich sind Replay-Angriffe durch geeignete Methoden,etwa den Einsatz von Zeitstempeln, zu verhindern, falls der Transportkanaldiese nicht schon zuverlässig unterbindet.

Wenn das Security Token nicht den direkten, verschlüsselten Weg vom STSzum Server nimmt, muss auch dessen Inhalt durch Verschlüsselung geschütztwerden, um zu verhindern, dass unbefugte Dritte das Token zur Authentisie-rung einsetzen können. Hierfür reicht es, den kryptographischen Teil, also dieSignatur des STS, zu verschlüsseln. Enthält die Assertion jedoch weitere ver-trauliche Daten, sind auch diese zu schützen. Grundsätzlich ist aber die be-nötigte Vertraulichkeit durch das Prinzip der Datensparsamkeit zu minimieren,indem immer nach möglichst allgemeinen Claims (zum Beispiel "Benutzer istvolljährig") gefragt wird.

Als weitere Schutzmaßnahme ist eine kurzfristige Lebensdauer für Token jenach Schutzbedarf anzusetzen, um den Schaden bei missbräuchlicher Ver-wendung zu verringern. Die meisten Frameworks geben hier Standards vor,die nach Möglichkeit verkürzt werden sollten.

Durch die vielen ineinander spielenden Standards samt ihrer verschiedenenVersionen und Standardisierungsgrade haben in der Vergangenheit Imple-mentierungen häufig Schwachstellen aufgewiesen, die die Sicherheit erheb-lich beeinträchtigt oder sogar ausgehebelt haben. Da es sich bei den zugrun-deliegenden Sicherheitsfunktionen um XML-Encryption, XML-Signaturen so-wie häufig TLS/SSL handelt, spielen entsprechende Angriffe auch hier eineRolle, was umso schwerer wiegt, je mehr kritische Autorisierungsentscheidun-gen von dem STS getroffen werden.

Angriffe wie XML Signature Wrapping, also die böswillige Änderung einerNachricht, ohne dass die Signatur ungültig wird, werden vor allem dadurchmöglich, dass die Erzeugung und Prüfung von Signaturen nicht aufeinanderabgestimmt sind. Hier sollten entweder dieselbe Softwarebasis zum Einsatzkommen, oder, wenn dies nicht möglich ist (zum Beispiel externe STS, XML-Gateways), ausgiebige Tests der Schnittstellen nach jeder Anpassung statt-finden. Grundsätzlich sind etablierte, gut getestete Bibliotheken und Frame-works zur Realisierung der STS-Funktionalität auszuwählen, zu denen Infor-mationen über Schwachstellen und Sicherheitspatches zeitnah bereitstehenund eingespielt werden müssen. Bei der Absicherung der Kommunikations-wege ist Maßnahme M 4.450 Absicherung der Kommunikation bei Web-Ser-vices zu beachten.



In jedem Fall ist bei der Komplexität der Materie unbedingt Sachverstand be-züglich des sicheren Einsatzes eines STS bereits während der Konzeptions-phase hinzuzuziehen.

Prüffragen:

- Wurde auch der STS selbst als Web-Service modelliert und entsprechendangemessene Maßnahmen aus dem Baustein B 5.24 Web-Servicesumgesetzt?

- Wurden bei Nutzung eines fremden STS die Maßnahmen des BausteinsB 1.11 Outsourcing und B 1.17 Cloud-Nutzung beachtet?

- Wurde die SSL/TLS Konfiguration vor der Freigabe zur Nutzung aufFehler geprüft und wird der Status in periodischen Abständen validiert?

- Entsprechen die vertraglichen Regelungen mit dem STS-Betreiber demSchutzbedarf der über den STS zugänglichen Daten und Anwendungen?

- Wurde die Vertraulichkeit der am STS anfallenden Daten betrachtet?- Wird die Datensparsamkeit durch möglichst allgemeine Claims

konsequent durchgesetzt?- Wurden ausgereifte Bibliotheken und Frameworks für die Nutzung der

STS-Funktionalität ausgewählt, für die auch aktuelle Informationen überSchwachstellen und Sicherheitspatches verfügbar sind?

- Werden entweder Token signiert oder der Transportkanal durchgängigverschlüsselt und authentisiert?

- Werden alle Passwörter nur als Hashwert übertragen mit Schutz gegenBrute-Force- und gegen Replay-Angriffe?

- Wurde die Lebensdauer für Security Token möglichst niedrig gewählt?



M 4.454 Schutz vor unerlaubter Nutzungvon Web-Services



Um zu gewährleisten, dass Web-Services nur von berechtigten Parteien ge-nutzt werden dürfen, ist es erforderlich, konkrete Anforderungen an die Au-thentisierung und Autorisierung einzelner Benutzer oder Clients zu stellen.Diese Anforderungen müssen im Rahmen eines sorgfältig gewählten Authenti-sierungs- und Autorisierungsmodells durch einen oder eine Kombination meh-rerer verfügbarer WS-Standards realisiert werden. Dies gewährleistet die Ein-schränkung und Kontrolle einzelner Zugriffe auf den Web-Service. WelcheWeb-Service-Standards für die Umsetzung einer geeigneten Authentisierungund Autorisierung eingesetzt werden können, ist näher in den MaßnahmenM 4.456 Authentisierung bei Web-Services und M 4.455 Autorisierung beiWeb-Services beschrieben.

Um Angriffe auf einen Web-Service zu erschweren, die im schlimmsten Fallzu einer Umgehung des Berechtigungssystems führen und somit unberech-tigten Zugriff auf vertrauliche Daten oder schützenswerte Funktionen ermög-lichen, sollten zusätzliche Maßnahmen gegen Brute-Force-Angriffe oder an-dere automatisierte Angriffe auf Web-Services ergriffen werden. Automatisier-te Angriffe zeichnen sich durch eine hohe Zahl an Zugriffsversuchen inner-halb einer kurzen Zeitspanne aus. Hoch frequentierte Anfragen (zum Beispielzum Erraten von Passwörtern) sollten durch festgelegte Schwellwerte erkanntwerden und zu geeigneten Reaktionen führen (Alarmierung von Verantwortli-chen, Sperrung des Zugangs). Solche Schwellwerte können sich zum Beispielauf die Anzahl der Zugriffe, Fehlanmeldungen, die übertragene Datenmengeoder die Größe der übertragenen XML-Nachrichten beziehen. Im Falle eineserkannten Angriffsversuches kann eine temporäre Sperrung des Zugangs er-folgen. Eine Alternative zur Sperrung des Zugangs ist die inkrementelle Ver-zögerung von Antworten (das heißt eine bei jedem Fehlversuch ansteigendeWartezeit), die automatisierte Angriffe effektiv ausbremst.

Bei der Festlegung von Schwellwerten ist darauf zu achten, dass legitimeDienstnutzer (Clients und ihre Benutzer, andere Web-Services) nicht in derFunktionalität und der Bedienung des Web-Service eingeschränkt werden.

Grundsätzlich sollte immer sichergestellt werden, dass nur berechtigte Syste-me oder Benutzer auf den Web-Service zugreifen dürfen. Durch eine Firewallkann sichergestellt werden, dass nur berechtigte IP-Adressen oder IP-Adress-blöcke auf den Web-Service zugreifen können. In geschlossenen Umgebun-gen bietet sich dieser Whitelisting-Ansatz an. Wird ein Web-Service betrieben,der aus dem Internet erreichbar sein soll (zum Beispiel APIs zur freien Nutzungdurch Dritte), empfiehlt sich ein Blacklisting-Ansatz. Durch die Sperrung be-kannter IP-Adressen, die zum Beispiel Spam-Servern zugeordnet werden kön-nen, kann sichergestellt werden, dass Zugriffe von Systemen ausgeschlossenwerden, die als bösartig angesehen werden müssen. Auch unberechtigte Zu-griffe aus bestimmten Regionen oder Ländern können durch solche Sperrli-sten verhindert werden. Alternativ kann die Sperrung von IP-Adressblöckenauch direkt beim Provider veranlasst werden. Durch eine entsprechende Kon-figuration der Firewall kann auch sichergestellt werden, dass auffällig häufigeAufrufe aus einem IP-Adressbereich oder von einer einzelnen IP-Adresse be-



grenzt werden, um so einem potenziellen Denial-of-Service-Angriff entgegen-zuwirken.

Eine weitere Möglichkeit, den Zugriff auf einen Web-Service nur für berechtig-te Benutzer einzuschränken, bietet der Einsatz eines VPNs. Durch ein Stand-ort-zu-Standort-VPN kann beispielsweise sichergestellt werden, dass nur einausgewählter Kreis von Geschäftspartnern unter Wahrung der Vertraulichkeitund Integrität auf den Web-Service zugreifen darf. Weitere Hinweise zum Ein-satz eines VPNs finden sich im Baustein B 4.4 VPN. Ein VPN trägt zum Schutzdes Web-Service bei, da keine externen Brute-Force-Angriffe auf den Web-Service durchführbar sind, wenn dieser nur aus einem internen Netz erreich-bar und somit nicht im Internet exponiert ist.

Web-Services sind oft darauf ausgelegt, dass diese sowohl intern als auch ex-tern (zum Beispiel durch Geschäftspartner) aufgerufen werden können, wobeijeweils ein Zugriff auf unterschiedliche Funktionen erfolgen kann. Externe Be-nutzer dürfen zum Beispiel nur in der Lage sein, eine Bestellung aufzugeben,während die internen Benutzer auch die Möglichkeit haben sollten, die ein-gegangenen Bestellungen zu verwalten und zu bearbeiten. Oft werden dieseunterschiedlichen Funktionen über ein und denselben Web-Service-Endpunktangeboten. Dadurch, dass allerdings alle Funktionen über den selben End-punkt aufrufbar sind, kann ein externer Angreifer durch Auslesen der WSDL-Datei oder andere Verfahren der Informationsgewinnung Aufrufpunkte der in-ternen Funktionen ermitteln, um Daten zu manipulieren oder auszulesen. Ausdiesem Grund sollte bei der Realisierung des Web-Service darauf geachtetwerden, dass die Bereitstellung von Funktionen für interne und externe Auf-rufer nicht auf dem selben Endpunkt erfolgt. Idealerweise befinden sich dieunterschiedlichen Web-Service-Endpunkte auf unterschiedlichen Systemen.Durch die Trennung der zugehörigen URLs kann dann auch eine feingranula-re Kontrolle auf den Web-Service durch eine Firewall erzielt werden, da derWeb-Service durch unterschiedliche URLs und Ports, oder sogar nur aus be-stimmten Netzen aufrufbar ist.

Sofern nicht gewollt ist, dass auf bestimmte Operationen zugegriffen wer-den kann, kann auch die Beschreibung der XML-Struktur (Schema) für denDienstaufruf derart modifiziert werden, dass die unerwünschten Operationenentfernt werden. Sofern eine Anfrage gestellt wird, die eine aus dem Schemaentfernte Operation enthält, wird diese im Rahmen der Validierung der XML-Anfrage gegen das Schema als nicht valide identifiziert und entsprechend ab-gelehnt.

Die Zugriffsbeschränkung auf einen Web-Service über Authentisierung undAutorisierung der Dienstnutzer kann sich als wirkungslos erweisen, wenn derAngriff seinen Effekt zeigt, bevor die Mechanismen der Zugriffskontrolle zurGeltung kommen. Aus diesem Grund muss im Vorfeld eine adäquate Validie-rung der gesamten Nachricht erfolgen, bevor der Web-Service diese weiterverarbeiten darf. Dieser Prozess wird auch als Schemavalidierung bezeich-net. Durch die Schemavalidierung wird sichergestellt, dass Nachrichten undAngriffe abgewehrt werden, die vom definierten Schema abweichen. Dies be-deutet, dass das Schema so restriktiv wie möglich zu gestalten ist, das heißtnur eine begrenzte Menge an XML-Formaten zur Nutzung des Dienstes ver-fügbar sein darf. Bei der Schemavalidierung ist es daher notwendig, das Sche-ma so einzuschränken, dass Nachrichten mit bekannten Angriffsmustern aus-geschlossen werden. Zusätzlich ist es notwendig, die Nachricht auf bestimm-te Zeichenfolgen zu untersuchen, die eventuell für Injection-Angriffe genutztwerden können (siehe G 5.174 Injection-Angriffe).



Weiter müssen die Schemata eines Web-Service so angepasst werden, dassnur Nachrichten bis zu einer bestimmten Größe verarbeitet werden können.Die Verarbeitung einer übergroßen Nachricht kann die Ressourcen des ver-arbeitenden Systems auslasten und somit zu Leistungseinbußen oder Ausfäl-len führen. Bei der Beschränkung der Nachrichtengröße ist darauf zu achten,dass keine unbeschränkten Nachrichtenteile verarbeitet werden dürfen, diefolgende Merkmale besitzen:

- xsd:any,- xsd:anyType,- xsd:anySimpleType,- rekursive Definition von Elementen oder Typen,- unbeschränkte Listen.

Die Validierung eines Schemas kann entweder bereits an einem XML-Gate-way oder direkt auf dem System erfolgen, welches den Web-Service bereit-stellt. Die Entscheidung, an welcher Stelle die Validierung erfolgen soll, ist be-reits während der Planungsphase zu treffen, da dies auch Auswirkungen aufdie Gesamtarchitektur haben kann.

Prüffragen:

- Wurden geeignete Standards für die Authentisierung und Autorisierunggewählt und umgesetzt?

- Sind Maßnahmen umgesetzt, die automatisierte Angriffe erkennenund abwehren können, zum Beispiel durch die Überwachung vonSchwellwerten für Anfragen?

- Ist darüber hinaus sichergestellt, dass nur berechtige Teilnehmer auf denWeb-Service zugreifen dürfen?

- Erfolgt eine Trennung zwischen internen und externen Operationen undist sichergestellt, dass nur die jeweiligen Benutzer die für sie benötigtenOperationen aufrufen dürfen?

- Wurde das XML-Schema entsprechend restriktiv aufgebaut, und wird dieEinhaltung des Schemas überprüft?



M 4.455 Autorisierung bei Web-ServicesVerantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter

IT, Verantwortliche der einzelnenAnwendungen


Autorisierung

Während Authentisierung das Ziel hat, eine behauptete Identität zu verifizie-ren, bezweckt die Autorisierung die Überprüfung, ob eine zuvor authentisier-te Entität befugt ist, auf bestimmte Ressourcen zuzugreifen. Beide Begriffeergänzen sich also zu den Bestandteilen von Identitäts- und Zugriffsmanage-ment (englisch Identity and Access Management, IAM), und vor jeder Auto-risierung muss entsprechend eine Authentisierung erfolgt sein. Das wichtig-ste Prinzip der Autorisierung ist, dass bei jedem Zugriff auf eine Ressourcegeprüft werden muss, ob die Berechtigungen der anfragenden Entität diesenerlauben - und zwar bei jeder Aktion, sprich im Fall von Web-Services jedereinzelnen Anfrage.

Rollen und RechteRollen-und- Rechte-Modell

Die Zuordnung und Verwaltung von Einzelberechtigungen zu jedem einzel-nen Benutzer ist bei komplexeren Anwendungen nicht sinnvoll umsetzbar. Da-her muss ein geeignetes Rollenmodell entwickelt werden, bei dem den Benut-zern jeweils ihren Aufgaben entsprechende Rollen zugewiesen werden kön-nen, über die sie die erforderlichen Berechtigungen erhalten.

Besondere Herausforderungen bei Web-Services

Bei Web-Services und insbesondere bei Serviceorientierten Architekturen(SOA) gibt es im Gegensatz zu monolithischen Anwendungen nicht nur einen,sondern mehrere Punkte, an denen diese Überprüfung stattfinden muss, denndie Durchsetzung von Zugriffsregeln (Policies) hat am Zugriffspunkt zu jedemDienst stattzufinden. Diese Überprüfungspunkte werden auch als Policy En-forcement Points (PEP) bezeichnet. Sowohl die Planung als auch die prakti-sche Administration solcher Regelwerke ist eine komplexe Herausforderungund sollte in einem zentralen Tool durchführbar sein.

Die Autorisierungsprüfinstanz muss in der Lage sein, Web-Service-Nachrich-ten zu lesen. Oft werden solche Prüfungsinstanzen auch selbst als Web-Ser-vice realisiert und nutzen Web-Service-Standards für die Abbildung von Rol-len und Rechten.

Organisationsübergänge

Besondere Herausforderungen stellen sich, wenn die Web-Service-NutzungOrganisationsgrenzen überschreitet. Dann müssen Konzepte gefunden undRegelungen getroffen werden, wie mit Autorisierungsentscheidungen bei An-fragen aus und an andere Organisationen umgegangen wird. EntsprechendeVertrauensbeziehungen sollten immer durch formale Regelungen und Rech-temodelle konkretisiert werden.

Schichten

Da moderne Anwendungen und damit auch Web-Services typischerweise inmehreren Schichten (mindestens zwei, besser drei, etwa Präsentation, Ge-schäftslogik und Datenhaltung) aufgebaut sind, stellt sich die Frage nach der



Autorisierung nicht nur einmal, beim Zugriff auf die Präsentationsschicht, son-dern darüber hinaus auch beim Zugriff jeder Schicht auf die jeweils darunterliegende.

Eine weitere, darüber liegende Schicht können in einer SOA Verzeichnisse(Repositories) bilden, also Datenbanken, die Informationen über Dienste etwanach dem Standard UDDI bereitstellen.

Minimale Rechte

Grundsätzlich ist auf jeder Schicht das Prinzip Zugriff nur soweit erforderlich(englisch Least Privilege) einzuhalten: Es dürfen immer nur so viele Rechtevergeben werden, wie im aktuellen Kontext zur Durchführung der fachlichenAufgabe benötigt werden. Dies impliziert insbesondere, dass administrativeRechte nur von besonderen Benutzern und nur zum Zweck der Administrationausgeübt werden dürfen. Das Prinzip der minimalen Berechtigungen gilt auchfür den Zugriff auf Repositories, falls diese nicht komplett öffentlich sind.

Der Grundsatz der minimalen Berechtigungen gilt ebenso für die Systembe-rechtigungen, mit denen die Prozesse von Applikationsserver, Datenbank,XML-Firewall und anderen Komponenten laufen.

Öffentlich zugängliche Web-Services

Insbesondere wenn Web-Services großen, möglicherweise anonymen Benut-zerschichten angeboten werden (etwa als Dienst im Internet), ist mit zufälli-gen und systematischen Angriffen auf die Autorisierung auf allen Schichten zurechnen. Hier sind besondere architektonische Maßnahmen zu treffen.

Von außen erreichbare Schnittstellen sollten dabei in ein isoliertes Grenznetz(DMZ) verlagert und von internen Diensten und Datenbeständen getrennt wer-den. Ebenfalls in der DMZ angesiedelt werden kann ein ergänzender Securi-ty-Service, der alle Anfragen an den Web-Service zuerst überprüft. Dabei kanner auch die Authentisierung und Autorisierung der Anfragen übernehmen, et-wa mithilfe des Zugriffs auf einen Verzeichnisdienst im internen Netz. Die ei-gentlichen Daten befinden sich auf einem Anwendungsserver, ebenfalls iminternen Netz, zu welchem der Web-Service nur bestimmte Anfragen erlaubt.

Sicherheitsgateways

Da Web-Service-Kommunikation sich häufig zwischen verschiedenen Netzbe-reichen vollzieht, spielen klassische Firewallkonzepte zur sicheren Trennungder Netze eine große Rolle. Hier kommt allerdings die Tatsache hinzu, dassinnerhalb von SOAP-Nachrichten beliebige Daten, Befehle und Dateien (alsAnhänge) verschickt werden können, auf die eine Firewall, die lediglich aufAdress- und Portebene filtert, nicht gezielt reagieren kann.

Dem Zweck angemessene Web-Service-Firewalls müssen als Application Le-vel Gateways (ALG) ausgeführt sein. Sie werden in diesem Fall häufig auch alsXML-Firewall oder XML-Security-Gateway bezeichnet. Solche Systeme kön-nen XML filtern, parsen, auf Schadsoftware prüfen und SOAP-Nachrichten un-tersuchen, um beispielsweise bestimmte Aktionen oder Akteure zu blockieren.

Auch für die Autorisierung kann eine XML-Firewall genutzt werden. In diesemFall trifft sie die Entscheidung, ob ein authentisierter Benutzer berechtigt ist,eine bestimmte Aktion auszuführen, indem das in der Nachricht enthalteneSecurity Token untersucht, ausgewertet und kryptographisch überprüft wird.



Standards

Bestehende IT-Systeme verfügen häufig über proprietäre Zugriffsmechanis-men. Informationen über Entitäten und Attribute werden in der Regel in Zu-griffslisten (Access Control Lists, ACL) gespeichert, die sehr unterschiedlichaussehen können. Dadurch werden ein Austausch und eine gemeinsame Nut-zung über verschiedene Systeme hinweg unnötig erschwert. Im Bereich derWeb-Services, wo bereits Schnittstellen, Datenmodelle und Authentisierungs-methoden homogenisiert sind, sollten deshalb einschlägige Standards auchfür die Zugriffskontrolle umgesetzt werden.

Im Gegensatz zu anderen spezifischen Themen ist Autorisierung allerdingsbisher nicht in einen dedizierten Standard der WS-*-Familie gemündet: DerStandard WS-Authorization wurde bis Anfang 2014 nicht veröffentlicht. Statt-dessen gibt es verschiedene XML-Standards, die sich teilweise überschnei-den, teilweise ergänzen und jeweils das Thema Autorisierung mit einem be-stimmten Fokus in Angriff nehmen.

In SAML (Security Assertion Markup Language), einem standardisierten XML-Framework für die Beschreibung und Abfrage von Authentisierungs-, Autori-sierungs- und Attributinformationen einer Entität, zum Beispiel über SOAP,lassen sich in sogenannten Assertions (Zusicherungen) unter anderem Auto-risierungsentscheidungen kodieren und austauschen.

XACML (eXtensible Access Control Markup Language) auf der anderen Sei-te stellt eine Sprache dar, die XML-basiert beschreibt, wie Regeln und dazu-gehörige Anfragen und Antworten zu gestalten sind, um eine kontext- oderattributbasierte Autorisierung der Zugriffskontrolle auf Ressourcen zu ermög-lichen. Neben dem einfachen Gewähren oder Verwehren von Aktionen gibt eshier die Möglichkeit, vor oder nach der Autorisierungsentscheidung bestimm-te weitere Aktionen zu erzwingen. XACML hat seine Stärken vor allem in derfeingranularen Beschreibung und Übertragung von Zugriffsrechten.

XACML und SAML überschneiden sich zwar teilweise als Standards fürAuthentisierung und Autorisierung, ergänzen sich aber aufgrund des unter-schiedlichen Fokus auch und werden daher häufig in Kombination eingesetzt.Während SAML allgemein die Authentisierung sowie die Übertragung von Au-thentisierungs- und Autorisierungsentscheidungen zwischen Entitäten ermög-licht, deckt XACML vor allem die Autorisierungsentscheidungen selbst ab, al-so wie diese im PEP verarbeitet werden.

Gestaffelte Verteidigung

Insbesondere, wenn Daten oder Operationen höheren Schutzbedarf tragen,sollte die Autorisierung nicht nur an einer Stelle geprüft werden, sondern ei-ne gestaffelte Verteidigung (Defense in Depth) stattfinden. So kann ein Si-cherheits-Gateway bereits die Autorisierung einer Anfrage überprüfen und derDienst selbst vor der Ausführung noch einmal, um mögliche Fehlkonfiguratio-nen oder Software-Schwachstellen des Gateways abzufangen.

Schließlich sollte im Fehlerfall immer auf eine sichere Entscheidung zurückge-fallen werden (Fail Securely): Geht es um Vertraulichkeit oder Integrität, mussbei fehlgeschlagener Autorisierung der Zugriff verweigert werden. Nur im Fall,dass die Verfügbarkeitsanforderungen die übrigen Sicherheitsanforderungendeutlich überwiegen, darf im Fehlerfall eine Erlaubnis des Zugriffs erfolgen.Eine solche Entscheidung muss jedoch in jedem Fall in einer Risikoanalysedokumentiert werden.



Prüffragen:

- Wurde ein geeignetes Rollen-und-Rechte-Modell entwickelt?- Werden bei jedem einzelnen Zugriff auf jede Ressource immer wieder die

Zugriffsrechte überprüft?- Existiert bei einer SOA ein zentrales Tool für die Verwaltung von Rollen

und Rechten?- Wird das Prinzip der minimalen Berechtigungen konsequent

durchgehalten, insbesondere auch für administrative Zugriffe und dieDienstkonten der beteiligten Software?

- Kommt bei öffentlich erreichbaren Web-Services eine sichere Architekturzum Einsatz, zum Beispiel in Form einer DMZ mit Security-Service oderXML-Security-Gateway?

- Fällt bei fehlgeschlagener Autorisierung das System auf einen sicherenZustand entsprechend des Schutzbedarfs zurück?



M 4.456 Authentisierung bei Web-Services

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, LeiterIT, Verantwortliche der einzelnenAnwendungen


Um den Zugriff auf einen Web-Service auf einen berechtigten Personenkreiseinzugrenzen oder unterschiedliche Berechtigungen innerhalb eines Web-Service zu realisieren (vergleiche M 4.455 Autorisierung bei Web-Services) istes notwendig, die Benutzer, die auf den Dienst zugreifen, eindeutig zu identi-fizieren und zu authentisieren. Umgekehrt muss der Benutzer eines Web-Ser-vice sicherstellen können, dass er tatsächlich mit dem gewünschten Dienstkommuniziert.

Die Authentisierung muss dabei erfolgen, bevor schützenswerte Informatio-nen übertragen werden. Dies bedeutet, dass der Benutzer eines Web-Servicesicherstellen muss, dass er tatsächlich mit dem gewünschten Web-Servicekommuniziert, bevor er eine Anfrage mit vertraulichen Informationen an denDienst sendet. Umgekehrt muss ein Web-Service die Identität des anfragen-den Benutzers oder Web-Services prüfen, bevor er vertrauliche Informationenan diesen zurücksendet oder dem Benutzer Berechtigungen zum Aufruf vonFunktionen erteilt (siehe M 4.455 Autorisierung bei Web-Services).

Die Authentisierung von Kommunikationspartnern kann auf unterschiedlichenEbenen umgesetzt werden. Eine Möglichkeit ist etwa die Authentisierung aufTransportebene mittels SSL-/TLS. Dies wird häufig auch als Transport LayerAuthentication bezeichnet. Eine andere Möglichkeit ist die Authentisierung aufNachrichtenebene, zum Beispiel mittels der Mechanismen aus den WS-Se-curity-Standards. Sollen nicht nur einzelne Nachrichten, sondern ein komple-xerer Nachrichtenaustausch authentisiert werden, so empfiehlt es sich, einentsprechendes Session-Management einzuführen (vergleiche M 4.394 Ses-sion-Management bei Webanwendungen und Web-Services).

Identitätsmanagement

Um die Benutzer von Web-Services zu authentisieren, ist es notwendig, Be-nutzerdaten zu erfassen und die zugehörigen Identifikationsmerkmale zu hin-terlegen. Diese Vorgänge sind Teil des sogenannten Identitätsmanagements(engl. Identity Management).

Der klassische Anwendungsfall ist dabei, dass jeder Anbieter eines Web-Ser-vice seine eigene Benutzerverwaltung betreibt und die Authentisierung selbstvornimmt. Hierbei spricht man von isoliertem Identitätsmanagement. Bei die-sem Modell kommuniziert der Benutzer ausschließlich mit dem gewünschtenWeb-Service. Bei der Nutzung weiterer Web-Services muss seine Identitätdort jeweils eigenständig verwaltet werden.

Kommen Web-Services in service-orientierten Architekturen (SOA) zum Ein-satz, so handelt es sich zumeist um komplexe Systeme, die oft nicht mehrder Kontrolle einer einzelnen Institution unterliegen. Es ist dann meistens nichtmehr möglich, die Identitäten durch die Betreiber der einzelnen Dienste ver-walten zu lassen. Diese Aufgabe wird stattdessen von spezialisierten Organi-sationen oder Organisationseinheiten, den Identitätsanbietern (engl. IdentityProviders) übernommen.



Beim zentralisierten Identitätsmanagement existiert ein solcher Identitätsan-bieter, der das Identitätsmanagement für eine Vielzahl an Dienstanbieternübernimmt. Beispiele für diese Art von Identitätsmanagement sind Dienste vonAnbietern wie Microsoft, Facebook oder Google, oder aber der Einsatz eineszentralen Authentisierungssystems innerhalb eines Unternehmens. Zentrali-sierte Identitätsmanagementsysteme bieten oftmals Single-Sign-On-Funktio-nalität: Der Benutzer muss sich lediglich gegenüber einem Identitätsanbieterauthentisieren, um die Dienste verschiedener Dienstanbieter in Anspruch zunehmen.

Die dritte Variante des Identitätsmanagements ist das föderierte Identitätsma-nagement (engl. Federated Identity Management). In dieser Variante existie-ren mehrere Identitätsanbieter. Die Authentisierung der Benutzer erfolgt überstandardisierte Schnittstellen und Protokolle. Für Web-Services ist hier vor al-lem die Spezifikation WS-Federation von Bedeutung. Konkrete Technologien,die zur Umsetzung dieser Spezifikation verwendet werden können, sind dieSecurity Assertion Markup Language (SAML) und OpenID.

Art der eingesetzten Indikatoren

Die Authentisierung der Teilnehmer an einer Web-Service-Kommunikation er-folgt über den Nachweis von eindeutig einer Identität zuzuordnenden Merk-malen, sogenannten Identifikatoren. Übliche Identifikatoren sind dabei Benut-zernamen mit Passwörtern, Zertifikate und Signaturen, sowie kryptographischgesicherte Datensätze (Token) eines Identitätsanbieters oder eines Securi-ty-Token-Services, wie er im Rahmen von WS-Trust spezifiziert ist (vergleicheM 4.453 Einsatz eines Security Token Service (STS)). Verschiedene Authen-tisierungsverfahren sind im Folgenden dargestellt. Für den Web-Service musshier ein Verfahren ausgewählt werden, dessen Sicherheit dem Schutzbedarfgerecht wird.

Ein Beispiel für eine sehr einfache Authentisierung mit Hilfe von Benutzerna-men und Passwörtern ist der Einsatz von HTTP Basic Authentication. Dieselässt sich sowohl für Web-Services auf Basis von REST als auch für SOAP-basierte Web-Services verwenden, bietet allerdings nur ein geringes Maß anSchutz der Authentisierungsdaten und muss daher durch zusätzliche Sicher-heitsmaßnahmen wie etwa eine Transportverschlüsselung ergänzt werden.Ein weiteres Beispiel ist die Verwendung eines Username Tokens beim Ein-satz von WS-Security.

Besseren Schutz bieten verschiedene Möglichkeiten, um Web-Service-Nach-richten mittels Zertifikaten und Signaturen zu authentisieren. Zumeist kom-men XML-Signaturen gemäß der XMLDSIG-Spezifikation zum Einsatz. Ei-ner der Vorteile des Einsatzes von Signaturen zur Authentisierung ist, dassdie Authentisierung auf Nachrichtenebene stattfindet. Dadurch kann gegebe-nenfalls auf eine Sitzungsverwaltung (Session Management) verzichtet wer-den, da jede Nachricht einzeln durch eine Signatur authentisiert werden kann.Der Nachteil dieser Vorgehensweise sind Leistungseinbußen durch die Erzeu-gung, Übertragung und Verifikation einer Signatur für jede einzelne Nachricht.Darüber hinaus erfordert der Einsatz von Signaturen die Nutzung einer PublicKey Infrastruktur (PKI).

Bei XML-Signaturen muss sichergestellt werden, dass sich die Signatur tat-sächlich auf die vom Dienst zu verarbeitenden Daten bezieht. Ist dies nicht derFall, werden so genannte XML Signature Wrapping-Angriffe möglich (sieheG 5.183 Angriffe auf XML). Bei diesem Angriff werden gültige, signierte XML-Daten in ein von einem Angreifer manipuliertes XML-Dokument eingebettet.



Wenn nun die Funktionen zur Verifikation der Signatur und die eigentliche An-wendungslogik die XML-Daten auf unterschiedliche Art und Weise verarbei-ten, kann eine Situation entstehen, bei der die Signatur für die ursprünglicheneingebetteten Daten überprüft wird, auf Anwendungsebene aber die manipu-lierten Daten verarbeitet werden.

Eine weitere Möglichkeit zur Authentisierung der Teilnehmer einer Web-Ser-vice-Kommunikation ist die Authentisierung mittels Token, die von vertrauens-würdigen Dritten ausgestellt wurden. Als Token wird hierbei eine Datenstruk-tur bezeichnet, die die Identität des Tokeninhabers bestätigt. Die Integrität undAuthentizität des Tokens selbst muss wiederum durch kryptografische Maß-nahmen sichergestellt werden. Beispiele für häufig im Rahmen von Web-Ser-vice-Kommunikation eingesetzte Token sind SAML oder OAuth-Token.

Beim Zugriff von Benutzern auf Web-Services mit erhöhtem Schutzbedarfkann es erforderlich sein, eine starke Authentisierung unter Verwendung meh-rerer Authentisierungsmerkmale (zum Beispiel der Besitz einer Chipkarte unddie Kenntnis der dazugehörigen PIN) zu realisieren. Werden für eine solcheMehrfaktorauthentisierung voneinander unabhängige Authentisierungsmerk-male verwendet, so wird die Wahrscheinlichkeit, dass ein Angreifer alle erfor-derlichen Merkmale unter seine Kontrolle bekommt, stark verringert.

Werden kryptografische Algorithmen zur Authentisierung eingesetzt, bei-spielsweise für Hashing-Verfahren oder Signaturen, muss sichergestellt wer-den, dass diese dem Stand der Technik entsprechen. Hierzu sollten die ent-sprechenden Maßnahmen des Bausteins B 1.7 Kryptokonzept umgesetzt wer-den.

Gesicherte Übertragung von Authentisierungsdaten

Die Übertragung von Identifikatoren muss auf angemessene Art und Weisegeschützt werden, sodass ein Angreifer die Identifikatoren nicht nutzen kann,um sich als legitimier Benutzer oder Anbieter eines Web-Service auszuge-ben. Die notwendigen Schutzmechanismen hängen von der Art des genutz-ten Identifikators ab. Bei der Übertragung von Benutzernamen und Passwör-tern muss die Vertraulichkeit gewährleistet werden, beispielsweise durch ei-ne Transportverschlüsselung oder eine Verschlüsselung der einzelnen Web-Service-Nachrichten.

Darüber hinaus müssen die Authentisierungsdaten vor Wiedereinspielung(Replay-Angriffe) und Weiterleitung (Relay-Angriffe) geschützt werden. Dieserfolgt üblicherweise durch Zeitstempel in der Nachricht, beispielsweise überein wsu:Timestamp- Element beim Einsatz von WS-Security, oder durch dieVerwendung von Einmal-Zufallszahlen (Nonce), beispielsweise in Form eineswsse:Nonce- Elements. Bei der Verwendung von Noncen muss sichergestelltwerden, dass die Zufallszahlen keinesfalls mehrfach verwendet werden. EinSchutz vor Relay-Angriffen kann durch explizite, vor Manipulationen geschütz-te Angabe des Empfängers einer Nachricht realisiert werden.

Prüffragen:

- Erfolgt in der Kommunikation zwischen Web-Service und Web-Service-Nutzer eine gegenseitige Authentisierung, bevor der Gegenseitevertrauliche Informationen übermittelt oder Zugriffe auf Funktionengewährt werden?

- Werden ausreichend starke Verfahren zur Authentisierung eingesetzt?- Werden Passwörter ausschließlich verschlüsselt übertragen?



- Wird beim Einsatz von XML-Signaturen sichergestellt, dass sich dieSignatur tatsächlich auf die auf der Anwendungsebene verarbeitetenDaten bezieht, um XML Signature Wrapping-Angriffe zu verhindern?

- Sind für die Authentisierung genutzte kryptographische Verfahren imKryptokonzept der Institution berücksichtigt?

- Sind Schutzmaßnahmen gegen die Wiedereinspielung und Weiterleitungvon Identifikatoren umgesetzt?



M 4.457 Sichere Mandantentrennung beiWebanwendungen und Web-Services



Wird ein Web-Service von mehreren, voneinander unabhängigen Anwendern("Mandanten") gemeinsam genutzt, so müssen Maßnahmen umgesetzt wer-den, die verhindern, dass ein Anwender versehentlich oder missbräuchlichauf die Daten eines anderen Mandanten zugreift (siehe G 4.94 UnbefugterZugriff auf Daten eines anderen Mandanten bei Webanwendungen und Web-Services).

Zur Trennung der Datenbestände sind verschiedene Verfahren möglich, dieeinzeln oder kombiniert zum Einsatz kommen können:

Applikationsseitige Trennung

Der Programmcode der Anwendung entscheidet bei der Ausführung einer Pro-grammfunktion, welche Daten für welchen Benutzer zugänglich sind, indemzum Beispiel ausschließlich vom Benutzer selbst angelegte Datensätze an-gezeigt werden oder die Datensätze ein bestimmtes Mandantenkennzeichenenthalten, das von der Anwendung ausgewertet wird. Hier ist die Gefahr ei-nes ungewollten Zugriffs auf Daten anderer Mandanten besonders hoch, dabereits ein Implementierungsfehler im Code oder eine fehlende Prüfung beimDirektaufruf von Funktionen entsprechende Daten offenlegen kann.

Trennung in der Datenhaltung

Bei dieser Realisierungsvariante werden die Daten verschiedener Mandantenin den eingesetzten Datenspeichersystemen getrennt vorzuhalten (zum Bei-spiel in verschiedenen logischen Datenbanken, verschiedenen Tabellen oderunterschiedlichen Zweigen im Verzeichnisdienstschema). Durch die Nutzungentsprechender mandantenspezifischer Accounts für den Datenzugriff und einpassendes Berechtigungskonzept kann dabei sichergestellt werden, dass je-weils nur mandanteneigene Daten gelesen oder verändert werden können.In diesem Szenario sind Zuordnungsfehler nur noch dann möglich, wenn derFehler auch zu einer falschen Zuordnung des eingesetzten Datenbank-/Ver-zeichnisdienstaccounts führt.

Trennung der Umgebungen

Die Dienste verschiedener Mandanten werden auf verschiedenen virtuellenoder physischen Systemen angeboten. Beim Zugriff eines Anwenders wird si-chergestellt, dass nur Dienste auf den Systemen des eigenen Mandanten er-reichbar sind. Dies kann zum Beispiel durch ein entsprechendes Authentisie-rungsverfahren erreicht werden oder durch netzseitige Maßnahmen, die dieverschiedenen Systeme nur aus dem Netz des jeweiligen Mandanten herauserreichbar machen.

Mandantenspezifische Verschlüsselung

Zusätzlicher Schutz von unbefugten Zugriffen kann durch die verschlüssel-te Ablage von Daten realisiert werden. Die Verschlüsselung kann dabei gan-



ze Datenbankinhalte, alternativ aber auch nur einzelne sensible Datenfelderumfassen. Durch die Erzeugung, Nutzung und Vorhaltung der erforderlichenkryptographischen Schlüssel in den Systemen der Anwender wird ein ZugriffDritter auf die jeweils eigenen Daten ausgeschlossen. Dieses Verfahren ge-währleistet auch einen Schutz gegen die unbefugte Einsicht in Daten durchAdministratoren des Diensteanbieters, erfordert aber entsprechend geeigne-te Strategien für das Schlüsselmanagement, insbesondere beim Verlust oderWechsel von Schlüsseln. Weiterhin schränken Verschlüsselungsmaßnahmenauch die serverseitige Verarbeitung der Daten stark ein, so ist zum Beispielein Suchen oder Sortieren mit Mitteln des Datenbank-Managementsystemsnicht mehr möglich.

Um eine Mandantentrennung sicher und wirksam umzusetzen, müssen diefolgenden Punkte beachtet werden:

- Die Trennung der Datenbestände verschiedener Mandanten darf nicht nurrein applikationsseitig umgesetzt werden, sondern muss nach Möglichkeitdurch eine logisch getrennte Datenhaltung mit separaten Datenbank-Ac-counts für den Zugriff und entsprechend eingeschränkten Berechtigungenunterstützt werden.

- Bei erhöhtem Schutzbedarf sind ergänzend Möglichkeiten zur mandan-tenspezifischen Verschlüsselung zu prüfen und nach Bedarf umzusetzen.Dabei muss sichergestellt werden, dass der Zugriff auf die erforderlichenkryptografischen Schlüssel nur den jeweils Berechtigten möglich ist (cli-entseitige Kryptierung). Eine solche Lösung ist insbesondere erforderlich,wenn ein Zugriff auf Datenbestände durch Administratoren des Dienstean-bieters sicher ausgeschlossen werden muss.

- Die Zuordnung von Benutzern zu ihrem Mandanten muss manipulations-sicher realisiert werden (durch eine entsprechende, nach Mandanten ge-trennte Benutzerverwaltung oder geeignete Kriterien für die automatisierteZuordnung von Benutzern zu Mandanten, zum Beispiel auf der Grundlagevon Zertifikaten).

- Die Mandantentrennung muss durchgängig umgesetzt werden. Dies be-trifft externe Schnittstellen, aber auch Verfahren zur Datensicherung (Mög-lichkeit zur getrennten Rücksicherung der Mandantendaten). Auch dieProtokollierungsmechanismen müssen so gestaltet sein, dass eine man-dantenspezifische Auswertung oder Bereitstellung von Logdateien mög-lich ist.

- Das gewählte Konzept zur Mandantentrennung muss in der Dokumenta-tion nachvollziehbar beschrieben sein. Im Rahmen von regelmäßigen Au-dits und Penetrationstests muss die Wirksamkeit der Mandantentrennungim Prüfumfang berücksichtigt werden.

Prüffragen:

- Sieht das Konzept Maßnahmen vor, die über eine rein applikationsseitigrealisierte Mandantenzuordnung hinausgehen, um auszuschließen, dasseinfache Softwarefehler zu einem Zugriff auf Daten anderer Mandantenführen?

- Erfolgt die Zuordnung von Dienstnutzern zu Mandanten mit einemzuverlässigen und manipulationssicheren Verfahren?

- Berücksichtigt das Konzept zur Mandantentrennung alle relevantenAspekte (Dienstnutzung, Schnittstellen, Datensicherung, Protokollierung)?

- Ist das umgesetzte Konzept zur Trennung von Daten verschiedenerMandanten nachvollziehbar dokumentiert? Entspricht die Umsetzung derDokumentation?

- Wird die Wirksamkeit der Mandantentrennung regelmäßig im Rahmenvon Sicherheitsaudits oder Penetrationstests überprüft?



M 4.458 Planung des Einsatzes vonWeb-Services

Verantwortlich für Initiierung: Leiter ITVerantwortlich für Umsetzung: Administrator, Fachverantwortliche

Vor dem Einsatz eines Web-Service ist der genaue Zweck zu bestimmen,den der Web-Service erfüllen soll. Denn Web-Services stellen nur eine Art derKommunikation zwischen Maschinen dar und bringen spezifische Vor- undNachteile gegenüber anderen Formen der Integration von Anwendungen undDiensten mit sich. Nicht jede Anwendung eignet sich für eine Ausführung alsWeb-Service. Auch Kosten-Nutzen-Überlegungen spielen hier eine Rolle. Sowird der Datendurchsatz, gerade beim durchgängigen Einsatz von Web-Ser-vice-Sicherheitsstandards, regelmäßig deutlich schlechter sein als bei klassi-schen Massendaten-Übertragungsverfahren. Dem gegenüber stehen Vorteilein der Wiederverwendbarkeit von Diensten und Funktionen und in der Skalier-barkeit von Anwendungen durch Verteilung der Aufgaben auf unterschiedlicheDienste.

Am Anfang steht eine gründliche Analyse der Anforderungen, die auch do-kumentiert werden sollten. Hierbei empfiehlt es sich, mit einer Abbildung derbetroffenen Prozesse auf einer hohen Abstraktionsebene zu beginnen, dar-aufhin die Arbeitsabläufe im Ist und Soll zu skizzieren und darauf aufbauendeinen Entwurf mit Eingaben, Ausgaben, Schnittstellen und Daten zu detaillie-ren. Ebenso zu identifizieren sind Anbieter, Konsumenten, Kommunikations-verbindungen und erforderliche Service-Verzeichnisse. Zu letzteren ist zu ent-scheiden, ob und welche Web-Services darin veröffentlicht werden sollen.

Eine grundlegende Entscheidung ist die für einen REST- oder einen SOAP-basierten Web-Service. Während SOAP bei internen betrieblichen Anwendun-gen wesentlich weiter verbreitet ist und auf eine Vielzahl von Werkzeugenund Standards aufbaut, ist REST hauptsächlich im agilen Web-Umfeld an-zutreffen. Letztlich wird die Entscheidung im Wesentlichen von den anderenDiensten und Anwendungen abhängen, die bereits vorhanden sind, noch ent-stehen oder angebunden werden sollen. In jedem Fall sind die Folgen dergrundlegenden Architekturentscheidung am Anfang zu berücksichtigen unddurchzuspielen.

Dies ist insbesondere dann relevant, wenn eine serviceorientierte Architektur(SOA) entstehen oder ein Dienst in eine bestehende SOA integriert werdensoll. Hierbei sind Fragen des SOA-Betriebsmodells zu klären: Wer ist inner-halb der Institution für die fachliche Funktionalität und für die verarbeiteten In-formationen verantwortlich? Rollen und Verantwortlichkeiten sind spätestensjetzt festzulegen und zu dokumentieren.

Ob eine Architektur in Richtung Serviceorientierung umgeformt werden soll, isteine strategische Entscheidung, die mit der Strategie zur Nutzung von Web-Services und der Plattformstrategie Hand in Hand gehen sollte. Sollen vieleWeb-Services auf unterschiedliche, möglicherweise wechselnde Art und Wei-se miteinander interagieren können - man spricht von Orchestrierung -, sokönnen Modellierungs- und Beschreibungssprachen wie BPMN oder BPELeingesetzt werden, um die Interaktion der Geschäftsprozesse zu steuern. Diesergibt jedoch frühestens dann Sinn, wenn eine ausreichend große Zahl vonWeb-Services vorhanden ist, welche auf verschiedene Art verknüpft werdensollen, um neue Dienste zu kreieren.



Besonders gut geeignet für die Ausführung als Web-Service sind Dienste, dievon mehreren Anwendungen oder anderen Diensten benötigt werden. Hiersollte auch berücksichtigt werden, dass die Dienste nicht nur intern genutztwerden könnten. Werden diese weiteren Institutionen zur Verfügung gestelltwerden, ist unbedingt zu klären, wer über die Bereitstellung von Diensten undDaten an Dritte entscheidet. Außerdem sind die Absicherung der Netzüber-gänge und Kommunikationsschnittstellen zu betrachten, damit die Web-Ser-vices im erforderlichen Maß von außen angesprochen werden können, ohnedie Sicherheit interner Netze unnötig zu gefährden. Dabei werden häufig Un-ternehmensdaten über Netzsegmente hinweg und auf freigeschalteten Portswie 80 (HTTP) oder 443 (HTTPS) durch Firewalls hindurch transportiert. AuchSchadsoftware kann auf diesem Weg in die Institution hinein gelangen, etwaals eingebettete Datei. Hier sind Schutzkonzepte und technische Sicherheits-maßnahmen wie Application Level Gateways (ALG) zu überprüfen und gege-benenfalls anzupassen.

Um den Web-Service gegen Angriffe abzusichern, müssen auch bei der Im-plementierung geeignete Sicherheitsmaßnahmen vorgesehen werden, zumBeispiel eine durchgängige Validierung von Ein- und Ausgabedaten und Kon-formitätsprüfungen der verarbeiteten XML-Daten. Auch hierzu sollten entspre-chende Vorgaben in der Planungsphase erarbeitet und dokumentiert werden.

Um über die Einführung von Web-Services, die damit verbundenen Risikenund die notwendige Absicherung informiert entscheiden zu können, ist eswichtig, die komplette Funktionalität des Web-Service zu dokumentieren unddiese Dokumentation aktuell zu halten. Dies geschieht am besten für alle Web-Services an einer zentralen Stelle. Bei Nutzung des Web-Service durch meh-rere Parteien sollten alle Seiten Zugriff auf diese Informationen haben.

Auch auf den Lebenszyklus eines Web-Service hat die Mehrfachnutzung Ein-fluss: Es muss geklärt und beschrieben werden, wie Änderungen eines Web-Service, der von mehreren Anwendungen oder Organisationen genutzt wird,durchgeführt werden können. Entsprechendes gilt für die Abschaltung am En-de des Lebenszyklus.

Für die Realisierung der Web-Service-Funktionalität empfiehlt es sich, be-währte und gut getestete Komponenten heranzuziehen, da die Materie kom-plex ist und Programmierfehler bei Eigenentwicklungen häufig vorkommen.Sowohl beim Applikationsserver wie bei Web-Service-Bibliotheken oder -Fra-meworks sollten Produkte ausgewählt werden, die aktiv weiter gepflegt wer-den, und bei denen Informationen über Schwachstellen und Patches zeitnahbereitstehen.

Kommen komplexere Standards wie etwa WS-Security, WS-Trust oder WS-Federation zum Einsatz, ist die gegenseitige Abhängigkeit und Beeinflussungder verschiedenen Sicherheitsfunktionen genau zu planen und zu testen. Fürdie Aufrechterhaltung der Sicherheit in einer kompletten SOA ist schließlichein Zusammenspiel von Standards, Konzepten und Mechanismen notwendig,das über die Absicherung einer reinen Client-Server-Beziehung hinausgeht.Hier ist besonderes Fachwissen gefragt.

Neben anderen Sicherheitszielen, die je nach Einsatzzweck eine Rolle spielenkönnen, ist fast immer die Absicherung der Kommunikation zwischen Dienst-nutzer und Dienstanbieter entscheidend. Dies kann entweder auf Transpor-tebene erfolgen, wenn der Transportweg der Nachrichten dies erlaubt (etwadurch SSL-/TLS bei HTTP), oder aber auf Nachrichtenebene. Letzteres er-laubt neben der Ende-zu-Ende-Absicherung auch, die Sicherheitsparameter



in einer feineren Granularität auszuwählen und auszuwerten, zum Beispiel dieSignatur oder Verschlüsselung lediglich für bestimmte Teile einer Nachricht.Dabei ist tiefliegendes Wissen über die verwendeten Mechanismen notwen-dig, um nicht durch Schwachstellen in Protokollen oder in der Implementierungangreifbar zu werden, beispielsweise durch XML Signature Wrapping (sie-he G 5.183 Angriffe auf XML). Außerdem erschwert eine Ende-zu-Ende-Ver-schlüsselung die Filterung bösartiger Nachrichten. Hier kann es helfen, dieVerschlüsselung am Application-Level-Gateway zu terminieren.

Um die Vorteile von Web-Services, insbesondere ihre Wiederverwendbarkeitund Skalierbarkeit, voll ausnutzen zu können, ist es entscheidend, das Identi-täts- und Zugriffsmanagement nicht in jedem Dienst einzeln neu zu realisieren.Die Planung der Web-Service-Landschaft umfasst deshalb auch die Planungder übergreifenden Verwaltung der Benutzer und Rechte. Näheres hierzu fin-det sich in den Maßnahmen M 4.456 Authentisierung bei Web-Services undM 4.455 Autorisierung bei Web-Services.

Die vorgenannten, für die Planung eines Web-Service erforderlichen Aspek-te gelten in ähnlicher Form auch für klassische IT-Anwendungen. Durch diemögliche Mehrfach-Nutzung und Orchestrierung zu übergreifenden Aufgabenund durch die technische Komplexität der Standards und Protokolle ist derEinfluss von Planungsmängeln auf den Projekterfolg jedoch gegenüber ande-ren Technologien erhöht.

Prüffragen:

- Ist der Einsatzzweck des Web-Service beschrieben und sind dieAnforderungen der Consumer analysiert und dokumentiert?

- Ist dokumentiert, wer für die fachliche Funktionalität und die verarbeitetenInformationen verantwortlich ist?

- Wurden Konzepte und Maßnahmen zur Absicherung der Netzübergängeim Hinblick auf den Einsatz von Web-Services angepasst?

- Besteht ein Schutz vor Schadsoftware in Web-Service-Nachrichten, undsind Sicherheitsmaßnahmen wie eine Eingabe- und Ausgabevalidierungfür die Software-Implementierung vorgegeben?

- Wurden bewährte, gut getestete Komponenten, Bibliotheken undFrameworks für die Realisierung des Web-Service ausgewählt?

- Ist die Kommunikation zwischen Consumer und Dienstanbieter entwederauf Transport- oder auf Nachrichtenebene auf eine dem Schutzbedarfangemessene Weise abgesichert?

Maßnahmenkatalog Kommunikation M 5.150 Bemerkungen


M 5.150 Durchführung vonPenetrationstests

Verantwortlich für Initiierung: Behörden-/Unternehmensleitung, IT-Sicherheitsbeauftragter, Leiter IT


Penetrationstests sind ein erprobtes und geeignetes Vorgehen, um die aktu-elle Sicherheit eines IT-Netzes, eines einzelnen IT-Systems, einer (Web-) An-wendung oder eines Web-Service festzustellen. Sie dienen dazu, die Erfolgs-aussichten eines vorsätzlichen Angriffs auf einen Informationsverbund oderein einzelnes IT-System vorab einzuschätzen und daraus notwendige ergän-zende Sicherheitsmaßnahmen abzuleiten beziehungsweise die Wirksamkeitvon bereits umgesetzten Sicherheitsmaßnahmen zu überprüfen. Für sicher-heitskritische Netze und Systeme sollten regelmäßig Penetrationstests erfol-gen.

Im Detail werden dabei die installierten Anwendungen (Webanwendung, Mail-server, Web-Service etc.) beziehungsweise die zugrunde liegenden Träger-systeme (Betriebssystem, Datenbank etc.) überprüft.

Typische Ansatzpunkte für einen Penetrationstest sind:

- Netzkoppelelemente (Router, Switches, Gateways),- Sicherheitsgateway (Paketfilter, Intrusion Detection System, Virenscan-

ner, etc.),- Server (Datenbankserver, Webserver, Fileserver, Speichersysteme etc.),- Telekommunikationsanlagen,- Webanwendungen (zum Beispiel Internetauftritt, Vorgangsbearbeitung,

Webshop),- Web-Services (zum Beispiel REST-Interface, SOAP-API, SOA),- Clients,- Drahtlose Netze (WLAN, Bluetooth) und- Infrastruktureinrichtungen (Zutrittskontrollmechanismen).

Üblicherweise werden Penetrationstests in Blackbox-Tests und White-box-Tests unterteilt. Bei einem Blackbox-Test stehen dabei den Penetrations-testern lediglich die Adressinformationen des Zieles zur Verfügung, weitere In-formationen werden ihnen nicht mitgeteilt. Mittels der Vorgehensweise "Black-box-Test" soll damit der Angriff eines typischen Außentäters mit unvollstän-digen Kenntnissen über das Zielsystem simuliert werden. Dagegen verfügendie Penetrationstester bei einem Whitebox-Test über umfangreiche, für sienotwendige Informationen über die zu testenden Systeme. Dazu gehören bei-spielsweise Informationen über IP-Adressen, das interne Netz, die eingesetz-te Soft- und Hardware etc. Diese Angaben werden ihnen zuvor vom Auftrag-geber mitgeteilt.

Es ist jedoch fraglich, ob die Unterscheidung zwischen den Vorgehensweisen"Blackbox-Test" und "Whitebox-Test" heute noch sinnvoll ist. Beispielsweisebesteht bei einem Blackbox-Test aufgrund nicht vorliegender Informationenein höheres, durchaus vermeidbares Risiko, einen unbeabsichtigten Schadenzu verursachen. Weiterhin könnten beispielsweise Schwachstellen aufgrundnicht mitgeteilter Informationen übersehen werden.

Zudem besteht die Gefahr, dass im Rahmen eines Blackbox-Tests der Angriffeines informierten Innentäters nicht berücksichtigt wird.



Den Penetrationstestern sollten daher heutzutage alle für die Testdurchfüh-rung notwendigen Informationen über die zu testenden Systeme zur Verfü-gung gestellt werden, um eventuell mit dem Test verbundene Risiken mini-mieren zu können und eine möglichst vollständige Schwachstellensuche zuermöglichen.

Die Klassifizierung von Penetrationstests in eine weitestgehend automatisierteSchwachstellensuche ("Vulnerability Scan") sowie eine in großen Teilen ma-nuelle Sicherheitsrevision erscheint daher nach heutigem Kenntnisstand pra-xisnäher und erfolgsorientierter.

Personelle und fachliche Anforderungen an einen Dienstleister fürPenetrationstests

Penetrationstests sind anspruchsvolle und diffizile Aufgaben, die auch Auswir-kungen auf den IT-Betrieb haben können. Daher sollte hierfür nur hinreichendqualifiziertes und zuverlässiges Personal mit themenübergreifenden Kenntnis-sen auf folgenden Gebieten eingesetzt werden:

- Administration von Betriebssystemen und Anwendungen- Netzwerkprotokolle und Auswertung von Netzwerkverkehr- Sicherheitsprodukte (zum Beispiel Sicherheitsgateways, Intrusion Detec-

tion Systeme etc.)- Programmiersprachen- Schwachstellenscanner- Audit- und Administrationssoftware

Werden externe Dienstleister mit der Durchführung von Penetrationstests be-auftragt, so sollte darauf geachtet werden, dass ein qualifizierter und vertrau-enswürdiger Dienstleister ausgewählt wird (siehe auch M 2.252 Wahl einesgeeigneten Outsourcing-Dienstleisters), der entsprechend qualifizierte und zu-verlässige Mitarbeiter bereitstellen kann.

Weiterhin sollten Anbieter von Penetrationstests dem Auftraggeber eine struk-turierte Methodik zur Durchführung des Penetrationstests vorstellen können,auf deren Basis die jeweilige individuelle Vorgehensweise ausgearbeitet wer-den kann.

Strukturierung und Vorgehensweise für einen Penetrationstest

In einer Vorbereitungsphase müssen zunächst zwischen dem Auftraggeberund dem Auftragnehmer die Ziele sowie der Umfang des Penetrationstestsso genau wie möglich festgelegt werden. Der Penetrationstester sollte hierbeidem Auftraggeber eine strukturierte Vorgehensweise, welche zwischen denParteien abzustimmen ist, vorstellen.

Während des Abstimmungsprozesses sollte beachtet werden, dass unter Um-ständen Dritte über den geplanten Penetrationstest informiert beziehungswei-se daran beteiligt werden müssen.

In der Regel müssen beispielsweise die Personalvertretung und der Daten-schutzbeauftragte, häufig auch Externe, wie der Internet Service Provider oderder Webhoster, in das Vorhaben einbezogen werden.

Zwischen dem Auftraggeber und dem Dienstleister sollten bestimmte Voraus-setzungen bereits im Vorfeld vereinbart werden. Hierzu zählen insbesondere:

- Vereinbarungen über die Verschwiegenheitspflichten- Vereinbarungen über den Einsatz von Hard- und Software- Vereinbarungen über die zu testenden IT-Systeme und IT-Anwendungen



- Festlegung von erlaubten und unerlaubten Aktivitäten der Penetrationste-ster, um Schäden möglichst zu vermeiden

- Vereinbarungen über den Umgang mit Datenträgern vor, während undnach Abschluss des Penetrationstests, da die Datenträger zum Beispielsensible Informationen über die Testergebnisse enthalten können

- Festlegungen über den Ort der Durchführung sowie zur Auswertung undBerichterstellung für den Penetrationstest

- Festlegung eines Terminplans einschließlich Wartungsfenster für dieDurchführung der Tests

- Detaillierte Vereinbarungen über den Zugang zum Internet beziehungs-weise den Anschluss von Testsystemen an das Internet während derDurchführung und der Auswertung von Penetrationstests

- Vereinbarungen über Zuständigkeiten und die Erreichbarkeit von An-sprechpartnern sowie zur Notfallvorsorge

In der sich anschließenden Informationsphase sammeln die Penetrationste-ster möglichst viele Informationen über das zu testende Objekt. Zur Vorberei-tung der Tests werden die gewonnenen Informationen anschließend hinsicht-lich potenzieller Schwachstellen ausgewertet.

In der eigentlichen Testphase eines Penetrationstests sollten nach Möglichkeitdie Testverfahren vermieden werden, welche ein destruktives Ergebnis für dieuntersuchten IT-Systeme oder IT-Anwendungen zur Folge haben könnten.

So zielen beispielsweise DoS-Angriffe (Denial of Service) darauf ab, den Zu-griff auf einzelne Dienste, Systeme oder Netzsegmente zu unterbinden. DieFeststellung, ob derartige Attacken möglich sind, kann jedoch oftmals im Vor-feld durch eine Systemanalyse geklärt werden, sodass solche Angriffe wäh-rend eines Penetrationstests überflüssig werden.

Sollen dennoch DoS-Angriffe oder ähnliche destruktive Angriffe im Rahmeneines Penetrationstests durchgeführt werden, sollte dies außerhalb der pro-duktiven Nutzungszeiten des Systems erfolgen. Gegebenenfalls kann ein der-artiger Angriff auch anhand eines Testsystems simuliert werden. Diese Vor-gehensweisen sollten ausdrücklich vereinbart werden.

Erst danach werden aktive Eindringungsversuche unternommen. Dabei müs-sen die vereinbarten Wartungsfenster und der Terminplan strikt eingehaltenwerden. Wenn Änderungen am zeitlichen Ablauf erforderlich sind, muss diesauf jeden Fall mit dem Auftraggeber abgestimmt werden.

Anderenfalls besteht die erhöhte Gefahr, dass auf der Seite des Auftraggebersbestimmte Aktivitäten der Penetrationstester mit echten Angriffen verwechseltwerden. Empfehlenswert ist die vollständige Aufzeichnung und Dokumentati-on des Penetrationstests.

Um möglichst aussagekräftige Ergebnisse zu erhalten, sollte darauf geach-tet werden, dass die Penetrationstests unmittelbar an dem zu testenden IT-System sowie unter Umgehung der vorgeschalteten aktiven Netzkoppelele-mente wie zum Beispiel Paketfilter durchgeführt werden. Liegen besondereGründe vor, den Test mit aktiven vorgeschalteten Sicherheitskomponentendurchzuführen, so ist zu beachten, dass dabei eventuell Sicherheitsproble-me in der Anwendung selbst unentdeckt bleiben, weil die vorgelagerten Kom-ponenten die Angriffsversuche im Penetrationstest abfangen. Solche unent-deckten Schwachstellen bilden jedoch ein relevantes Risiko, denn häufig kön-nen mit einem abgewandelten Angriff die Schutzsysteme ausgehebelt und dieSchwachstellen ausgenutzt werden.



Typische Angriffstechniken

Netzwerk- und Portscanning: Netzwerk- und Portscanning werden genutzt, umdie in einem Netz aktiven IT-Systeme aufzufinden und die dort angebotenenDienste (Ports) zu identifizieren.

Seitens der IT-Administration werden solche Abfragen dazu genutzt, den aktu-ellen Status der eingesetzten IT-Systeme abzufragen. Allerdings kann ein An-greifer unter Umständen mit Hilfe dieser Informationen vorhandene Schwach-stellen auf den einzelnen IT-Systemen identifizieren und basierend auf diesenInformationen einen Angriff durchführen.

Ausnutzung mangelhafter Eingabeüberprüfung: Als Eingabeüberprüfung wirddas Verfahren bezeichnet, mit dem die Benutzereingaben (Daten), die einerAnwendung zur weiteren Bearbeitung übergeben werden, vorher gefiltert, be-reinigt oder zurückgewiesen werden.

Diese Filterung soll verhindern, dass der Anwendung schädlicher Code über-geben werden kann, dessen Verarbeitung zu einem Fehlverhalten führt wiezum Beispiel der Offenlegung vertraulicher Informationen.

Angriffsmethoden, mit denen ein derartiges Fehlverhalten hervorgerufen wer-den kann, sind zum Beispiel "Cross-Site Scripting (XSS)", "Cross-Site RequestForgery (XSRF)", "SQL Injection", "LDAP Injection", "OS Injection", "Fuzzing"sowie im Bereich von Web-Services "XMLExternal Entity-Angriffe (XEE)" odersogenannte "XML-Bomben".

Teilweise lassen sich auch Schwachstellen der verwendeten Protokolle undsonstigen Techniken ausnutzen, um Schaden zu bewirken, zum Beispiel mit-tels Angriffen auf veraltete SSL/TLS-Versionen oder etwa durch "XML Signa-ture Wrapping (XSW)" bei Web-Services.

Denial-of-Service-Angriffe (DoS): Diese Angriffe zielen darauf ab, einen odermehrere der zur Verfügung gestellten Dienste außer Betrieb zu setzen. Dieskann unter anderem mittels einer durch vermehrte Anfragen gesteigerten Last,durch ein massiv erhöhtes Datenaufkommen (zum Beispiel E-Mails), aberauch durch gezieltes Ausnutzen möglicher Softwarefehler durchgeführt wer-den. Ein bekanntes Beispiel für einen DoS-Angriff ist der "Ping of Death".

Information Gathering: Als "Information Gathering" wird die Sammlung allerInformationen bezeichnet, welche im weiteren für einen Angriff nützlich seinkönnten. Beispiele für solche Informationen sind etwa das verwendete Num-merierungsschema für Verzeichnisse oder Server oder Erkenntnisse überWeb-Service-Schnittstellen, die durch WSDL-Scanning gewonnen werden.

Social Engineering: Als "Social Engineering" werden beispielsweise fingierteAnrufe oder sonstige Kontaktaufnahmen mit Personen bezeichnet, die dasbetrachtete IT-System bedienen. Das Ziel ist meist, dadurch vertrauliche In-formationen wie zum Beispiel Passwörter zu erhalten (siehe auch G 5.42 So-cial Engineering).

War Dialing: Hierunter wird der automatisierte und systematische Versuch ver-standen, Telefonnummern, die in Verbindung mit einem Modem stehen, aus-zuforschen. Dabei werden die Telefonnummern des Zielsystems angerufenund auf ein antwortendes Modem hin abgeprüft.



Passwort-Attacken: Hierbei wird die Sicherheit beziehungsweise Stärke vonPasswörtern mittels sogenannter Wörterbuchangriffe, Brute-Force-Attackenoder durch Entschlüsselungsversuche getestet.

Ausnutzen von Software-Schwachstellen: Bei diesen Angriffen wird beispiels-weise getestet, ob die installierte Software anfällig für bestimmte Exploits ist,fehlerhaft konfiguriert ist, Schwachstellen aufweist oder veraltet ist. Häufig wirdauch untersucht, ob etwa bekannte Schwachstellen der Standardinstallationdes jeweiligen Produkts im vorliegenden Fall ausgenutzt werden können.

Kryptographische Angriffe: Hierbei werden beispielsweise die Stärke und dieImplementierung der eingesetzten Verschlüsselungsmechanismen und -pro-tokolle sowie der Schlüsselverwaltung untersucht.

Infrastruktur-Untersuchungen: Im Rahmen von Infrastruktur-Untersuchun-gen werden unter anderem bauliche Sicherungsmaßnahmen, Zutritts- undSchließeinrichtungen, aber auch die Entsorgung von Material durchleuchtet.Eine Variante hiervon ist das sogenannte "Dumpster Diving", also das Suchennützlicher Unterlagen oder Datenträger im Abfall (zum Beispiel Papierkörbe,Abfallcontainer).

In der Auswertungs- und Berichtsphase werden die Ergebnisse gesammelt,ausgewertet und in Form eines Berichts zusammengestellt. Alle während desPenetrationstests gewonnenen Informationen sind hierbei entsprechend gesi-chert aufzubewahren. Der Auftraggeber sollte den Auftragnehmer im Vorfelddazu verpflichten, alle Aufzeichnungen über den Penetrationstest vollumfäng-lich an den Auftraggeber zu übergeben beziehungsweise zu vernichten.

Der Bericht sollte neben einer Auflistung der gefundenen Schwachstellen auchMaßnahmenempfehlungen enthalten, wie mit den entdeckten Schwachstellenumgegangen werden sollte. Empfehlenswert ist hierbei zudem die Erstellungeines Umsetzungsplans für die in dem Bericht aufgeführten Maßnahmenemp-fehlungen einschließlich einer Priorisierung. Für das Management sollte derAbschlussbericht außerdem eine Zusammenfassung enthalten, in der die we-sentlichen Prüfungsergebnisse und ein Überblick über die empfohlene weitereVorgehensweise dargestellt sind. Der Abschlussbericht muss dem IT-Sicher-heitsbeauftragten und den verantwortlichen Führungskräften vorgelegt wer-den.

Begleitend zu allen Phasen eines Penetrationstests ist eine gemeinsame Do-kumentation der einzelnen Vereinbarungen und Ergebnisse durch den Auf-traggeber und den Auftragnehmer empfehlenswert.

Prüffragen:

- Wird für Penetrationstests ausschließlich zuverlässiges und qualifiziertesPersonal eingesetzt?

- Ist sichergestellt, dass ausschließlich vertrauenswürdige und qualifizierteDienstleister mit Penetrationstests beauftragt werden?

- Ist sichergestellt, dass die Ergebnisse von Penetrationstests ausreichendgeschützt und vertraulich behandelt werden?

- Werden die Abschlussberichte über Penetrationstests dem IT-Sicherheitsbeauftragten und den verantwortlichen Führungskräftenvorgelegt?

- Wurden mit allen Auftragnehmern für Penetrationstests vorab detaillierteVereinbarungen zur Durchführung und Auswertung von Penetrationstestsabgeschlossen?



- Wurde im Vorfeld der Penetrationstests das Einverständnis allerzuständigen Stellen eingeholt?

- Wurden die Ansprechpartner und deren Erreichbarkeit für den Zeitraumder Durchführung von Penetrationstests verbindlich festgelegt?



M 5.168 Sichere Anbindung vonHintergrundsystemen anWebanwendungen und Web-Services



Webanwendungen und Web-Services verwenden häufig Hintergrundsysteme,zum Beispiel für die Datenhaltung in einer Datenbank oder für die Authenti-sierung durch einen Identitätsspeicher. Die Daten sind auch bei der Übermitt-lung und Speicherung in Hintergrundsystemen ausreichend zu schützen. Da-zu müssen die Hintergrundsysteme sicher an die Webanwendung oder denWeb-Service angebunden sein.

Typische Hintergrundsysteme von Webanwendungen und Web-Services sind:

- Datenbanken,- Verzeichnisdienste,- Middleware,- Web-Services und- Legacy-Systeme.

Zur sicheren Anbindung von Hintergrundsystemen sollten folgende Punkte be-achtet werden:

Platzierung von und Zugriff auf die Hintergrundsysteme

Die Benutzer der Webanwendung beziehungsweise Aufrufer des Web-Ser-vice sollten nicht direkt auf die Hintergrundsysteme zugreifen können, da sogegebenenfalls Schutzmaßnahmen umgangen werden. Stattdessen sollte derZugriff ausschließlich über vordefinierte Schnittstellen und Funktionen der We-banwendung oder des Web-Service möglich sein.

Darüber hinaus sollte bei hohem Schutzbedarf die Verbindung zu den Hin-tergrundsystemen zusätzlich geschützt werden. Hierzu sollten sich die Syste-me vor der Datenübertragung authentisieren und die übertragenen Daten ver-schlüsseln, sodass sie nicht unbemerkt mitgelesen oder geändert werden kön-nen (zum Beispiel mittels SSL/TLS; siehe auch M 5.66 Clientseitige Verwen-dung von SSL/TLS und M 5.177 Serverseitige Verwendung von SSL/TLS).

Werden die beteiligten IT-Systeme über unsichere Kanäle angebunden, sosollte in jedem Fall ein kryptographisch abgesicherter Tunnel mit entsprechen-der Verschlüsselung und Authentisierung verwendet werden.

Zugriffe auf Hintergrundsysteme sollten mit minimalen Rechten erfolgen. Hier-für sollten Dienstekonten auf dem jeweiligen Hintergrundsystem eingerichtetwerden.

Wird für den Zugriff auf ein Hintergrundsystem ein einziges Dienstekonto ver-wendet, werden alle Anfragen im Sicherheitskontext dieses Dienstekontos be-arbeitet. Dies gilt dann sowohl für Zugriffe von Benutzern mit eingeschränktenZugriffsberechtigungen als auch für die Zugriffe administrativer Benutzer. Umdies zu verhindern, sollten mehrere Dienstekonten mit unterschiedlichen Zu-griffsrechten für ein Hintergrundsystem verwendet werden.



Bei einer geeigneten Systemumgebung (zum Beispiel bei der Verwendung ei-nes Verzeichnisdienstes, der sowohl von der Webanwendung als auch für dasHintergrundsystem zur Verwaltung der Benutzer verwendet wird) können dieBenutzerkonten an das Hintergrundsystem weitergeleitet werden. Auf dieseWeise können die Privilegien auf die notwendigen Rechte des jeweils an derWebanwendung angemeldeten Benutzers limitiert werden.

Es ist darauf zu achten, dass für unauthentisierte Zugriffe auf die Webanwen-dung ein eigenes Dienstekonto im Verzeichnisdienst mit eingeschränkten Be-rechtigungen verwendet wird.

Enterprise Service Bus

Im Kontext sogenannter Service-Orientierter Architekturen (SOA) werden We-banwendungen und Web-Services häufig über einen Enterprise Service Bus(ESB) als zentrale Kommunikationsinfrastruktur an Hintergrundsysteme an-gebunden. Dadurch wird erreicht, dass für jede Anwendung jeweils nur dieSchnittstelle zum ESB definiert und realisiert werden muss, und nicht vieleseparate Schnittstellen zu anderen Anwendungen und Diensten. In einem ei-genen Verzeichnis ("Repository") speichert der ESB Metainformationen überdie angeschlossenen Dienste.

Zusätzlich kann der ESB auch zentrale Sicherheitsfunktionen realisieren, umdie angeschlossenen Anwendungen weiter zu schützen. Solche Sicherheits-funktionen können beispielsweise Replay-Attacken erkennen und abwehrenoder XML-Daten auf potenziell schädliche Inhalte prüfen, aber auch den Nach-richtenaustausch zentral und revisionssicher protokollieren.

Beim Einsatz eines ESB muss sichergestellt werden, dass sich alle Dienstegegenüber dem ESB authentisieren, bevor ihnen ein Zugriff erlaubt wird. Diesgilt auch für Zugriffe auf das ESB-Repository. Der ESB muss so in die Netz-architektur integriert werden, dass ein Zugriff nur von den Servern der ange-schlossenen Anwendungen und Dienste möglich ist und ein Zugriff von außenauf den ESB ausgeschlossen wird. Dazu sollte der ESB ein eigenes logischesNetzsegment erhalten.

Der ESB muss eine eigene Berechtigungsprüfung durchführen, um zu prü-fen, ob ein Zugriff auf den angefragten Dienst durch den anfragenden Dienstbeziehungsweise die anfragende Anwendung zulässig ist. Dabei muss insbe-sondere sicher ausgeschlossen werden, dass Anwendungen oder Dienste mitAußenkontakt auf interne Dienste zugreifen, die dafür nicht vorgesehen sind.Solche Anwendungen dürfen auch nicht über das ESB-Repository Kenntnisvon internen Diensten und ihren Schnittstellen erlangen.

Sofern die service-orientierte Architektur mehrere Sicherheitsdomänen um-spannt, zum Beispiel eine DMZ mit extern aufrufbaren Services und ein inter-nes Netz mit Backend-Systemen, so muss auch der ESB in entsprechendeSicherheitsdomänen mit kontrollierten Übergängen aufgeteilt werden, oder esmüssen mehrere ESB für die einzelnen Sicherheitszonen realisiert werden.

Sofern der ESB nicht ausschließlich lokal in einem geschützten RZ-Netz kom-muniziert, muss die Kommunikation zwischen ESB und den angeschlossenenAnwendungen geeignet gesichert werden (Authentisierung und Verschlüsse-lung).

Durch die Bündelung der Kommunikation vieler Anwendungen und Dienstekommt der Verfügbarkeit des ESB eine besondere Bedeutung zu. Dies ist bei



der Realisierung und beim Betrieb des ESB entsprechend durch Redundan-zen und eine geeignete Überwachung des Dienstes zu berücksichtigen.

Prüffragen:

- Ist der Zugriff auf Hintergrundsysteme von Webanwendungen oder Web-Services ausschließlich über definierte Schnittstellen und von definiertenSystemen aus möglich?

- Wird der Datenverkehr zwischen den Benutzern und der Webanwendungbeziehungsweise den Anwendungen, Web-Services und weiterenDiensten sowie den Hintergrundsystemen durch Sicherheitsgateways(Firewalls) reglementiert?

- Werden die Verbindungen zwischen Webanwendungen oder Web-Services und Hintergrundsystemen bei hohem Schutzbedarf durch eineTransportverschlüsselung geschützt?

- Ist sichergestellt, dass Anfragen der Webanwendung oder des Web-Service an Hintergrundsysteme nur mit minimalen Rechten auf diesenausgeführt werden?

- Ist beim Einsatz eines ESB ein eigenes logisches Netzsegment für denESB vorgesehen? Ist der Zugriff auf den ESB ausschließlich durch dieangeschlossenen Anwendungen und Dienste möglich?

- Ist eine Segmentierung nach Zonen entsprechend den vorhandenenSicherheitsdomänen im ESB durchgehalten, nötigenfalls bis hin zurAuftrennung in mehrere ESB?

- Werden alle Zugriffe auf den ESB authentisiert und bei derKommunikation über Standort- und Netzgrenzen hinweg ausreichendgesichert/verschlüsselt?

- Sind bei der Realisierung und beim Betrieb des ESB geeigneteMaßnahmen zur Sicherstellung einer angemessenen Verfügbarkeitumgesetzt?



M 5.175 Einsatz eines XML-GatewaysVerantwortlich für Initiierung: Leiter IT, Verantwortliche der einzelnen

AnwendungenVerantwortlich für Umsetzung: Administrator, Leiter IT

Durch eine klassische Firewall kann sichergestellt werden, dass in geschlos-senen Umgebungen nur Endgeräte mit berechtigten IP-Adressen auf einenWeb-Service zugreifen können (Whitelisting) oder dass bei im Internet ver-fügbaren Web-Services IP-Adressen, von denen Angriffe, etwa durch Bot-netze, ausgehen, gesperrt werden können (Blacklisting). Zu Details sieheM 4.454 Schutz vor unerlaubter Nutzung von Web-Services. Derartige Fire-walls sind jedoch typischerweise nicht in der Lage, SOAP-Nachrichten zu ana-lysieren und Angriffe auf der Anwendungsschicht (SOAP/HTTP) zu erkennen.Daher sollte, insbesondere bei erhöhtem Schutzbedarf, zum Schutz von Web-Services der Einsatz eines sogenannten XML-Gateways in Erwägung gezo-gen werden, das diese Filterung auf XML-Ebene leistet.

Ein XML-Gateway ist eine Infrastrukturkomponente, die zwischen Web-Ser-vice und Consumer geschaltet wird und dabei als eine Firewall für Nachrich-ten in einer Web-Service-Infrastruktur agiert. Sie leistet damit für Web-Ser-vices das, was eine Web Application Firewall (WAF) für Webanwendungenausführt. Beide stellen Ausprägungen sogenannter Application Level Gate-ways (ALG) für unterschiedliche Anwendungsprotokolle dar. Das XML-Gate-way fängt XML-Nachrichten ab, um sie nach definierten Vorgaben zu ana-lysieren, bevor sie an den Web-Service weitergeleitet werden. Dafür kommtüblicherweise ein leistungsstarker, gehärteter Parser zum Einsatz, der einedefinierte Sicherheitsrichtlinie anwendet und teilweise auch über Heuristikenverfügt, die das Erlernen typischer Kommunikationen erlaubt. So können et-wa plötzlich sprunghaft anwachsende Nachrichtengrößen erkannt werden unddefinierte Aktionen und Alarme auslösen.

Ein XML-Gateway (auch als XML-Firewall, Web-Service-Firewall, Web-Ser-vice-Security-Gateway oder XML-SOAP-Proxy bezeichnet) ist eine Kompo-nente, die dem Schutz von Diensten vor Angriffen über XML-basierte Schnitt-stellen dient, indem es XML-Daten prüft, die die Institution erreichen oderverlassen. XML-Gateways können als eigenständige Systeme oder auch alsKomponente eines Enterprise Service Bus (ESB) realisiert werden.

Folgende Funktionen werden typischerweise bereitgestellt:

- Auslagerung von Authentisierung und Autorisierung an das Gateway- Zugriffskontrolle durch Zertifikate, SAML, LDAP, RADIUS und ähnliche

Methoden- Begrenzung von Datenraten als Maßnahme gegen Denial-of-Service-An-

griffe- Ver- und Entschlüsselung auf Transport- oder Nachrichtenebene- Anbringung und Prüfung von XML-Signaturen- Kontrolle von Datenflüssen- Validierung von XML-Nachrichten anhand von Schemata und Policys- Schutz vor in XML eingebetteten Angriffen wie Cross-Site Scripting, SQL-

Injection oder Command-Injection- Schutz vor bestimmten SOAP-/XML-spezifischen Angriffen wie zu großen

Nachrichten, zu stark verschlüsselten Elementen, rekursivem Parsen,bösartig manipulierten Schemata oder WSDL-Dateien sowie Angriffen aufdas Routing

- Scannen von SOAP-Body sowie SOAP-Attachments auf Schadsoftware



- Unterstützung verschiedener Web-Service-Sicherheitsstandards wie WS-Security, WS-SecureConversation, WS-Trust oder WS-Federation

- Auslösen von Alarmen, teilweise durch Anomalie-Erkennung in der Kom-munikation

- Teilweise auch Dienstvirtualisierung durch URL-Rewriting, XSL-Transfor-mationen und SOAP-basiertes Routing

Modelle verschiedener Hersteller unterscheiden sich vor allem im Da-ten-Durchsatz und der Latenz der Verbindung, in Funktionen zur Sicherstel-lung der Verfügbarkeit durch redundante Systeme, den vorhandenen Zertifi-zierungen (etwa nach Common Criteria), Unterstützung für Identitäts- und Zu-griffsmanagement (etwa durch SAML, OAuth oder für SSO-Lösungen), Kon-figurationsmöglichkeiten und Erweiterbarkeit.

Für den Einsatz eines XML-Gateways sollte daher im ersten Schritt eine An-forderungsanalyse erfolgen, in der die erforderlichen und wünschenswertenFunktionen ermittelt werden. Werden XML-Gateways bei höherem Schutzbe-darf eingesetzt, sollten zudem die zu erreichenden Sicherheitsziele definiertwerden.

XML-Gateways sind in der Lage, den eingehenden Datenverkehr auf bösarti-ge Inhalte zu untersuchen und diese herauszufiltern, damit eine Verarbeitungauf dem Endsystem gar nicht erst erfolgen kann. So können zum Beispiel vomAngreifer konstruierte fehlerhafte XML-Nachrichten bereits am Gateway her-ausgefiltert werden (siehe G 5.183 Angriffe auf XML). Die Gateways bietenoft auch eine ausgehende Datenflusskontrolle an, die zu verhindern versucht,dass sensible Inhalte aus dem internen Netz exfiltriert werden.

Damit kann ein XML-Gateway die meisten Aufgaben übernehmen, die in denMaßnahmen M 4.454 Schutz vor unerlaubter Nutzung von Web-Services undM 4.393 Umfassende Ein- und Ausgabevalidierung bei Webanwendungen undWeb-Services gefordert werden. Die Validierung eines Schemas etwa (sieheM 4.454 Schutz vor unerlaubter Nutzung von Web-Services) kann entwederbereits am XML-Gateway oder direkt auf dem System erfolgen, welches denWeb-Service bereitstellt. Die Entscheidung, an welcher Stelle die Validierungerfolgen soll, ist bereits in der Planung zu dokumentieren, da dies auch Aus-wirkungen auf die Gesamtarchitektur haben kann.

Folgende Vorteile ergeben sich beim Einsatz eines XML-Gateways:

- XML-Gateways sind für ihren Einsatzzweck optimiert. Das bedeutet in derRegel, dass sie speziell gehärtet und dadurch robust sind.

- Da in die Entwicklung viel Wissen über XML-basierte Angriffe und entspre-chende Sicherheitsmaßnahmen geflossen ist, erlauben XML-Gatewaysdie sichere Nutzung von Web-Services, wenn sie richtig konfiguriert wer-den.

- Einer der größten Vorteile eines XML-Gateways ist die Verwaltung derverschiedenen Aspekte einer Web-Service-Sicherheitsrichtlinie an einerzentralen Stelle (häufig in einem Web-Interface), anstatt für jeden Diensteinzeln. Dies kann helfen, Konzeptions- und Konfigurationsfehler zu ver-meiden. Das Managementinterface ist geeignet abzusichern.

Nachteile, die aus dem Einsatz eines XML-Gateways erwachsen können, sinddie folgenden:

- Wie bei anderen ALGs auch ist die Konfiguration eines XML-Gatewaysnicht trivial, sondern erfordert sorgfältige Planung und gründliches Testen.Dies gilt nicht nur für die Inbetriebnahme, sondern auch für alle Änderun-gen am Kommunikationsverhalten der betroffenen Web-Services.



- Ein XML-Gateway ist zwar wartungsarm, aber nicht wartungsfrei. Auchhier sollten regelmäßig Software- und Signaturupdates eingespielt wer-den, falls der Hersteller solche anbietet. Auch auf das Bekanntwerden vonSchwachstellen für das Gateway sollte geachtet und reagiert werden.

- Durch den Einbau eines weiteren Systems in die Verarbeitungskette steigtdas Risiko eines Verlusts der Verfügbarkeit durch Konfigurations-, Soft-ware- oder Hardwarefehler. Bei hohem Verfügbarkeitsbedarf sollte eineredundante Auslegung erfolgen.

- Insbesondere wenn das Gateway auch die Prüfung auf Schadsoftwareübernimmt, können Fehlalarme zu Beeinträchtigungen der Funktionalitätund Verfügbarkeit führen. Daher ist neben ausführlichem Testen auch ei-ne Abwägung der Risiken gegeneinander durchzuführen sowie gegebe-nenfalls ein Notfallkonzept zu erstellen.

- Bestimmte Angriffstypen sind komplex und entwickeln sich laufend wei-ter, sodass nicht davon ausgegangen werden darf, dass das XML-Gate-way jede Variante des Angriffs erkennen kann. Beispiele sind XML Signa-ture Wrapping-Angriffe (XSW) oder neuere Angriffe auf TLS/SSL wie etwaCRIME.

- Gerade bei ressourcenkritischen Services mit vielen kryptographischenOperationen kann der Einsatz eines Gateways notwendig sein, um die Re-chenlast bewältigen zu können. Gleichzeitig kann das Gateway dadurcheinen Flaschenhals darstellen, auf dessen innere Funktion und Leistungder Betreiber weniger Einfluss hat als auf den Web-Service selbst. Diesmacht umsichtige Planung und Tests notwendig.

Ähnlich einer Web-Application Firewall (WAF) kann der Einsatz einer XML-Firewall ein falsches Gefühl von Sicherheit erzeugen und dazu führen, dassSicherheitsmaßnahmen in der Softwareentwicklung und im Betrieb von Web-Services vernachlässigt werden. Dies ist häufig fatal, da für die meisten Ga-teways im Lauf der Zeit Methoden bekannt werden, wie deren Filterfunktio-nen umgangen werden können. Die Notwendigkeit von robustem Code undSicherheitschecks im Dienst selbst wird dadurch also nicht obsolet.

Typischerweise wird ein XML-Gateway wie andere ALGs auch in einem neu-tralen Grenznetz (DMZ) positioniert. Zu empfehlen ist auch hier der P-A-P-Aufbau mit vor- und nachgeschaltetem Paketfilter und dem XML-Gateway inder Mitte, was erheblich bessere Kontroll- und Protokollierungsmöglichkeitenbietet (siehe M 2.73 Auswahl geeigneter Grundstrukturen für Sicherheitsgate-ways). Zudem können die beiden Paketfilter das XML-Gateway selbst vor ein-fachen Attacken schützen und komplexitätsbedingte Fehlkonfigurationen dortteilweise kompensieren. Darüber hinaus können sie das Gateway bei der Fil-terung von unerwünschtem Datenverkehr (zum Beispiel durch Internet-Wür-mer) unterstützen und eine Überlastung zumindest hinauszögern.

Da ein XML-Gateway ein komplexes System darstellt, sind in allen Phasen desLebenszyklus von Konzeption bis Notfallvorsorge detaillierte Anforderungenzu stellen. Daher ist das XML-Gateway selbst im Sicherheitskonzept anhanddes Bausteins B 3.301 Sicherheitsgateway (Firewall) zu behandeln.

Prüffragen:

- Wurde in einer Anforderungsanalyse bestimmt, welche Funktionen einesXML-Gateways benötigt werden?

- Wurde die Entscheidung getroffen und dokumentiert, an welcher Stelledie Validierung von Nachrichten durchgeführt werden soll?

- Ist sichergestellt, dass in der Anwendungsentwicklung weiter dieForderungen nach robustem Code und Überprüfung der Eingangsdatenberücksichtigt werden?



- Ist die Platzierung des XML-Gateways geplant und begründet, etwa in derDMZ und zwischen zwei Paketfiltern (P-A-P)?

- Wurde das XML-Gateway selbst im Sicherheitskonzept erfasst und mitdem Baustein B 3.301 Sicherheitsgateway (Firewall) abgebildet?

Maßnahmenkatalog Notfallvorsorge M 6.32 Bemerkungen


M 6.32 Regelmäßige DatensicherungVerantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter ITVerantwortlich für Umsetzung: Administrator, Benutzer

Zur Vermeidung von Datenverlusten müssen regelmäßige Datensicherungendurchgeführt werden. In den meisten Rechnersystemen können diese weitge-hend automatisiert erfolgen. Es sind Regelungen zu treffen, welche Daten vonwem wann gesichert werden.

Es müssen mindestens die Daten regelmäßig gesichert werden, die nichtaus anderen Informationen abgeleitet werden können. Dokumentationen, Pro-gramm- und Programmablaufbeschreibungen sind gemäß M 2.111 Bereithal-ten von Handbüchern vorzuhalten.

Empfehlenswert ist die Erstellung eines Datensicherungskonzepts.

Abhängig von der Menge und Wichtigkeit der laufend neu gespeicherten Da-ten und vom möglichen Schaden bei Verlust dieser Daten ist folgendes fest-zulegen:

- ZeitintervallBeispiele: täglich, wöchentlich, monatlich

- ZeitpunktBeispiele: nachts, freitags abends

- Anzahl der aufzubewahrenden GenerationenBeispiel: Bei täglicher Komplettsicherung werden die letzten sieben Siche-rungen aufbewahrt, außerdem die Freitag-Abend-Sicherungen der letztenzwei Monate.

- Umfang der zu sichernden DatenAm einfachsten ist es, Partitionen bzw. Verzeichnisse festzulegen, die beider regelmäßigen Datensicherung berücksichtigt werden. Eine geeigneteDifferenzierung kann die Übersichtlichkeit vergrößern sowie Aufwand undKosten sparen helfen.Beispiel: selbst erstellte Dateien und individuelle Konfigurationsdateien

- Speichermedien (abhängig von der Datenmenge)Beispiele: Bänder, Kassetten, CDs oder DVDs, Festplatten

- Vorherige Löschung der Datenträger vor Wiederverwendung (z. B. beiBändern oder Kassetten)

- Zuständigkeit für die Durchführung (Administrator, Benutzer)- Zuständigkeit für die Überwachung der Sicherung, insbesondere bei au-

tomatischer Durchführung (Fehlermeldungen, verbleibender Platz auf denSpeichermedien)

- Dokumentation der erstellten Sicherungen (Datum, Art der Durchführungder Sicherung sowie gewählte Parameter, Beschriftung der Datenträger)

Wegen des großen Aufwands können Komplettsicherungen in der Regelhöchstens einmal täglich durchgeführt werden. Die seit der letzten Sicherungerstellten Daten können nicht wieder eingespielt werden. Daher und zur Sen-kung der Kosten sollten zwischen den Komplettsicherungen regelmäßig dif-ferentielle oder inkrementelle Sicherungen durchgeführt werden. Hinweise zuden verschiedenen Arten von Datensicherungen finden sich in M 6.35 Festle-gung der Verfahrensweise für die Datensicherung.

Eine differentielle oder inkrementelle Sicherung kann häufiger erfolgen, zumBeispiel sofort nach Erstellung wichtiger Dateien oder mehrmals täglich. DieVereinbarkeit mit dem laufenden Betrieb ist sicherzustellen.



Für eingesetzte Software ist separat zu entscheiden, ob sie von der regelmä-ßigen Datensicherung erfasst werden muss. Dies hängt beispielsweise davonab, wie aufwendig eine Neuinstallation und das Einspielen von Patches undUpdates ist. Unter Umständen ist es ausreichend, Sicherungskopien von denOriginaldatenträgern anzufertigen.

Es muss regelmäßig getestet werden, ob die Datensicherung auch wie ge-wünscht funktioniert, vor allem, ob gesicherte Daten problemlos zurückge-spielt werden können.

Alle Benutzer sollten über die Regelungen zur Datensicherung informiert sein,um gegebenenfalls auf Unzulänglichkeiten (zum Beispiel zu geringes Zeitin-tervall für ihren Bedarf) hinweisen oder individuelle Ergänzungen vornehmenzu können (zum Beispiel zwischenzeitliche Spiegelung wichtiger Daten aufder eigenen Platte). Auch die Information der Benutzer darüber, wie lange dieDaten wiedereinspielbar sind, ist wichtig. Werden zum Beispiel bei wöchentli-cher Komplettsicherung nur zwei Generationen aufbewahrt, bleiben in Abhän-gigkeit vom Zeitpunkt des Verlustes nur zwei bis drei Wochen Zeit, um dieWiedereinspielung vorzunehmen.

Falls bei vernetzten Rechnern nur die Server-Platten gesichert werden, ist si-cherzustellen, dass die zu sichernden Daten regelmäßig von den Benutzernoder automatisch dorthin überspielt werden. Bei größeren Änderungen an IT-Systemen oder im Informationsverbund muss der Datensicherungsprozessentsprechend angepasst werden.

Vertrauliche Daten sollten vor der Sicherung möglichst verschlüsselt werden,wobei darauf zu achten ist, dass eine Entschlüsselung auch nach einem län-geren Zeitraum möglich sein muss (siehe M 6.56 Datensicherung bei Einsatzkryptographischer Verfahren).

Der Ausdruck von Daten auf Papier ist keine angemessene Art der Datensi-cherung.

Prüffragen:

- Bei vertraulichen Daten, gegebenenfalls auch bei Auslagerung derBackups: Werden die gesicherten Daten verschlüsselt gespeichert?

- Werden zumindest alle Daten, die nicht aus anderen Informationenabgeleitet werden können, regelmäßig gesichert?

- Ist festgelegt, wie die Datensicherungen organisatorisch und technischablaufen?

- Entspricht das festgelegte Verfahren für die Datensicherungen denVerfügbarkeitsanforderungen?

- Sind die Benutzer über die Festlegungen zur Durchführung vonDatensicherungen informiert?

- Wird regelmäßig getestet, ob die gesicherten Daten problemloszurückgespielt werden können?



M 6.154 Notfallmanagement für Web-Services



Web-Services stellen eine flexible, aber auch komplexe Lösung dar, um Ge-schäftsprozesse durch IT zu unterstützen. Ein Ausfall oder Leistungseinbußenkönnen wesentliche Auswirkungen auf die unterstützten Geschäftsprozessehaben.

Daher ist es notwendig, unter Berücksichtigung des übergreifenden Notfallma-nagements (siehe Baustein B 1.3 Notfallmanagement) sowie des Datensiche-rungskonzepts (siehe Baustein B 1.4 Datensicherungskonzept) entsprechen-de Vorkehrungen zu treffen, um Notfällen vorzubeugen und sie angemessenzu behandeln.

Die Grundlage hierzu stellt eine Notfallplanung dar, die die unterschiedlichenrelevanten Ereignisse in der Risikoanalyse berücksichtigt. Diese können ins-besondere sein:

Ausfall des Web-Service

Der Web-Service oder einzelne Komponenten sind ausgefallen, und die vonihnen unterstützten Geschäftsprozesse funktionieren nicht.

Leistungseinbrüche

Der Web-Service oder einzelne Komponenten erbringen nicht die erforderlicheLeistung (zum Beispiel Antwortzeiten), und die Geschäftsprozesse werdendadurch beeinträchtigt. Ursache können beispielsweise Denial-of-Service-An-griffe oder aber saison- oder terminbedingte Lastaufkommen (zum Beispielzum Jahresabschluss) sein.

Logische Fehler im Web-Service

Der Web-Service selbst ist nach außen verfügbar. Seine interne Verarbeitungder Informationen erfolgt jedoch fehlerhaft. Dadurch sind die Informationenhinsichtlich ihrer Integrität gefährdet und die Ergebnisse der Arbeitsabläufebeeinträchtigt. Der Web-Service steht im eigentlichen Sinne nicht mehr zurVerfügung. Des Weiteren muss berücksichtigt werden, dass voraussichtlichauch die Datenbank des Web-Service durch die fehlerhaften Informationenhinsichtlich ihrer Integrität beeinträchtigt wurde.

Beeinträchtigung durch Abhängigkeiten

Andere Komponenten, von denen der Web-Service abhängig ist, sind in ihrerVerfügbarkeit oder Leistungsfähigkeit beeinträchtigt. Komponenten könnenhierbei beispielsweise andere Web-Services, Authentisierungsdienste, Spei-chersysteme oder auch die relevanten Netze und Netzzugänge sein. Die Be-einträchtigung dieser Komponenten kann zum einen bedeuten, dass der Web-Service selbst nicht verfügbar ist. Andererseits können lediglich relevante Tei-le der Funktionalität des Web-Service beeinträchtigt sein.

Solche Szenarien haben jeweils auch Auswirkungen auf die Leistungsfähigkeitder Geschäftsprozesse, in denen die Web-Services eingesetzt werden. DieseAuswirkungen müssen analysiert und die entsprechenden Abhängigkeiten in



der Business Impact Analyse (BIA) berücksichtigt werden. Dabei sind auchmittelbare Abhängigkeiten über andere Web-Services, die mit dem betrachte-ten Web-Service interagieren, zu berücksichtigen.

Auf Basis der Ereignisse und der mit ihnen verbundenen Auswirkungen müs-sen geeignete präventive und reaktive Maßnahmen im Rahmen der Notfall-planung entwickelt werden.

Im Notfallvorsorgekonzept sind geeignete Vorsorgemaßnahmen für die Web-Services zu berücksichtigen:

- Für die kryptographischen Funktionen müssen die erforderlichen Schlüs-sel wiederherstellbar sein. Neue Schlüssel und Zertifikate, zum Beispielfür die Transportverschlüsselung, müssen in ausreichend kurzer Zeit ge-neriert oder beschafft werden können. Unter Umständen kann dazu dieVorhaltung von Ersatzschlüsseln an einem sicheren Ort dienen.

- Erforderliche Konfigurations- und Metadaten der Web-Services müssendokumentiert und gesichert werden, um eine Wiederherstellung zu ermög-lichen.

- Die Dokumentation muss an geeigneter Stelle vorgehalten werden, um imNotfall schnell verfügbar zu sein. Die Qualität der Dokumentation musses möglich machen, dass ein sachverständiger Dritter sich damit in ange-messener Zeit in die Umgebung einarbeiten kann.

- Bestehen hohe oder sehr hohe Anforderungen an die Verfügbarkeit desWeb-Service, sollte geprüft werden, ob der Web-Service redundant undüber unterschiedliche Standorte verteilt aufgebaut wird.

Die konkreten Maßnahmen für den Wiederanlauf eines Web-Service müssenin einem Wiederanlaufplan beschrieben werden. Dabei ist zu beachten:

- Der Wiederanlauf muss den zeitlichen Anforderungen der Geschäftspro-zesse entsprechen.

- Auch während des Notfalls und des Wiederanlaufs müssen die Sicher-heitsanforderungen weitestmöglich erfüllt bleiben (zum Beispiel Policy Ma-nagement).

- Die Planungen müssen die Reihenfolge der Komponenten des Web-Ser-vice beim Wiederanlauf berücksichtigen.

- Abhängigkeiten zu anderen Web-Services müssen ebenfalls berücksich-tigt werden. Dies kann insbesondere Auswirkungen auf die Reihenfolgedes Wiederanlaufs haben.

Werden die Web-Services für Dritte erbracht, so ist zu prüfen, welche Anfor-derungen seitens der Dienstnutzer an die Notfallplanung bestehen, und wiedie Vorsorge- und Reaktionsmaßnahmen auf beiden Seiten aufeinander ab-gestimmt werden können.

Die Notfallplanung muss schließlich regelmäßig praktisch getestet werden.Nur so kann sichergestellt werden, dass die in den Wiederanlaufplänen be-schriebenen Maßnahmen tatsächlich durchführbar sind. Gleichzeitig lernendie Mitarbeiter in den Übungen die beschriebenen Abläufe kennen und trai-nieren ihre Umsetzung. Schließlich vermittelt die Übung Erkenntnisse zu dentatsächlichen Wiederherstellungs- und Wiederanlaufzeiten und erlaubt so diePrüfung der Einhaltung der in der BIA ermittelten Vorgaben.

Prüffragen:

- Sind Web-Services als Ressourcen für Geschäftsprozesse in derBusiness Impact Analyse angemessen berücksichtigt? Wurden dabeiauch die Abhängigkeiten von Web-Services untereinander beachtet?



- Ist eine ausreichend schnelle Wiederherstellung der Web-Services unterBerücksichtigung von erforderlichen kryptographischen Schlüsseln,Konfigurations- und Metadaten, möglich?

- Ist die Dokumentation im Notfall verfügbar und aussagekräftig?- Wurde ein Wiederanlaufplan für den Web-Service ausgearbeitet? Sind die

Abhängigkeiten der Komponenten des Web-Service untereinander unddie Abhängigkeiten zu anderen Web-Services dabei berücksichtigt?

- Haben Notfälle beim Web-Service Auswirkungen auf Dritte, und sind dieNotfallmaßnahmen mit diesen abgestimmt?

- Werden die Notfallmaßnahmen regelmäßig getestet?

Kreuzreferenztabelle für B 5.24

199

G 2.1 G 2.7 G 2.22 G 2.27 G 2.61 G 2.67 G 2.87 G 2.103 G 2.158 G 2.159 G 2.160 G 2.181 G 3.3 G 3.16 G 3.38 G 3.119 G 3.120 G 3.121 G 4.13 G 4.22 G 4.33 G 4.35 G 4.84 G 4.85 G 4.87 G 4.94 G 5.18 G 5.19M 2.1 PK A X X XM 2.8 BT A X X X XM 2.31 BT A X X X XM 2.34 BT A X XM 2.35 BT B X X XM 2.62 BE B X X XM 2.64 BT A X X X X XM 2.80 PK A X XM 2.110 BT A X X XM 2.273 BT A X XM 2.363 PK B XM 2.486 PK A XM 2.487 PK B X X X X X X XM 2.530 PK B XM 2.531 PK A X X XM 2.532 UM B XM 2.533 BE C X X X XM 3.5 BT A X X X X X XM 4.78 BT A X X XM 4.393 UM B X X XM 4.394 UM AM 4.395 UM B X XM 4.397 BT C X XM 4.400 BT B XM 4.405 UM C XM 4.450 UM A X XM 4.451 PK W XM 4.452 BT A X X XM 4.453 UM Z XM 4.454 UM A X XM 4.455 UM A X X XM 4.456 UM A X XM 4.457 PK B XM 4.458 PK A X XM 5.150 BT Z X X X X X X X XM 5.168 PK A X X XM 5.175 UM Z X X X XM 6.32 NV A XM 6.154 NV B X X

G 5.20 G 5.28 G 5.87 G 5.131 G 5.165 G 5.167 G 5.168 G 5.169 G 5.172 G 5.173 G 5.174 G 5.179 G 5.180 G 5.181 G 5.182 G 5.183 G 5.184

M 2.1 PK AM 2.8 BT A X XM 2.31 BT A XM 2.34 BT AM 2.35 BT B XM 2.62 BE BM 2.64 BT A XM 2.80 PK AM 2.110 BT AM 2.273 BT AM 2.363 PK B X XM 2.486 PK AM 2.487 PK B XM 2.530 PK B XM 2.531 PK AM 2.532 UM BM 2.533 BE CM 3.5 BT AM 4.78 BT A X X X

Kreuzreferenztabelle für B 5.24

200

G 5.20 G 5.28 G 5.87 G 5.131 G 5.165 G 5.167 G 5.168 G 5.169 G 5.172 G 5.173 G 5.174 G 5.179 G 5.180 G 5.181 G 5.182 G 5.183 G 5.184M 4.393 UM B X XM 4.394 UM A X XM 4.395 UM B XM 4.397 BT C X XM 4.400 BT B X XM 4.405 UM C X XM 4.450 UM AM 4.451 PK WM 4.452 BT AM 4.453 UM ZM 4.454 UM AM 4.455 UM A XM 4.456 UM AM 4.457 PK BM 4.458 PK AM 5.150 BT Z X X X X X X X X X X X X XM 5.168 PK AM 5.175 UM Z X X X XM 6.32 NV AM 6.154 NV B X

Documents

Baustein B 5.24 Web-Services