Testat nach OPDV-Stellungnahme Nr. 1/2006

Transcription

Testat nach OPDV-Stellungnahme Nr. 1/2006
Reuters RET-AD, Client-Applet in der Version
3.3 SP3
( Abschlussergebnis )
Dokumentversion 2.13 vom 10.07.2008 11:08
INFORMATIKZENTRUM
DER SPARKASSENORGANISATION GMBH
Abschlussergebnis: Testat nach OPDV-Stellungnahme Nr. 1/2006
angewendet auf Reuters RET-AD, Client-Applet
INFORMATIKZENTRUM
Inhaltsverzeichnis
1 Vorwort und Zusammenfassung ...................................................................1
1.1 Benutzung / Zweck des Dokumentes..............................................................2
1.2 Prüfgegenstand...............................................................................................3
1.2.1 Identifizierung ..................................................................................................3
1.2.2 Produktbeschreibung und -abgrenzung ...........................................................3
1.3 Prüfkriterien ....................................................................................................5
1.4 Ziel der Prüfung ..............................................................................................5
1.5 Voraussetzungen der Prüfung ........................................................................6
1.6 Prüfgrundsätze und -vorgehen .......................................................................6
1.7 Grenzen des Dokuments ................................................................................7
1.8 Projektbeteiligte ..............................................................................................7
1.9 Projektverlauf ..................................................................................................8
2 Details zur Risikoklassifizierung ...................................................................8
2.1 Wirtschaftliche Auswirkungen & Auswirkungen auf Entscheidungen..............9
2.2 Auswirkungen auf die Kundenbeziehung......................................................10
2.3 Auswirkungen auf das Sicherheitsniveau .....................................................10
2.4 Einhaltung gesetzlicher oder bankaufsichtsrechtlicher Vorschriften .............11
2.5 Datenüberstellung in autorisierte Programme...............................................11
3 Literaturverzeichnis (inkl. Angaben zum geprüften Projekt) ....................12
4 Zusammenfassende Bewertung der IT-Anwendung aus Sicht der
Stellungnahmen ............................................................................................17
5 Detailbewertung der Bereitstellungs- und Wartungsprozesse
(Projektverantwortung).................................................................................18
5.1 Fehlerfreie Herstellung der IT-Anwendung ...................................................18
5.1.1 Anforderungserfassung (AE) .........................................................................18
5.1.2 Architektur und Schnittstellendesign, Geschäftsprozessmodellierung (GPM) 18
5.1.3 Einhaltung von Programmierkonventionen ....................................................19
5.1.4 Programm- bzw. Systemdokumentation ........................................................19
5.1.5 Durchführung und Dokumentation der Entwicklertests...................................19
Quelle: IT-Testierungen nach OPDV-Stellungnahme Nr. 1/2006, koenig
080528_QSRP(Reuters,RetAd)TYP=TST(unterschrieben).doc
Seite: i
Stand: 10.07.08
INFORMATIKZENTRUM
5.2 Nachweis einer vollumfänglichen Qualitätssicherung ...................................19
5.3 Bereitstellung und Identifikation des Liefergegenstandes sowie seiner
Quellen .........................................................................................................20
5.3.1 Versionsverwaltung und Identifikation............................................................20
5.3.2 Lieferumfang .................................................................................................20
6 Detailbewertung aus Sicht der Benutzer bzw. Fachbereiche....................21
6.1 Fachliche Berücksichtigung von gesetzlichen oder normativen Vorgaben ...21
6.1.1 BGB...............................................................................................................21
6.1.2 HGB ..............................................................................................................21
6.1.3 KWG..............................................................................................................22
6.1.4 AO (Abgabenordnung und Aufbewahrungsfristen).........................................22
6.1.5 GoBS und Verarbeitung buchungsrelevanter Geschäftstransaktionen...........22
6.2 Fachliche Administration der IT-Anwendung ................................................23
6.3 Korrekte Bedienung durch den Anwender ....................................................23
6.4 Internes Kontrollsystem (IKS) der Sparkasse ...............................................23
7 Detailbewertung aus Sicht des Betreibers / der Produktion .....................23
7.1 Installation und Betriebsaufnahme................................................................24
7.2 Sicherstellung eines sicheren IT-Betriebes...................................................24
7.2.1 IT-Dokumentation (K015) ..............................................................................24
7.2.2 Archivierungsmedien, -fristen (K020).............................................................24
7.2.3 SLV Betreuungsqualität (K305) .....................................................................24
8 GLOSSAR ......................................................................................................25
9 INDEX .............................................................................................................31
10 Unterschrift....................................................................................................32
Seite: ii
Stand: 10.07.08
©
INFORMATIKZENTRUM
GmbH Bonn, 10. Juli 2008
Diese Dokumentation dient zur Information der Mitarbeiter1 der SparkassenFinanzgruppe. Weitergehende Veröffentlichungen, Nachdruck, Vervielfältigungen
oder Speicherung - gleich in welcher Form, ganz oder teilweise - sind nur mit Zustimmung der SIZ GmbH zulässig. Ebenso darf diese Dokumentation Dritten gegenüber nur mit ausdrücklicher Zustimmung des SIZ und entsprechend der vom Aufsichtsrat des SIZ getroffenen Regelungen weitergegeben werden.
Diese Dokumentation enthält neben Erläuterungen, Bewertungen und eigenen Erhebungen Beschreibungen von Herstellerprodukten, Schnittstellen und Konzepten, die
auf entsprechenden Veröffentlichungen der jeweiligen Hersteller beruhen. Sofern in
der Dokumentation dem SIZ besondere Geschäfts- oder Betriebsgeheimnisse von
Herstellern offengelegt wurden, sind diese in der Dokumentation entsprechend gekennzeichnet und unterliegen damit der besonderen Geheimhaltung.
1
Aus Gründen der Einfachheit des Ausdrucks wird nur von Mitarbeitern, Teilnehmern, Benutzern usw.
gesprochen, obgleich selbstverständlich auch immer Mitarbeiterinnen und Mitarbeiter gemeint sind.
Stand: 10.07.08
INFORMATIKZENTRUM
Versionsführung dieses Dokumentes:
Wer
Hr. König
Wann/ Version
V080215
V2.10
Was
Inhaltliches Protokoll über den Workshop angepasst
QS des Workshopprotokolls durch Herrn Dünnwald, SIZ
V080310
V2.11
Berücksichtigung der Unterlagen ab [100]
Hr. König
V080502
V2.12
Berücksichtigung des Testnachweises [156] der
HSH Nordbank und Testatentwurf zur Rücksprache mit Reuters
Hr. König
V080528
V2.13
Berücksichtigung der Testnachweise ab [157]
und der Textvorschläge von Reuters
QS des Testatentwurfes durch Herrn Dünnwald,
SIZ
Hr. König
QS der Befundliste durch Herrn Dünnwald, SIZ
1 Vorwort und Zusammenfassung
Die in den letzten Jahren eingeführten Internet-basierten Infrastrukturen, wie sie bspw. die
auf Browsern basierenden Client- und Serverarchitekturen erfordern, eröffnen den
Anwendern die komfortable Abwicklung von Transaktionen ohne komplexe
Softwareinstallation auf den Arbeitsplatzsystemen. Zugleich bringen die neuen Technologien
neue Risikopotentiale mit sich, die mit immer sorgfältigerer Planung, Umsetzung und
Überprüfung der IT-Anwendungen und Infrastrukturen einzugrenzen sind.
Dies sicherzustellen ist Aufgabe des jeweiligen Projektmanagements, der beteiligten
Fachabteilungen sowie der Innenrevision. Mit der Stellungnahme OPDV 1/2006 liegen
Regularien für die Freigabe eines Systems vor. Soweit es sich um fremd entwickelte,
komplexe Systeme handelt, wird der Aufwand hierfür jedoch zunehmend größer. Wenn der
Einsatz des Systems dann noch bei mehreren Betreibern vorgesehen ist, dann bietet es sich
an, die Freigabe in eine Programmfreigabe und eine Einsatzfreigabe aufzuspalten.
Im Rahmen der Programmfreigabe sind die fachliche Eignung entsprechend den
Anforderungen des Fachkonzepts, die sachgerechte Umsetzung in der
Programmierung innerhalb eines geordneten Programmentwicklungsverfahrens,
der erfolgreiche Test von Verarbeitungsfunktionen und -regeln innerhalb der
Anwendung (ggf. einschl. Schnittstellen) sowie das Vorliegen einer aktuellen
Verfahrensdokumentation zu beurteilen.
Unter besonderen Umständen können Umfang und Intensität der
Qualitätssicherungsmaßnahmen einer Programmfreigabe reduziert werden, ggf.
sogar ganz unterbleiben. Dies kann der Fall sein
o
bei Betriebssystemen und betriebssystemnaher Software
2
z. B. IDW PS 880, ISO-Normen
3
z. B. Prüfungsstellen, BSI, Wirtschaftsprüfungsgesellschaft , TÜV-IT
Seite: 1
Stand: 10.07.08
o
bei Programmen von IT-Dienstleistern, die sich dazu verpflichtet haben, ihr
Programmeinsatzverfahren nach Maßgabe dieser Stellungnahme
auszurichten, und gewährleisten, dass die Einhaltung dieser Verpflichtung
regelmäßig geprüft wird
o
bei typischerweise nicht bankfachlicher Standard-Software (z. B.
Bürosoftware), wenn die Funktionsfähigkeit aufgrund der
Vertrauenswürdigkeit in die Qualität der Softwareentwicklung der
Herstellerfirma unterstellt werden kann, z. B. aufgrund des hohen
Verbreitungs- und Bekanntheitsgrads
o
wenn die Programmfreigabe eines vertrauenswürdigen Dritten (z. B. DSGV,
SIZ, andere Sparkasse oder IT-Dienstleister als Vertreter) i. S. dieser
Stellungnahme vorliegt und eine unveränderte Programmversion eingesetzt
wird
o
INFORMATIKZENTRUM
beim Vorliegen eines qualifizierten Softwaretestats4 von einer anerkannten
Prüfungseinrichtung5 und dem Einsatz einer unveränderten Version des
Programms. Entsprechende Nachweise sind nachvollziehbar zu
dokumentieren.
Gegenstand der Einsatzfreigabe ist die Untersuchung der organisatorischen und
technischen Prozesse des Anwenders, die den Einsatz innerhalb der
vorhandenen Umgebung bestimmen, sowie die Gewährleistung der
Funktionsfähigkeit von Schnittstellenprozessen zu vor- und nachgelagerten
Anwendungen und der Belastbarkeit im Echtbetrieb.
Besonderer Aufmerksamkeit bedürfen die Einbindung in das Interne
Kontrollsystem und die Parametrisierung des neuen Programms sowie die
Ergebnisse von Integrationstests.
Voraussetzung für die durchzuführende Beurteilung sind das Vorliegen
vollständiger und aktueller Programm- und Hardwareübersichten sowie
angemessene Verfahren in den Bereichen Beschaffung und ChangeManagement.
Im Verlauf der Prüfung kam auch die Checkliste Prüfungen nach OPDV 1/2006 des SIZ zum
Einsatz. Diese Liste baut auf der Stellungnahme Nr. 1/2006 des Fachausschusses OPDV
auf und berücksichtigt die Praktiken und Erfahrungen mit DV-Projekten innerhalb der
Sparkassen-Finanzgruppe. Dieses Testat ist somit eine thematisch umfassende und
unabhängige Analyse des Entwicklungs-, Qualitätssicherungsprozesses sowie des
Praxiseinsatzes, der dem Freigabeverfahren nach OPDV 1/2006 unterliegt. Das Testat
berücksichtigt insbesondere auch Aspekte des Projektmanagements, der IT-Qualität, der
Softwareentwicklung sowie der IT-Sicherheit.
1.1 Benutzung / Zweck des Dokumentes
Kursive Texte kennzeichnen Originalzitate aus anderen Dokumenten oder Vorgaben.
4
z. B. IDW PS 880, ISO-Normen
5
z. B. Prüfungsstellen, BSI, Wirtschaftsprüfungsgesellschaft , TÜV-IT
Seite: 2
Stand: 10.07.08
INFORMATIKZENTRUM
1.2 Prüfgegenstand
1.2.1 Identifizierung
Im Rahmen der hier dokumentierten Prüfung ist die erstellte IT-Anwendung Reuters RETAD, Client-Applet in der Version 3.3 SP3 und deren Herstellungsprozess bei der Thomson
Reuters AG6 zu untersuchen und zu bewerten [IDW PS 880, Tz2].
1.2.2 Produktbeschreibung und -abgrenzung
Gegenstand der Prüfung ist ein Softwaresystem namens RET-AD, Client-Applet.
RET-AD stellt eine Handelsplattform für Devisen und Geldmarkt Geschäfte bereit. Hierbei
kommen neben weiteren Komponenten folgende drei Hauptkomponenten zum Einsatz:
1. Eine Händlerplattform (in den Unterlagen als Trader-Applet bezeichnet) einschließlich der Konfigurationsoberflächen (Admin-Applet), die es einem Anbieter der mit
dieser IT-Anwendung gehandelten Papiere erlaubt, seine Angebote abzugeben, sowie später den Handel dieser Papiere zu steuern. Diese Komponenten werden im
Rahmen der hier beschriebenen Prüfung nicht vertiefend behandelt, explizit genannte
Aspekte ausgenommen. Sie stellen Client-Anwendungen dar.
2. Eine Serverlandschaft bestehend aus der Gesamtheit aller für den Betrieb der
Client-Anwendungen erforderlichen Server. Diese Server stehen zum großen Teil
beim Betreiber der Handelsplattform, dies kann sowohl durch oder für Reuters erfolgen als auch durch oder für den Händler. Auch diese Komponenten werden im Rahmen der hier beschriebenen Prüfung nicht vertiefend behandelt, explizit genannte
Aspekte ausgenommen.
3. Die Plattform, die es einem Kunden erlaubt, die angebotenen Devisen und Geldmarkt
Geschäfte durchzuführen. Sie wird in den Unterlagen als Client-Applet bezeichnet
und wird auf dem Rechner der Personen als Client-Anwendung ausgeführt, die den
Handel plant und durchführt.
Die Komponente RET-AD, Client-Applet erlaubt als Fat-Client-Komponente die Durchführung
von Devisen und Geldmarkt Geschäften eines externen Traders. Für eine nähere Beschreibung siehe die entsprechenden Handbücher. Einen allgemeinen Überblick liefern die beiden
folgenden Grafiken.
6
Nachfolgend mit Hersteller abgekürzt.
Seite: 3
Stand: 10.07.08
INFORMATIKZENTRUM
Die linke Darstellung aus [126,
S20, 2.1] zeigt
die Einbindung
der in dieser Testierung betrachteten Teilkomponente RET-AD,
Client Applet in
das Gesamtsystem.
Den groben
Funktionsumfang
des in der obigen
Darstellung mit
RET-AD Server
bezeichneten
Teils der Anwendung zeigt die
linke Grafik aus
[125, S6, 3.1].
Die vom Gesamtsystem erbrachte Funktionalität wird dabei
im wesentlichen
von den Komponenten erbracht,
die in der Liste
Detail of Application server genannt werden.
Seite: 4
Stand: 10.07.08
INFORMATIKZENTRUM
Die Prüfaussage dieses Prüfberichts bezieht sich ausschließlich auf die Systemkomponente
(Kernbestandteil) Reuters RET-AD, Client-Applet.
Die ebenfalls zum Gesamtsystem gehörenden Systemkomponenten
Sämtliche Server,
Trader-Applet und Admin-Applet
sind nicht Bestandteil der Überprüfung. Allgemeine Aussagen der vorliegenden Prüfungsdokumentation gelten daher nur dann auch für diese Systemkomponenten, wenn explizit darauf
hingewiesen wird.
1.2.2.1 Schnittstellen
Folgende Schnittstellen des RET-AD, Client-Applets sind vorhanden:
Der Aufruf durch den Anwender erfolgt in einem Browser mittels eines HTTPS
(Port 443) URL Aufrufs an den SCS (Secure Communication Server) zum Webserver. Der SCS übernimmt die Zertifikat Verwaltung.
Das Java-Client-Applet benutzt als alleinige Schnittstelle eine HTTPS (Port 443)
Verbindung zum SCS Server an den WebServer. Als unsigned Java-Applet steht
der im Web-Browser des Anwenders ablaufenden IT-Anwendung nur die Schnittstelle zum liefernden Server offen. Weitere Schnittstellen sind nicht benannt und
würden durch die Laufzeitumgebung des Web-Browsers abgeblockt. Details siehe
Abschnitt 2.3 Auswirkungen auf das Sicherheitsniveau.
Weitere Schnittstellen sind an den Server-Komponenten vorhanden, werden im Rahmen der
hier vorliegenden Dokumentation aber nur in Einzelfällen behandelt, da sie im Verantwortungsbereich des Server-Betreibers liegen. Hierzu gehören u. a. alle fachlichen Schnittstellen
zur Ermittlung von Preisen, zur Abwicklung des Handelsgeschäftes sowie seiner Dokumentation.
1.3 Prüfkriterien
Die Prüfung erfolgt auf der Grundlage der von:
Fachausschuss Ordnungsmäßigkeit und Prüfung der Datenverarbeitung, Stellungnahme Nr. 1/2006, Anforderungen an einen ordnungsgemäßen SoftwareEinsatz in ihrer aktuellen Fassung.
Die Prüfung erfolgte unter Hinzuziehen der folgenden Checkliste:
Checkliste - Prüfungen nach OPDV 1/2006, Version vom 12.11.2007, SIZ
1.4 Ziel der Prüfung
Vor Inbetriebnahme eines IT-Systems innerhalb der Sparkassen-Finanzgruppe ist eine Programmfreigabe nach OPDV 1/2006 erforderlich.
Als Vorbereitung auf die Freigabe analysiert ein unabhängiger Mitarbeiter des SIZ die Ergebnisse aller am Abnahmeprozess Beteiligten und bewertet im vorliegenden Testat, inwieweit die Anforderungen der OPDV 1/2006 eingehalten sind, d. h. es wird im Testat eine Aussage zur Ordnungsmäßigkeit der Verarbeitung des IT-Systems getroffen. Sofern alle Anforderungen eingehalten sind, wird eine Empfehlung zur Freigabe ausgesprochen. Diese Empfehlung findet sich im Abschnitt 4 Zusammenfassende Bewertung der IT-Anwendung aus
Sicht der Stellungnahmen.
Seite: 5
Stand: 10.07.08
INFORMATIKZENTRUM
Als Besonderheit bezieht sich das konkrete Freigabeverfahren des SIZ für Reuters RET-AD,
Client-Applet lediglich auf eine „Programmfreigabe“. Vor einem tatsächlichen Einsatz von
Reuters RET-AD, Client-Applet innerhalb der Sparkassen-Finanzgruppe ist zusätzlich ein
institutsspezifisches Einsatzfreigabeverfahren zu durchlaufen. Dies muss den örtlichen Gegebenheiten des Betreibers Rechnung tragen und den Integrationsprozess berücksichtigen.
Insbesondere sind seine infrastrukturellen, organisations- und bundeslandspezifischen Vorschriften und Regelungen bzw. Gesetze einzubeziehen.
1.5 Voraussetzungen der Prüfung
Für den vorliegenden Prüfbericht ist Folgendes vorausgesetzt:
Prüfer erfüllen die persönlichen, fachlichen und formalen Voraussetzungen für die
Durchführung der Prüfung nach OPDV 1/2006.
Das IT-System bzw. IT-Produkt unterliegt den Regelungen der OPDV 1/2006.
Grundsätzlich haben die Betreiber wie auch der Prüfer das Vertrauen in den Hersteller, dass er seine Kompetenzen nach bestem Wissen und Gewissen einsetzt.
Damit mögliche Fehler vermieden oder zumindest erkannt und beseitigt werden
können, gewährte der Hersteller dem Prüfer einen umfassenden und detaillierten
Einblick in seine internen Abläufe. Dies beinhaltet seine Prozesse, Verfahren, Methoden und Dokumente. Hierdurch wird das Vertrauen in die Produkte des Herstellers gestärkt. Die Offenlegung dieser betriebsinternen Informationen erfolgt im
wechselseitigen Vertrauen auf die Einhaltung üblicher Vertraulichkeitsregelungen.
In den Prüfbericht fließen ausschließlich Informationen, die für die Analyse und
Bewertung nach OPDV 1/2006 erforderlich sind.
1.6 Prüfgrundsätze und -vorgehen
Die für die Prüfung nach OPDV 1/2006 angewendeten Grundsätze sind:
Die Prüfung begleitet den Lebenszyklus des IT-Systems bzw. IT-Produkts beginnend mit der Anforderungsdefinition bis hin zur Auslieferung an den Kunden.
Die Prüfung bewertet sämtliche Qualitätsprozesse und schließt die fachkundige
Bewertung der IT-technischen, infrastrukturtechnischen, organisatorischen, prozessualen und sicherheitstechnischen Maßnahmen ein.
Die Prüfung bewertet auch, ob beim Softwareentwickler die Anforderungen gemäß OPDV 1/2006 eingehalten wurden.
Die Prüfung stützt sich sowohl auf die Herstellerdokumentation als auch auf ein
am 13. Februar 2008 durchgeführtes Kurzaudit beim Softwarehersteller, bei dem
eine grobe Vorstellung des Supportprozesses präsentiert wurde.
Die Prüfung wendet das „Prinzip des Unabhängigen Dritten“ an, d. h. die Abnahme wird von unabhängigen SIZ-Mitarbeitern überprüft. Die Aussagekraft der Überprüfung und die dadurch erzielbare Qualität wird so deutlich gesteigert. Das
Arbeitsergebnis der unabhängigen Analyse ist vorliegender Prüfbericht.
Die Prüfung wird unter der „going concern“ Annahme des Softwareherstellers
durchgeführt, d. h. die Bewertungen werden unter der Voraussetzung getroffen,
dass das die IT-Anwendung herstellende Unternehmen fortbesteht.
Seite: 6
Stand: 10.07.08
INFORMATIKZENTRUM
1.7 Grenzen des Dokuments
Dieses Testat ist thematisch sehr umfassend angelegt, so dass erwartet werden kann, dass
alle IT-technischen Aspekte der Programmfreigabe nach OPDV 1/2006 abgedeckt sind. Seine Grenzen werden hier konkretisiert.
Das Testat betrachtet ausschließlich die in direktem Zusammenhang mit der Informationstechnologie stehenden Aspekte, die zur erfolgreichen Projektabwicklung bzw. System- und Produktentwicklung gehören. Dies schließt sämtliche zugehörigen organisatorischen wie technischen Themen ein. Bspw. gehört das Projektmanagement ebenso zu den Aspekten wie Dokumentation, Entwicklung, Herstellertests, Abnahmetests sowie IT-Qualität und IT-Sicherheit. Nur bedingt betrachtet werden dedizierte juristische oder betriebswirtschaftliche Aspekte. Auch
sind Aspekte wie die Analyse des Kundenbedarfs an anderer Stelle zu betrachten.
Die Überprüfung erfolgt immer gegen die Produktspezifikation, deren inhaltliche
Korrektheit und Vollständigkeit ausschließlich in der Verantwortung des Herstellers liegt. Die Spezifikation wird lediglich darauf hin überprüft, ob sie ausreichend
vollständig und in sich schlüssig ist.
Anforderungsdefinitionen bzw. zu Grunde gelegte Standards werden grundsätzlich nicht hinterfragt, es sei denn, dass sie offensichtlich unvollständig oder unangemessen sind.
Insbesondere nicht enthalten ist eine Detailanalyse des IT-Systems bzw. Produkts
bspw. im Rahmen eines Codereview [IDW PS 880, Tz22]. Solche tiefgehenden
Analysen erforderten das Anwenden bspw. von IT-Sicherheitskriterien wie den
„Common Criteria“ (ISO 15408) oder des Sicheren IT-Betriebs des SIZ, was inhaltlich sowie im Umfang ausdrücklich außerhalb dieser Prüfung liegt.
Das vorliegende Testat greift der Einsatzfreigabe nach OPDV 1/2006 durch die
zuständige Revision nicht vor. Diese Freigabe bleibt exklusiv dem jeweiligen Institut vorbehalten.
Grundsätzlich muss jeder Betreiber vor Einsatz des Produktes sein eigenes Freigabeverfahren durchführen, welches die konkreten Gegebenheiten des Betreibers
berücksichtigt. Dabei ist es empfohlen und gewollt, die aus der Programmfreigabe
gewonnenen Erkenntnisse in die eigene Analyse einzubinden. Im Rahmen dieses
Einsatzfreigabeverfahrens muss durch das anwendende Institut auch geklärt werden, ob die angebotenen Handelsszenarien den eigenen Erfordernissen entsprechen, eine diesbezügliche Untersuchung ist im Rahmen des vom SIZ durchgeführten Programmfreigabeverfahrens nicht abschließend möglich gewesen.
Hinsichtlich der in [IDW PS 880, Tz19] geforderten eigenen Testfälle des Prüfers
wird im Rahmen der hier dokumentierten Prüfung überprüft, ob in den vorgelegten
Testprotokollen auch die Prüffälle enthalten sind, die aus Sicht des Prüfers durchgeführt werden müssten. Hierzu werden sowohl Prüfungen auf in der Software
erwartete Eigenschaften als auch Prüfungen auf nicht in der Software zugelassene Eigenschaften (siehe [IDW PS 880, Tz20]) herangezogen und dabei alle potentiellen Störquellen betrachtet. Einem vorgelegten Testprotokoll wird dabei nicht
blind vertraut, es wird seitens des Prüfenden hier immer ein Nachweis über die
Korrektheit des Testprotokolls verlangt.
1.8 Projektbeteiligte
Hersteller und Lieferant
Seite: 7
Stand: 10.07.08
INFORMATIKZENTRUM
Hersteller und Lieferant von Reuters RET-AD, Client-Applet ist die Thomson Reuters AG.
Die Entwicklung hat stattgefunden in Thailand bei RSTL. Tests wurden nicht belegt.
Betreiber
Hinweis: Die erforderliche Betreiberfreigabe seitens der Rechenzentren ist nicht Gegenstand
dieses Berichts.
Abnahmen
Die Thomson Reuters AG ist Anbieter von Reuters RET-AD, Client-Applet.
Von der HSH Nordbank liegt mit [156] ein als bestanden zu wertendes Testprotokoll vor.
Seitens der Rechenzentren und der Projektsparkassen liegen keine Abnahmeschreiben vor.
Prüfinstitut
Die Prüfung wurde durchgeführt von Herrn König, Mitarbeiter des Informatikzentrums der
Sparkassenorganisation GmbH (SIZ), Bonn.
1.9 Projektverlauf
Abnahmetests durch Externe, beginnend mit Reuters RET-AD, Client-Applet
Version 3.3 SP 3, erfolgten im April 2008 durch die HSH Nordbank.
Im Rahmen der in diesem Dokument beschriebenen Prüfungsmaßnahmen hat
das SIZ am 11. Januar 2008 den generellen Prüfauftrag erhalten (siehe [IDW
EPS 460nF, Tz14ff]).
Vorbereitend für den Auftraggeber der Prüfung hat am 12. und 13. Februar 2008
ein Workshop beim Hersteller mit folgenden Beteiligten stattgefunden:
- Thomas Kerstan, (Reuters: Head of Professional Services Group)
- Jürgen Steinebach (Reuters: Manager Central Service, Datenschutzbeauftragter, Market Data Solutions) / zeitweise
- Hr. Keckes (Reuters: Schulungen) / zeitweise
- Hr. Ulyi Ugur (Reuters)
- Claudia Nefflen (Reuters) / zeitweise
- Bernhard König (SIZ).
Die erste Prüfungsphase durch das SIZ wurde durch den Auftrageber durch die
Bereitstellung der prüfungsrelevanten Unterlagen (siehe Abschnitt 3 Literaturverzeichnis (inkl. Angaben zum geprüften Projekt)) am 7. März 2008 begonnen. Diese Phase wurde nach interner Qualitätssicherung (siehe Historie dieses Dokumentes) durch eine am 9. April 2008 dem Auftraggeber übergebene Befundliste
abgeschlossen.
In Absprache zwischen Auftraggeber und SIZ wurde nach Nachlieferung weiterer
Dokumente am Anfang Mai 2008 beschlossen, den aktuellen Stand im Testat
festzuhalten, dieses wurde nach interner Qualitätssicherung auch mit dem Auftrageber abgestimmt und zu Mitte Juni dem Auftraggeber übergeben.
2 Details zur Risikoklassifizierung
Die folgende Tabelle benennt Unternehmensinteressen und verweist auf jeweils die spezifischen Risiken, durch die dieses Interesse gefährdet wird. Auf die Details wird dann in den
folgenden Abschnitten eingegangen.
Seite: 8
Stand: 10.07.08
INFORMATIKZENTRUM
Unternehmensinteresse7
Gefährdendes Risiko und Verweis auf konkrete Ausprägungen8
Integrität
Die Integrität der übertragenen Daten ist Voraussetzung für die Vertragsrechtliche Akzeptanz der mit RET-AD getätigten Transaktionen.
Details werden im Abschnitt Einhaltung gesetzlicher oder bankaufsichtsrechtlicher Vorschriften beschrieben.
Verfügbarkeit
Die Verfügbarkeit einer Handelsplattform, hier RET-AD stellt für die
einsetzende Sparkasse eine hohe Priorität dar. Details siehe Abschnitte
Wirtschaftliche Auswirkungen & Auswirkungen auf Entscheidungen und
Auswirkungen auf die Kundenbeziehung.
Compliance /
Einhaltung
rechtlicher Erfordernisse
Die rechtliche Korrektheit der mit der Handelsplattform RET-AD initiierten Transaktionen stellt für die einsetzende Sparkasse eine hohe Priorität dar. Details siehe Abschnitt Einhaltung gesetzlicher oder bankaufsichtsrechtlicher Vorschriften.
Die Risikoklassifizierung in hoch, gering bzw. nicht vorhanden9 für die gesamte Anwendung
ergibt sich aus dem Maximum der potenziellen Auswirkungen der einzelnen Risikokategorien, die in den folgenden fünf Abschnitten detaillierter beschrieben werden. Es müssen alle
fünf Abschnitte berücksichtigt werden [28, 9]. Das SIZ kommt nach derzeitiger Betrachtung
zu folgendem Ergebnis, wobei hier explizit darauf hingewiesen wird, dass eine Sparkasse
davon abweichen kann:
RET-AD, Client Applet stellt nach der in diesem Dokument beschriebenen Risikobeurteilung eine ITAnwendung mit hohem Risiko dar und entspricht
dabei den Vorgaben der Risikostufe A der OPDVStellungnahme Nr. 1/2006.
2.1 Wirtschaftliche Auswirkungen & Auswirkungen auf Entscheidungen
Die IT-Anwendung unterliegt folgenden Beurteilungskriterien zu wirtschaftlichen Auswirkungen:
Wirtschaftliche Auswirkungen durch Verwendung der Anwendung RET-AD,
Client-Applet sind signifikant gegeben, da mit dieser Anwendung u. a. Kosten für
die Sparkasse verursacht werden, wenn über die Anwendung die Durchführung
von Devisen und Geldmarkt Geschäften abgewickelt wird. Da die Anwendung ihrerseits ein mehrstufiges Handelslimit und damit eine Begrenzung dieses Risikos
7
Unternehmensinteressen sind im „COBIT-Würfel“ [COBIT4.0, S.26] :, [COBIT4.1, S.25]:als Unternehmensanforderung beschrieben.
8
Entsprechend [GAIT, Prinzip1] muss die übergeordnete Analyse von Risiken durchgeführt werden,
bevor die in den Unterabschnitten im Rahmen der Analyse auszufüllenden Listen potenzieller Risiken
bearbeitet werden.
9
[OPDV 1/2006, Anlage1] definiert folgende drei Risikostufen:
hoch wird mit Risikostufe A bezeichnet und bedingt ein vollumfängliches Programm- und Einsatzfreigabeverfahren,
gering wird mit Risikostufe B bezeichnet und bedingt ein vereinfachtes Freigabeverfahren und bei
nicht vorhanden, auch als Risikostufe C bezeichnet, beschränkt sich das Programmeinsatzfreigabeverfahren auf die Risikobeurteilung.
Seite: 9
Stand: 10.07.08
INFORMATIKZENTRUM
unterstützt, stellt dieses Risiko nicht automatisch eine Einstufung in die höchste
Risikostufe (Risikokategorie A nach OPDV Stellungnahme Nr. 1/2006) dar. Eine
feste Zuordnung in die niedrigste Kategorie kann ebenfalls nicht allgemein angenommen werden.
Andere wirtschaftliche Auswirkungen oder Auswirkungen auf geschäftspolitische
Entscheidungen werden nicht gesehen. Insgesamt werden dabei die wirtschaftlichen
Auswirkungen durch die IT-Anwendung vom SIZ als vorhanden bewertet.
2.2 Auswirkungen auf die Kundenbeziehung
Die IT-Anwendung unterliegt folgenden Beurteilungskriterien zu Auswirkungen auf die Kundenbeziehung:
RET-AD kann als Handelsplattform, mit der Devisen und Geldmarkt Geschäfte
durchgeführt werden auch eine Auswirkung auf die Kundenbeziehung haben. Das
primäre Interesse dieser Beziehung ist aber eine vertragstechnisch korrekte Abwicklung der Transaktionen. Dieses Thema wird im Abschnitt Einhaltung gesetzlicher oder bankaufsichtsrechtlicher Vorschriften behandelt.
Auswirkungen auf die Kundenbeziehung werden daher nicht gesehen, da die Informationen
nur Institutsintern vorgelegt, nicht aber Richtung Sparkassenkunden kommuniziert werden.
2.3 Auswirkungen auf das Sicherheitsniveau
Die IT-Anwendung unterliegt folgenden Beurteilungskriterien zu Auswirkungen auf das Sicherheitsniveau:
Reuters RET-AD, Client-Applet wird ggf. täglich benötigt [IIR2, 20 Datenverarbeitungsrisiken: Verfügbarkeit] . Die zum Produkt gehörenden Handbücher liefern
hierzu für sich allein keine ausreichende Information.
Das einsetzende Institut ist auf eine eigene Sicherstellung der durch die ITAnwendung unterstützten Geschäftsprozesse angewiesen. Diese Sicherstellung
durch das anwendende Institut erscheint dem SIZ als durchführbar.
Zur Sicherstellung der erforderlichen Integrität der Informationen ist eine ausreichende Funktionstrennung (Segregation of Duties) in der Bedienung der ITAnwendung erforderlich. Für das das Client-Applet einsetzende Institut müssen
organisatorische Prozesse die ggf. erforderlichen Funktionstrennungen erwirken
und prüfen. Hierbei ist die Mitarbeit des Anwendungsbetreibers zwingend erforderlich.
Nach [GAIT, Prinzip3] stellt die IT-Anwendung auf folgenden Ebenen ein Risiko
dar:
1) Das eigentliche Applikationsprogramm:
Da die Anwendung als Java-Applet in einer sogenannten Sandbox ausgeführt
wird, die theoretisch keine Zugriffe des Programms auf seine Umgebung zulässt
hängt die Sicherheit primär von der Sicherheit der eingesetzten Ablaufumgebung
und damit des Web-Browsers und seiner Java-Anbindung ab. Es bleibt zu empfehlen, entsprechende Sicherheitswarnungen hier entsprechend zu beachten.
Das zu RET-AD gelieferte Handbuch enthält keine diesbezüglichen Sicherheitshinweise.
2) Die verwendeten Datenbanken bzw. Datenspeicher liegen ausschließlich beim
Anwendungsbetreiber. Eine ausreichende Sicherheit muss hier durch entsprechende vertragliche Vereinbarungen hergestellt werden.
Seite: 10
Stand: 10.07.08
INFORMATIKZENTRUM
3) Das Betriebssystem (siehe 1).
4) Sämtliche Datenübertragungsmechanismen (network) müssen vom Betreiber
des Datennetzes abgesichert werden.
Aus den Gefährdungskatalogen des BSI [GS-KAT] kommen folgende weitere Gefährdungen in Betracht:
o
Aus dem Gefährdungskatalog Organisatorische Mängel:
G 2.1 Fehlende oder unzureichende Regelungen,
G 2.2 Unzureichende Kenntnis über Regelungen,
G 2.4 Unzureichende Kontrolle der IT-Sicherheitsmaßnahmen,
Sowie das Thema Service-Level-Vereinbarung mit dem Betreiber und
alle in diesem Zusammenhang relevanten Aspekte.
Andere Auswirkungen auf das Sicherheitsniveau werden nicht gesehen. Insgesamt werden
dabei diese Auswirkungen durch die IT-Anwendung vom SIZ als zwar vorhanden aber im
Rahmen des Vertragsmanagements mit dem Dienstleister zu behandlen bewertet.
2.4 Einhaltung gesetzlicher oder bankaufsichtsrechtlicher Vorschriften
Die IT-Anwendung unterliegt folgenden Beurteilungskriterien zu Auswirkungen auf die Einhaltung von gesetzlichen und sonstigen relevanten Vorschriften:
RET-AD unterliegt als Bestandteil einer Handelsplattform dem Vertrags- und
Handelsrecht. BGB und HGB sind somit zwingend umzusetzen. In wie weit Verordnungen zu Auslandsgeschäften ebenfalls durch die Durchführung von Devisen- oder Geldmarkt Geschäften ausländischer Börsen betroffen sind, muss
durch das einsetzende Institut geklärt werden.
Reuters RET-AD, Client-Applet hat folgende Auswirkungen auf das interne Kontrollsystems (IKS):
Kontrollprozesse der mit RET-AD, Client-Applet durchgeführten Transaktionen
müssen manuell durchgeführt werden.
Andere Auswirkungen auf gesetzliche oder andere relavente Vorgaben werden nicht
gesehen. Insgesamt werden dabei diese Auswirkungen durch die IT-Anwendung vom SIZ
als signifikant vorhanden bewertet. Zu welcher Risikoeinstufung dabei das einsetzende
Institut gelang, hängt ggf. auch von bereits für diese Transaktionen vorhandenen
Kontrollmechanismen ab.
2.5 Datenüberstellung in autorisierte Programme
Die IT-Anwendung liefert Daten an folgende autorisierte Programme aus:
Die Überstellung von Transaktionsdaten in die Systeme des einsetzenden Institutes geschieht potenziell über Schnittstellen zwischen RET-AD-Server und Institut,
diese Schnittstelle wurde im Rahmen des hier vorliegenden Testates nicht betrachtet, ein Beleg für eine korrekte Übergabe konnte nicht identifiziert werden.
Andere Datenübergaben in bereits bestehende Programme bestehen vermutlich nicht. Die
oben angesprochene Schnittstelle zur Übergabe der Transaktionsdaten -sofern überhaupt
automatisiert möglich- kann nicht bewertet werden.
Seite: 11
Stand: 10.07.08
INFORMATIKZENTRUM
3 Literaturverzeichnis (inkl. Angaben zum geprüften Projekt)
Im Testierungsprojekt wurden u. a. folgende Artefakte10 vollständig berücksichtigt, im Dokument selbst werden weitere Referenzen durch eckige Klammern gekennzeichnet und dabei
jeweils die verständliche Kurzbezeichnung des Dokumentes angegeben, z. B. [HGB, §238]:
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
Anforderungen der SI vom 22.3.2006 an eine IT-Anwendung
Arbeitshilfe für die Beurteilung von Qualitätseigenschaften bei Fremdsoftware
(Erstveröffentlichung: Fachmitteilungen Nr. 7 vom 31. 3. 1999 durch den Fachausschuss OPDV, Anm. d. Red.)
DIN ISO/IEC 12119 „Software-Erzeugnisse, Qualitätsanforderungen und Prüfbestimmungen"
Grundsätze ordnungsgemäßer DV-gestützter Buchführungssysteme (GoBS) Schreiben des Bundesministeriums der Finanzen an die obersten Finanzbehörden der
Länder vom 7. November 1995, veröffentlicht im BStBl. 1995, Teil I, S.738ff.
BMF-Schreiben vom 7. November 1995 zu den GoBS
FAMA 1/1987
Verlautbarung OPDV 1991
TÜViT im Rahmen der Überarbeitung der Checkliste für das Projekt TRAVIC Jan 2005
„Arbeitsanweisung DV09 Softwareeinsatz und Anwendungsentwicklung V01 vom
15.1.2004“ der Stadtsparkasse Augsburg
„Schutzbedarfsfeststellung für IT-Anwendungen“ der Stadtsparkasse Wuppertal (Sp
860 033…) einschließlich dazugehörender Beispielfragen
Definierte Einsatzbedingungen von der Konzernrevision der Deutschen Sparkassen
Leasing AG & Co. KG
„UHB-Sicherheitsmanagement-> IT-Sicherheitsmanagement-> Arbeitsanweisung –
Freigabe von Anwendungen“ der Sparkasse Nürnberg
WS IT-Revision Kiel vom 10.5.2004 der Sparkassenakademie Schleswig-Holstein
Datenbanktitel: Handbuch DV-Prüfung/IR (vom FA OPDV, Anm. d. Red.)
Datenbankname:
HB-DVPK.NSF
Freigabedatum: Freigabe mit Stand 10/99 erfolgte am 11.10.99
Bundesdatenschutzgesetz (BDSG) vom 20. Dezember 1990 (BGBl. I S. 2954), neu
gefasst durch Bekanntmachung vom 14. Januar 2003 (BGBl. I S. 66), geändert durch §
13 Abs. 1 des Gesetzes vom 5. September 2005 (BGBl. I S.2722) sowie durch Artikel 1
des Gesetzes vom 22. August 2006 (BGBl. I S. 1970) Aktualisierte, nicht amtliche Fassung Stand: 26.08.2006
AE-Modell des SIZ
Fachausschuss Ordnungsmäßigkeit und Prüfung der Datenverarbeitung (OPDV); Stellungnahme Nr. 1/2006; Anforderungen an einen ordnungsgemäßen Programmeinsatz;
Stand Juli 2006
BITKOM Publikation „Compliance in IT-Outsourcing-Projekten - LEITFADEN zur Umsetzung rechtlicher Rahmenbedingungen“ (siehe )
10
Berücksichtigte Artefakte (SW-Teile und Dokumente) werden in den Testierungsdokumenten mit
abkürzender Notation der Quelle hier mit [<lit-nr>] bezeichnet, wenn dieses Artefakt im Literaturverzeichnis auftaucht. Konkrete Inhalte innerhalb dieser Quelle werden dabei möglichst auch detaillierter
angegeben:
[<lit-nr>, <Abschnitt>] Der Abschnitt kann dabei auch aus der Abschnittsnummer gebildet werden
[<lit-nr>, S.<Seitennummer>] Als Seitenangabe im Dokument
[<lit-nr>, XYZ] wenn XYZ in der speziellen Dokumentenform eine Stelle eindeutig kennzeichnet, bei
Tabellenkalkulationsprogrammen z. B. die Zellennummern.
Für allgemein bekannte Literaturhinweise wird statt der numerischen Angabe auch die abkürzende
Bezeichnung im Text verwendet, auch wenn dieses Schriftstück nicht im Literaturverzeichnis auftaucht.
Seite: 12
Stand: 10.07.08
INFORMATIKZENTRUM
[19] [= FAIT1] IDW-Stellungnahme zur Rechnungslegung: Grundsätze ordnungsmäßiger
Buchführung bei Einsatz von Informationstechnologie (IDW RS FAIT 1); (Stand:
24.09.2002): Verabschiedet vom Hauptfachausschuss (HFA) am 24.09.2002
[20] [= IIR2] Deutsches Institut für Interne Revision (IIR) - IIR Revisionsstandard Nr. 2 - Prüfung des Risikomanagements durch die Interne Revision
[21] [= FAIT2] Entwurf IDW-Stellungnahme zur Rechnungslegung: Grundsätze ordnungsmäßiger Buchführung bei Einsatz von Electronic Commerce (IDW ERS FAIT 2) (Stand:
01.07.2002)
[22] [= GPSG] Gesetz über technische Arbeitsmittel und Verbraucherprodukte (Geräte- und
Produktsicherheitsgesetz - GPSG) GPSG - Ausfertigungsdatum: 06.01.2004
[23] [= COBIT4.0] COBIT 4.0, deutsche Ausgabe der KPMG in der Version vom 14.5.2007
[24] [= COBIT4.1] COBIT 4.1, IT Governance Institute - 3701 Algonquin Road, Suite 1010 Rolling Meadows, IL 60008 USA - Phone: +1.847.590.7491 - Fax: +1.847.253.1443 E-mail: info@itgi.org - Web site: www.itgi.org, Ausgabe 2007
[25] [=SITB] Sicherer IT-Betrieb, Version 4.1 vom 3.11.2005; Herausgeber SIZ
[26] IT-Revision, Schriftlicher Lehrgang in 10 Lektionen, Management Circle Edition, 1. Auflage (2007)
[27] Fachtagung IT-Revision: Impulse für die tägliche Arbeit, Sparkassenakademie Bonn
30.10.07
[28] ( Datei: Z:\PG-Architektur_und_QS\IT-Testierung\# Interna\60 Externe Veranstaltungen\070615 SVN Sparkassenprüfung und Programmfreigabe\SVNSoftwarebeschaffung.PDF )
SVN Prüfungsstellen, Checkliste für IT-Prüfungen, CL Softwarebeschaffung.doc
[29] BaFin Rundschreiben vom 30.10.2007, Rundschreiben 5/2007 (BA), Mindestanforderungen an das Risikomanagement (MaRisk)
[30] BSI: Verantwortlichkeiten von IT-Herstellern, Nutzern und Intermediären – Studie im
Auftrag des BSI durchgeführt von Prof. Dr. Gerald Spindler, Universität Göttingen
[31] [=DGCK] Deutscher Corporate Governance Kodex (in der Fassung vom 14. Juni 2007)
der Regierungskommission Deutscher Corporate Governance Kodex
[32] [=GAIT] “The GAIT Principles” (Stand 2. Jan. 2007) und “The GAIT Methodology”
(Stand Jan. 2007)
[33] [=GS-KAT] IT-Grundschutz-Kataloge, deutsch: Stand 2006 - 8. Ergänzungslieferung
[34] [=IDW EPS 850] Entwurf IDW Prüfungsstandard: Projektbegleitende Prüfung bei Einsatz von Informationstechnologie (IDW EPS 850) (Stand: 19.09.2007)
[35] [=HGrG] Gesetz über die Grundsätze des Haushaltsrechts des Bundes und der Länder
(Haushaltsgrundsätzegesetz - HGrG) zuletzt geändert 31. Oktober 2006
[36] [=ISACA] der Berufsverband der EDV-Revisoren und IT-Sicherheitsmanager, ISACA
Germany Chapter e. V., Eichenstrasse 7, 46535 Dinslaken hat als Berufsverband der
IT-Revisoren und IT-Sicherheitsmanager Berufsstandards herausgegeben
(http://www.isaca.de/grundlagen_standards_dl.php ):
[ISACA-S1] = IS AUDITING STANDARD „AUDIT-CHARTA“,
[ISACA-S2] = „UNABHÄNGIGKEIT“,
[ISACA-S3] = „BERUFSETHIK UND STANDARDS“,
[ISACA-S4] = „FACHKOMPETENZ“,
[ISACA-S5] = „PLANUNG“,
[ISACA-S6] = „AUSFÜHRUNG DER REVISIONSARBEITEN“,
[ISACA-S7] = „BERICHTERSTATTUNG“,
[ISACA-S8] = „NACHSCHAU“,
[ISACA-R] = „IS Verfahren zur Risikobewertung“ und
[ISACA-B] = „#060.020.092: Internet Banking“
[100] OPDV_Document_List.txt: Übersicht über die zur Testierung bereitgestellten Dokumente
[101] Reuters/Reuters_BusinessContinuity.pdf: Business Continuity - Client Statement
Seite: 13
Stand: 10.07.08
INFORMATIKZENTRUM
[102] Reuters/Reuters_ISMS_Certificate_Statement.pdf: Reuters and ISO 27001 - Raising
the information security bar von 2007
[103] Reuters/Reuters_ISO_27001.pdf: Certificat of Registration
[104] Reuters/Reuters_ISO_9001.pdf: Certificat of Registration, gültig bis 1. April 2009
[105] Reuters/Reuters_ISO_Statement_V3.pdf: Reuters ISO Statement von 2007
[106] Reuters/Reuters_InformationSecurity.pdf: Reuters Information Security von 2006
[107] Reuters/Reuters_InformationSecurity_Statement.pdf: Reuters Information Security von
2003
[108] Reuters/Reuters_StatementofService_Germany_V_5.pdf: Statement of Service - Providing Support Services for the Information Business beschreibt u. a. den von Reuters
angebotenen Support
[109] RET-AD/Hosted_Service/RET-AD_Hosted-Service-Standard-Configuration.pdf:
Reuters ADT User Documentation - RET-AD Hosted Service Standard Configuration Document Version 1.1 (von 2004)
[110] RET-AD/Hosted_Service/RET-AD_ASP-Change-Control Document.pdf: Reuters ADT
User Documentation – ASP Change Management Procedures - Document Version 2.4
(vom 19. Februar 2004).
[111] RET-AD/Hosted_Service/RET-AD_Guidelines-for-Hosted-Service.pdf: Reuters ADT
User Documentation – Guidelines for RET-AD Hosted Service - Document Version
2.94 (vom 17. Mai 2005).
[112] RET-AD/Hosted_Service/RET-AD_Hosted-Service-Flier.pdf: Reuters Electronic Trading Hosted Service - A managed service that accelerates time to market and reduces
technical overheads von 2005
[113] RET-AD/Hosted_Service/RET-AD_Hosted-Service-Security-Questions.pdf: Reuters
Electronic Trading Hosted Service – Hosted Service Security vom 12. März 2004
[114] RET-AD/Hosted_Service/RET-AD_Hosted-Services-Implementation-RequestForm.doc
[115] RET-AD/Application_Guides/RET-AD_Working-with-Modifiers.pdf: RET-AD3.3 Working
with Modifiers, Dokumentversion 15.1 vom 31. März 2006
[116] RET-AD/Application_Guides/RET-AD_3.3-Trader-Guide.pdf: RET-AD 3.3 SP2 Trader
Applet User Guide vom 7. August 2007
[117] RET-AD/Application_Guides/RET-AD_3.3-Administration-Guide.pdf: RET-AD 3.3 SP3
Administration Guide vom 25. Juni 2007
[118] RET-AD/Application_Guides/RET-AD_Client-QuickStartGuide.pdf: Electronic Trading
Automated Dealing Client
[119] RET-AD/Application_Guides/RET-AD_3.3-Client-Guide.pdf: RET-AD 3.2 SP2 Client
User Guide vom 18. Januar 2007
[120] RET-AD/Application_Guides/RET-AD_Working-with-Filters.pdf: Reuters TGST User
Documentation RET-AD 3.3 – Working with Filters, Document Version No: 20.1 vom
31.März 2006
[121] RET-AD/Product/RET-AD_Applet-Branding-Guide.pdf: RET-AD 3.3 SP1; Applet Branding Guide, Document Version 8.3 vom 23. Januar 2007
[122] RET-AD/Product/RET-AD_Product-Flier.pdf mit Copyright von 2005
[123] RET-AD/Product/RET-AD_3.3-Release-Notes-Version.pdf: RET-AD 3.3, Service Pack
3 Release Notes, Document Version 1.2 vom 11. Dezember 2007
[124] RET-AD/Product/RET-AD_Supported-Environments.pdf, Document Version 23.6 vom
31. Juli 2007
[125] RET-AD/Solution_Architecture/RET-AD_Hosted-Service-Architecture.pdf: Reuters ADT
Global Task Team, RET-AD Hosted Service Architecture, Dokumentversion 1.4 vom
11. August 2004
[126] RET-AD/Solution_Architecture/RET-AD_TRM-User-Guide.pdf: RET-AD 3.3: TRM User
and Administration Guide, Dokumentversion 1.2 vom 12. April 2006
[127] RET-AD/Solution_Architecture/RET-AD_SCS-In-Depth.pdf: Reuter Electronic Trading,
SCS In Depth, Dokumentversion 28.0 vom 6. September 2007
Seite: 14
Stand: 10.07.08
INFORMATIKZENTRUM
[128] QA_Process/Reuters_3000Xtra_5.1_QualityPlan.doc: QA & Third level support, White
Paper 1 – Test Strategy, Version 1.1 vom 17. Juni 2004
[129] HSH/Vereinbarung HSHN-Trader.doc: Vereinbarung über die Abwicklung von Transaktionen über das System HSH NORDBANK TRADER, Dokumentvorlage vom 3.12.2007
[130] Coding\SPI_CPP_CODING_STD.pdf: REUTERS THAILAND TECHNICAL
DEVELOPMENT, CODING STANDARD FOR C/C++, Version 1.0 vom 5. August 1999
[131] Coding\SPI_SPE_IMPL_GL.pdf: REUTERS SOFTWARE (THAILAND) LIMITED,
IMPLEMENTATION PHASE PROCESS GUIDELINE, in Version 2.0 vom 4. März 2004
[132] Coding\SPI_VB_CODING_STD.pdf: REUTERS THAILAND TECHNICAL
DEVELOPMENT, CODING STANDARD FOR VISUAL BASIC, Version 1.0 vom 5. August 1999
[133] Design\SPI_SPE_ADS_DT.pdf: Dokumentvorlage für: REUTERS SOFTWARE
(THAILAND) LIMITED <PROJECT NAME>, ARCHITECTURE DESIGN
SPECIFICATION
[134] Design\SPI_SPE_DDS_DT.pdf: Dokumentvorlage Version 4.0 vom 25. Januar 2008 zu
REUTERS SOFTWARE (THAILAND) LIMITED <PROJECT NAME> <MODULE
NAME> DETAILED DESIGN SPECIFICATION
[135] Design\SPI_SPE_DESIGN_GL.pdf: REUTERS SOFTWARE (THAILAND) LIMITED,
DESIGN PROCESS GUIDELINE, Version 4.0 vom 4.März 2004
[136] PeerReview\CodeReview.pdf: General Peer Review Quick Reference, Mai 2007
[137] PeerReview\SPI_Code_Review_CL.pdf: Code Review Checklist, V 1.0 – 20 Feb 2001
[138] PeerReview\SPI_PRTOOL_UM.pdf: REUTERS SOFTWARE (THAILAND) LIMITED,
RSTL GENERAL TOOLS PROJECT, PR TOOL&TEMPLATE USER MANUAL, Version
3.0 vom 8. Oktober 2007
[139] PeerReview\SPI_PR_GL.pdf: REUTERS SOFTWARE (THAILAND) LIMITED, PEER
REVIEW GUIDELINE, Version 6.0 vom 19. Dezember 2005
[140] PeerReview\SPI_SPI_RCC.pdf: RSTL Root Cause Categories for Defect Analysis v
3.0 – Issued 13 Jan 2006
[141] QA_Process\Debriefing Process Best Practice_05.pdf: Debriefing Process Best Practice, Updated date : 9 Feb 2006
[142] QA_Process\Defect_Severity_Definition.xls
[143] QA_Process\ELS204L2OSQT3_STR100.xls: Testprotokoll des Enterprise Licensing
System vom 31. Oktober 2005
[144] QA_Process\SPI_SPE_TEST_GL.pdf: REUTERS SOFTWARE (THAILAND) LIMITED,
TESTING PROCESS GUIDELINE, Version 8.0 vom 6. Dezember 2006
[145] QA_Process\SPI_SPE_TS_DT.pdf: Dokumentvorlage Version 3.0 vom 8. August 2005:
REUTERS SOFTWARE (THAILAND) LIMITED, <PROJECT NAME> <TEST LEVEL>
TEST SPECIFICATION
[146] QA_Process\SPI_SPE_UTD_DT.xls
[147] QA_Process\SPI_SPE_UT_GL.pdf: REUTERS SOFTWARE (THAILAND) LIMITED,
UNIT TESTING PROCESS GUIDELINE, Version 1.0 vom 9. April 2007
[148] QA_Process\SPI_SQA_GL.pdf: REUTERS SOFTWARE (THAILAND) LIMITED,
SOFTWARE QUALITY ASSURANCE GUIDELINE, Version 5.0 vom 14. März 2007
[149] QA_Process\SPI_TestProcess_CL.pdf: RSTL Test Process Checklist V1.00 (Updated:
15 August 2007)
[150] QA_Process\SQA_Check_Maintain_Procedure_04.xls
[151] RequirementsManagement\SPI_RM_CAT_DT.xls
[152] RequirementsManagement\SPI_RM_GL.pdf: REUTERS SOFTWARE (THAILAND)
LIMITED, REQUIREMENT MANAGEMENT GUIDELINE, Version 4.0 vom 4. März
2004
[153] RequirementsManagement\SPI_RM_PFS_DT.pdf: Dokumentvorlage Version 1.0 vom
25. August 2000: REUTERS SOFTWARE (THAILAND) LIMITED, <PROJECT NAME>,
PROJECT FUNCTIONAL SPECIFICATION
Seite: 15
Stand: 10.07.08
INFORMATIKZENTRUM
[154] RequirementsManagement\SPI_RM_RA_PRO.pdf: REUTERS SOFTWARE
(THAILAND) LIMITED, REQUIREMENT ANALYSIS PROCEDURE, Version 1.0 vom
20. Februar 2001
[155] RequirementsManagement\SPI_RM_TRACE_GL.pdf: REUTERS SOFTWARE
(THAILAND) LIMITED, REQUIREMENT TRACEABILITY GUIDELINE, Version 2.0 vom
14. März 2003
[156] Testfall_01.01_001_Autotrade Spot_1.xls in einer mehrfach überarbeiteten Version der
HSH Nordbank
[157] HSH Nordbank Testfall_01.01_001 Überprüfung des automatischen Trading, Datei
01.pdf
HSH Nordbank Testfall_01.01_002 Eingabe eines EUR/CHF Spotgeschäftes über 5
Mio. EUR, Datei 02.pdf
HSH Nordbank Testfall_01.01_003 Eingabe eines EUR/JPY Outrightgeschäftes über
3,3 Mio. EUR bei 1W, Datei 03.pdf
HSH Nordbank Testfall_01.01_004 Eingabe eines EUR/JPY Outrightgeschäftes über
4,2 Mio. EUR bei 1M, Datei 04.pdf
HSH Nordbank Testfall_01.01_004 (TF05) Eingabe eines EUR/ZAR Geschäftes bei
6M, Datei 05.pdf
HSH Nordbank Testfall_01.01_006 Eingabe eines EUR/USD Swapgeschäftes bei 6M,
Datei 06.pdf
HSH Nordbank Testfall_01.01_007 Eingabe eines USD/NOK Swapgeschäftes bei 6M Broken, Datei 07.pdf
HSH Nordbank Testfall_01.01_008 Eingabe eines GBP/USD Spotgeschäftes, Datei
08.pdf
HSH Nordbank Testfall_01.01_009 Eingabe eines EUR/USD Outrightgeschäftes über
3 Mio. EUR bei 13M, Datei 09.pdf
HSH Nordbank Testfall_01.01_010 Eingabe eines USD/ZAR Swapgeschäftes über 15
Mio. USD mit Dealerintervention, Datei 10.pdf
HSH Nordbank Testfall_01.01_011 Eingabe eines USD/CHF Swapgeschäftes über 6.6
Mio. CHF, Datei 11.pdf
HSH Nordbank Testfall_01.01_012 Eingabe eines EUR/JPY Spotgeschäftes über 3
Mio. mit deny-spot, Datei 12.pdf
HSH Nordbank Testfall_01.01_013 Eingabe eines USD/THB Spotgeschäftes mit denycurrency, Datei 13.pdf
HSH Nordbank Testfall_01.01_014 Eingabe eines EUR/USD Blockgeschäftes 1+2+3
Monate, Datei 14.pdf
HSH Nordbank Testfall_02.01_001 Eingabe eines EUR/deposit MM-AutoTradingGeschäftes, Datei 15.pdf
HSH Nordbank Testfall_02.01_002 Eingabe eines USD/deposit MM-AutoTradingGeschäftes 1W, Datei 16.pdf
HSH Nordbank Testfall_02.01_003 Eingabe eines GBP/deposit MM-AutoTradingGeschäftes 1W Dealer-Intervention, Datei 17.pdf
HSH Nordbank Testfall_02.01_004 Eingabe eines EUR/deposit MM-AutoTradingGeschäftes 15 Monate mit Dealer-Intervention, Datei 18.pdf
HSH Nordbank Testfall_02.01_005 Eingabe eines EUR/deposit MM-AutoTradingGeschäftes Today mit Dealer-Close, Datei 19.pdf
HSH Nordbank Testfall_02.01_006 Eingabe eines EUR/deposit MM-AutoTradingGeschäftes 26 Monate mit Deal-Deny, Datei 20.pdf
HSH Nordbank Testfall_02.01_007 Eingabe eines USD/deposit MM-AutoTradingGeschäftes Manuell und deny, Datei 21.pdf
HSH Nordbank Testfall_02.01_008 Eingabe eines MM Rollover in EUR, Datei 22.pdf
HSH Nordbank Testfall_02.01_009 Eingabe 1M Blocktrade MM deny, Datei 23.pdf
HSH Nordbank Testfall_02.01_010 Eingabe 17T MM und broken date, Datei 24.pdf
HSH Nordbank Testfall_02.01_011 Eingabe MM mit Betragserweiterung, Datei 25.pdf
HSH Nordbank Testfall_02.01_012 Eingabe Interest capitalisation, Datei 26.pdf
Seite: 16
Stand: 10.07.08
INFORMATIKZENTRUM
HSH Nordbank Testfall_02.01_013 Eingabe Rollover trade mit Betragsänderung und
deny, Datei 27.pdf
4 Zusammenfassende Bewertung der IT-Anwendung aus Sicht der
Stellungnahmen
Aus Sicht der Projektverantwortung wird vom SIZ festgestellt, dass für thailändische Unternehmensteile der Reuters AG dokumentierte Software-Bereitstellungsprozesse bestehen.
Mit [104] liegt auch ein auf Reuters Limited ausgestelltes ISO 9001-Zertifikat vor. Inwieweit
sich hieraus ableiten lässt, dass damit auch das Einhalten der thailändischen Bereitstellungsprozesse verbunden ist, möchte das SIZ nicht bewerten. Auf der einen Seite muss unabhängig davon festgestellt werden, dass international operierende Organisationen ohne
dokumentierte Prozesse insbesondere an den Schnittstellen auf Grund der daraus resultierenden direkten Probleme unwahrscheinlich sind und insofern kein Grund vorliegt, die Korrektheit der dokumentierten Prozesse zu bezweifeln, auf der anderen Seite muss aber festgestellt werden, dass die von der Reuters AG vorgelegten Prozessdokumentationen nur als
sehr marginal anzusehen sind und insofern nur allergrößte Probleme abfedern können. Details finden sich im Abschnitt 5 Detailbewertung der Bereitstellungs- und Wartungsprozesse.
Mit [103] wurde ein auf Reuters Limited ausgestelltes ISO27001-Zertifikat vorgelegt.
Aus Sicht der Benutzer/Fachbereiche finden sich Detailaussagen im Abschnitt 6 Detailbewertung aus Sicht der Benutzer bzw. Fachbereiche hinsichtlich fachlicher Aspekte und im
Abschnitt 5.2 Nachweis einer vollumfänglichen Qualitätssicherung hinsichtlich der Testnachweise. Eine zusammenfassende Bewertung findet sich am Ende des vorliegenden Abschnittes.
Aus Sicht der Produktion muss für das hier betrachtete RET-AD Client-Applet festgestellt
werden, dass fast sämtliche Maßnahmen zur Betriebsaufnahme als auch zur dessen Aufrechterhaltung durch den Betreiber erbracht werden müssen. Primär ist hierbei also die erfolgreiche Übertragung entsprechender Pflichten auf den Betreiber erforderlich. Hierzu liefert
der Abschnitt 7 Detailbewertung aus Sicht des Betreibers Hilfestellung, die dem SIZ vorgelegte Mustervereinbarung [129] erfüllt für sich allein genommen diese Pflichtenübertragung
jedoch nicht.
Zusammenfassend stehen sich bei der IT-Anwendung RET-AD, Client-Applet die beiden
folgenden Seiten gegenüber:
RET-AD, Client-Applet wird derzeit in der Version 3.3 SP3 angeboten, [156] belegt einen
aktuellen Versionswechselzyklus von maximal nur sehr wenigen Versionen pro Jahr. Die
Anwendung ist also a) aus Anwendersicht als relativ stabil und b) in einer Vielzahl von Ländern und damit auch bei einer signifikanten Anzahl von Anwendern im Einsatz. Dies sähe
anders aus, wenn die Anwendung insgesamt unzuverlässig wäre. Mit dem Hintergrund einer
insgesamt ausreichend geprüften Software muss folgende Festlegung aus der OPDVStellungnahme Nr. 1/2006 (Abschnitt 3.2) zumindest zur Kenntnis genommen werden:
Unter besonderen Umständen können Umfang und Intensität der Qualitätssicherungsmaßnahmen einer Programmfreigabe reduziert werden, ggf. sogar ganz unterbleiben. Dies
kann der Fall sein …
•
bei typischerweise nicht bankfachlicher Standard-Software (z. B. Bürosoftware), wenn
die Funktionsfähigkeit aufgrund der Vertrauenswürdigkeit in die Qualität der Softwareentwicklung der Herstellerfirma unterstellt werden kann, z. B. aufgrund des hohen Verbreitungs- und Bekanntheitsgrads …
Seite: 17
Stand: 10.07.08
INFORMATIKZENTRUM
Auf der anderen Seite finden sich im Detail viele kleinere oder größere Probleme. Insgesamt
geht das SIZ hier davon aus, dass die Kenntnis dieser Probleme und ein ggf. notwendiges Gegensteuern im einsetzenden Institut das tatsächliche Risiko des Einsatzes
dieser Software soweit reduziert, dass ein Einsatz vertretbar wird und eine Programmfreigabe ausgesprochen werden kann.
Mit dieser Gesamtbewertung sind die in den folgenden Kapiteln genannten Einschränkungen
oder Probleme aus Sicht des SIZ nicht als generell Freigabe verhindernd einzustufen. Eine
Dokumentation und Berücksichtigung ist aus Sicht des SIZ trotzdem notwendig, da im Rahmen der an die Programmfreigabe folgenden Einsatzfreigaben durch die einsetzenden Institute einzelnen Risiken jeweils spezifische Reduktionsmaßnahmen zu spezifizieren und umzusetzen sind.
5 Detailbewertung der Bereitstellungs- und Wartungsprozesse (Projektverantwortung)
Das allgemeine Projektmanagement bei der Reuters AG zur Erstellung von Software wurde
durch das SIZ nicht hinterfragt, da das primäre Projektrisiko bis auf Supportaspekte einzig
bei Reuters verbleibt und für die einsetzenden Institute kein weiteres signifikantes Risiko aus
dem Reuters-Projektmanagement resultiert.
Auch wenn das Problem für viele Anwender unrelevant ist, so ist doch in den Supportunterlagen der Reuters AG festgehalten, dass schnell zu lösende Probleme [108, S27, Severity1]
erst dann vorliegen, wenn eine ausreichende Anzahl von Personen von diesem Problem
betroffen ist. Das gleiche Dokument [108, S24] beschreibt aber auch die angebotenen Eskalationsprozesse für nicht schnell genug behobene Probleme, die aus Sicht von anwendenden Finanzinstituten als insgesamt ausreichend und angemessen einzustufen sind.
5.1 Fehlerfreie Herstellung der IT-Anwendung
Die mit [133] und [134] vorgelegten Dokumentvorlagen für das Grob- und Detaildesign von
Software legen den Softwareentwicklungsprozess nur sehr oberflächlich fest. Hierbei treten
aus Erfahrung des SIZ viele Probleme erst später und ggf. auch erst beim Kunden auf, da
eine entsprechende aktive Vermeidung problematischer Situationen nur auf sehr niedrigem
Niveau stattfindet.
5.1.1 Anforderungserfassung (AE)
Es ist sicher auch der im internationalen Umfeld als uneinheitlich einzustufenden Rechtsprechung und Sicherheitseinschätzung zu verdanken, dass in den Unterlagen zu RET-AD,
Client-Applet die Themen juristische Aspekte, sicherheitstechnische Maßnahmen und auch
die organisatorische Einbindung der IT-Anwendung nur minimal behandelt werden. Das SIZ
stuft die hieraus entstehenden Resultate als nicht ausreichend ein, Details und Folgen finden
sich hierzu in anderen Abschnitten.
5.1.2 Architektur und Schnittstellendesign, Geschäftsprozessmodellierung
(GPM)
Die zur Anwendung gehörenden Unterlagen lassen offen, wie die IT-Anwendung RET-AD,
Client-Applet in den Gesamtprozess Beschaffung von Devisen oder anderen Finanzpapieren
integriert werden kann, muss oder soll. Die Feststellung, ob ein institutsspezifisch gewählter
Einbindungsgrad tatsächlich ausreichend ist, muss vom Institut ohne weitere Hilfestellung
durch die Anwendungsdokumentation getroffen werden.
Seite: 18
Stand: 10.07.08
INFORMATIKZENTRUM
5.1.2.1 Schnittstellen und sicherer Datenaustausch
Administrationsarbeiten unterliegen vollständig dem Verantwortungsbereich des ServerBetreibers und damit außerhalb des Einflussgebietes der Anwendung RET-AD, ClientApplet. Die Notwendigkeit entsprechender Maßnahmen kann also nicht komplett abgestritten
werden. Auffällig bleibt hier, dass einige in [109, S5, 2.2.2], [124, S10, 1.2.3.5], [124, S9,
1.2.3.3] und [123, S8, 1.2] genannten Schnittstellen nicht unbedingt mit der am Anfang des
Testates zitierten Architektur gemappt werden können, insofern diese Architekturdarstellung
nur als Auszug zu betrachten ist. Der Server-Betreiber verfügt damit potenziell über weitere
Möglichkeiten, auf den Server und dessen Administration Einfluss zu nehmen. Das die Anwendung RET-AD, Client-Applet einsetzende Institut muss im Rahmen des Vertragsmanagements eine Bewertung der Sicherheit beim Server-Betreiber durchführen.
5.1.3 Einhaltung von Programmierkonventionen
Die vorgelegten Unterlagen können als Hinweis gesehen werden, dass sich Reuters um entsprechende Konventionen bemüht, haben hier aber keinen Nachweischarakter.
5.1.4 Programm- bzw. Systemdokumentation
Die wenigen in der Programmdokumentation aufgefundenen Widersprüche lassen sich am
System überprüfen, können also nicht als gravierend eingestuft werden.
5.1.5 Durchführung und Dokumentation der Entwicklertests
Dokumentierte Entwicklertests wurden nicht belegt.
5.2 Nachweis einer vollumfänglichen Qualitätssicherung
RET-AD, Client-Applet Version 3.3 SP 3 benötigt unter Vollständigkeitsgesichtspunkten formal nur einen Regressionstest. Es enthält 2 ähnlich ablaufende Basisfunktionen, für die
durch einen unabhängigen Dritten –hier die HSH Nordbank– eine korrekte Durchführung
bestätigt wurde [156] und [157]. Die für den Nachweis erforderliche Unabhängigkeit liegt damit vor.
Da für eine institutsspezifische Einsatzfreigabe auch immer die tatsächlich vorliegende Konfiguration maßgeblich ist, die ebenfalls gravierende Einflüsse auf die Funktionsfähigkeit der
IT-Anwendung hat, müssen die zu verwendenden Funktionen auch bei der Einsatzfreigabe
erfolgreich durchlaufen werden können. Mit der Bedingung dieses im Rahmen der Einsatzfreigabe durchzuführenden Tests und unter Berücksichtigung der bisherigen Versionstests
von Vorgängern kann nicht mehr bewiesen werden, dass die Qualitätssicherung unzureichend wäre.
Die von der HSH Nordbank durchgeführten Testfälle [156] und [157] stellen BlackboxFunktionsprüfungen dar, die jeweils unter Verwendung sämtlicher jeweils relevanter Systemkomponenten durch einen Anwender unter Anwendung der IT-Oberfläche durchgeführt wurden.
Die hierbei tatsächlich dokumentierten Tests beschreiben zwar nur das Trader-Applet und
nicht wie eigentlich zu erwarten das Client-Applet. Auf Grund der Gesamtprüfung aller betroffenen Systemkomponenten im Rahmen der hier dokumentierten Tests muss dies aber als
ausreichend eingestuft werden, da die Gesamtprüfung nicht nur auch die Serverkomponenten sondern wahrscheinlich auch die Handelsseite und damit das Client-Applet umfasst hat.
Die Testfälle belegen inhaltlich, dass sowohl Positivtestfälle als auch Negativtestfälle zum
Einsatz kamen. Die konkrete Auswahl von Positiv- und Negativtestfällen wird das SIZ in dieQuelle: IT-Testierungen nach OPDV-Stellungnahme Nr. 1/2006, koenig
Seite: 19
Stand: 10.07.08
INFORMATIKZENTRUM
sem Umfeld nicht bewerten, da die Tests von bankfachlichen Mitarbeitern der HSH Nordbank ausgeführt wurden, bei denen das SIZ von einer entsprechenden Fachkenntnis ausgeht.
Die vorgelegten Testfälle [156] und [157] belegen zwar eine fachliche Prüfung der ITAnwendung, nicht weder weitergehende technische, noch organisatorische oder juristische
Prüfungen. Solche Prüfungen sind aber nur als zwingend anzusehen, wenn entweder neue
Aspekte des aktuellen Releases konkret Eigenschaften aus einer dieser Gruppen ansprechen oder aber eine Neuentwicklung stattgefunden hat. Beides ist für die Version 3.3 SP 3
von RET-AD aber nicht erkennbar. Für einen für diese Folgeversion notwendigen Regressionstest sind diese Spezialprüfungen somit verzichtbar.
5.3 Bereitstellung und Identifikation des Liefergegenstandes sowie seiner
Quellen
5.3.1 Versionsverwaltung und Identifikation
Die Versionsverwaltung und insbesondere deren jeweils zusammengehörige Komponenten
aus Beschreibungen, Handbüchern und tatsächlich verwendeter Softwareversion muss
durch das einsetzende Institut durchgeführt werden. Ein festgelegtes und auch eingehaltenes Format von Versionsbezeichnungen durch den Hersteller ist nicht erkennbar. Am hierzu
erfolgversprechendsten scheint die jeweilige Copyright-Angabe zu sein.
5.3.2 Lieferumfang
5.3.2.1 Produktbeschreibung, Pflichtenheft oder Releasenotes
Die Produktbeschreibung [122] ist aus Sicht DIN ISO/IEC 12119 sowie deren Vorgänger DIN
66285 als unvollständig einzustufen.
5.3.2.2 Systemdokumentation, Programmdokumentation, Softwaredesigndokumente
Dem SIZ wurden im Rahmen der Prüfung Dokumentationen mit allgemeinen Architekturen
und spezifischen Berechnungsdokumentationen vorgelegt. In den allgemeinen Architekturen
sind nicht alle Systemschnittstellen verzeichnet und die Beschreibungen der Berechnungsalgorithmen sind hinsichtlich ihres konkreten Zeitpunktes nicht ausreichend.
Weitere Systemdokumentation zu Schnittstellen und Datenmodell wurde nicht vorgelegt.
Unterlagen zur Supportunterstützung wurden nicht vorgelegt.
5.3.2.3 Installations- und Betriebshandbuch
Für RET-AD, Client-Applet kann keine Notwendigkeit eines Installations- oder Betriebshandbuches gesehen werden.
Seite: 20
Stand: 10.07.08
INFORMATIKZENTRUM
5.3.2.4 Anwenderhandbuch und Hilfestellungen
Sämtliche dem SIZ übergebenen Handbücher zeichnen sich durch eine Mischung von technischen und fachlichen Inhalten aus. Einen fachlichen Anwender fehlen dabei typischer Weise die von den Handbüchern erwarteten technischen Kenntnisse und Berechtigungen und
einen Techniker wird ohne fachliches Wissen auch nicht transparent, welche Aktionen mit
welchem Ziel durchzuführen sind.
5.3.2.5 Testkonzepte, Testprotokolle, Abnahmen und Freigabeerklärungen
Die einzige vorgelegte Abnahme ist eine Funktionsbestätigung durch einen Externen, hier
die HSH Nordbank [156].
6 Detailbewertung aus Sicht der Benutzer bzw. Fachbereiche
6.1 Fachliche Berücksichtigung von gesetzlichen oder normativen Vorgaben
6.1.1 BGB
Das Bürgerliche Gesetzbuch (BGB) beschreibt u. a. das Vertragswesen und damit auch alle
über eine Software abgeschlossenen Vereinbarungen.
Die Unterlagen von RET-AD, Client-Applet haben mindestens folgende beiden Probleme mit
dem BGB:
a) nach deutscher Rechtsprechung (LG München vom 10.07.1985: Aktenzeichen 7U
1501/85) gehört zur Vertragserfüllung bei einer in Deutschland ausgelieferten Software auch
ein deutsches Handbuch, sofern nichts gegenteiliges vereinbart wurde. Dem SIZ liegen weder Hinweise auf diese andere Vereinbarung noch ein deutsches Handbuch vor.
b) Die Mustervereinbarung benennt eine mit dem Vertragsrecht nicht kompatible Situation
als Abschlusszeitpunkt eines Handelsgeschäftes11. Diese Mustervereinbarung ist aber weder
automatisch für das die IT-Anwendung einsetzende Institut bindend noch aus Sicht der notwendigen Service-Level-Vereinbarung als vollständig anzusehen.
Beide Aspekte gelten zwar im Gesamtzusammenhang, nicht aber spezifisch für die Software.
6.1.2 HGB
6.1.2.1 Belegbarkeit u. a. [HGB, §238]
Dem SIZ wurden zur Prüfung der IT-Anwendung weder Unterlagen überlassen, aus denen
die nach HGB §238 geforderten Eigenschaften wie Belegbarkeit, Richtigkeit und Nachvollziehbarkeit erkennbar wären noch dass die nach HGB §239 geforderten Funktionen Vollständigkeit, Zeitgerechtigkeit, Klarheit und Verfügbarkeit/ Sicherheit erfüllt wären. Hier kann
das SIZ nur annehmen, dass bislang keine gegenteiligen Hinweise aufgetaucht sind.
11
[129, S2, 3.2] vereinbart „Ein Vertrag kommt dann zustande, wenn im Anschluss an die Freigabe
durch den Kunden auf dessen Bildschirm eine Dealnummer erscheint“. Das Ausschalten des Bildschirms vor diesem Zeitpunkt ist technisch nicht feststellbar, insofern liegt hier eine nicht prüfbare
Situation zum Zustandekommen eines Vertrages vor. Dies widerspricht der vom BGB geforderten
Eindeutigkeit.
Seite: 21
Stand: 10.07.08
INFORMATIKZENTRUM
6.1.2.2 Aufbewahrungspflichten [HGB, §257]
Die mit RET-AD, Client-Applet durchgeführten Kommunikationen stellen Handelsbriefe dar,
die archiviert werden müssen. Ob diese Archivierungspflicht seitens des einsetzenden Institutes oder beim Betreiber wahrgenommen wird, ist dagegen nicht festgelegt. Beide Varianten
haben aber Folgen für das System RET-AD, Client-Applet:
Bei der Archivierung im eigenen Institut fehlen die Sicherheitshinweise, was hier konkret und
bis wann zu archivieren ist.
Bei der Archivierung durch den Betreiber fehlen die Vorgaben, dass dies dann ein Outsourcing mit den entsprechenden Vorgaben zur Vertragsgestaltung und Überwachung darstellt.
6.1.2.3 Überwachungsmaßnahmen [HGB, §317]
In den Produktdokumentationen fehlt der Hinweis, dass die mit dem RET-AD, Client-Applet
durchgeführten Transaktionen durch das einsetzende Institut überwacht werden müssen.
6.1.3 KWG
In der zum RET-AD, Client-Applet gehörenden Dokumentation fehlen Hinweise, wie z. B. bei
Devisengeschäften mit der sich daraus ergebenden Notwendigkeit von Meldungen nach
KWG §25 umzugehen ist. Derzeit geht das SIZ davon aus, dass das Problem aber die undokumentierte Einbindung in den Gesamtprozess ist und die entsprechenden Meldungen von
anderen Systemen bearbeitet werden.
§11 KWG fordert weiterhin die Berücksichtigung einer ausreichenden Liquidität. Dies hat
Auswirkungen auf RET-AD, da hiermit Geschäfte in der Zukunft abgewickelt werden, die in
zukünftigen Liquiditätsplanungen zu berücksichtigen sind. Auch hier vermutet das SIZ eher
die bislang nicht dokumentierte Schnittstelle zur Liquiditätsverwaltung als ein konkretes
Problem in RET-AD.
§25a KWG fordert eine ausreichende Kontrolle von ausgelagerten Geschäftsbereichen. Dies
muss sich zumindest in den Verträgen mit dem Betreiber wiederfinden. Entsprechende Hinweise fehlen aber in der allerdings unverbindlichen Mustervereinbarung [129].
Das Thema Outsourcing wird für Finanzinstitute u. a. durch das KWG zu einem rechtlich relevanten Aspekt. Wenn in diesem Testat von Outsourcing, Service-Level-Vereinbarungen
u. a. verwandten Themen gesprochen wird, so muss generell festgehalten werden, dass seitens SIZ nicht davon ausgegangen wird, dass der gesamte von RET-AD unterstützte Handel
als Outsourcing angesehen wird. Diese Negativ-Feststellung ist auf Detailaspekte der Durchführung von Handelsgeschäften aber nicht allgemein anwendbar, da der Handel mit Finanzpapieren und Devisen sehr wohl zum Kerngeschäft eines Finanzinstitutes gehören kann. Im
Abschnitt 7.2.3 SLV Betreuungsqualität (K305) werden daher spezifische Themen angesprochen, die institutsspezifisch als Outsourcing angesehen werden könnten.
6.1.4 AO (Abgabenordnung und Aufbewahrungsfristen)
Das Thema Aufbewahrungsfristen wurde oben bereits behandelt, eine weitergehende Analyse entfällt, da aus Sicht des Client-Applet die Aufbewahrung dem Outsourcing unterliegt.
6.1.5 GoBS und Verarbeitung buchungsrelevanter Geschäftstransaktionen
GoBS Prüfungen können auf Grund fehlender Unterlagen bis auf Einzelfälle noch nicht
durchgeführt werden, da wesentliche Informationen noch nicht vorgelegt wurden:
Beschreibung der bei Eingaben durchgeführten Plausibilisierungen,
Schnittstellenbeschreibung und Absicherungsmechanismen der Schnittstelle zwiQuelle: IT-Testierungen nach OPDV-Stellungnahme Nr. 1/2006, koenig
Seite: 22
Stand: 10.07.08
INFORMATIKZENTRUM
schen Client-Applet, Server und ggf. Trader-Applet,
Datenmodell und
Qualitätssicherungsprotokolle einschließlich der Überprüfung von Transaktionen.
Der nach [GoBS, Tz1.2], §§ 238 und 257 HGB und die §§ 145 und 146 AO erwartete Überblick enthält Summenfunktionen, die von RET-AD, Client-Applet nicht erbracht werden.
Für Buchführungsverfahren wird u. a. eine sachliche Ordnung [FAIT2, Tz34] erwartet, hierzu
sind Selektions- oder Sortiermechanismen auf den fachlichen Merkmalen von Transaktionen
erforderlich. RET-AD, Client-Applet stellt dies als Sortierfunktion weitgehend zur Verfügung,
das Merkmal „Zielwährung“ bei Devisengeschäften lässt sich aber nicht ordnen.
6.2 Fachliche Administration der IT-Anwendung
RET-AD, Client-Applet enthält keine eigene Administration. Sämtliche notwendigen Maßnahmen müssen durch den Betreiber durchgeführt werden und ihm dazu aufgetragen werden.
6.3 Korrekte Bedienung durch den Anwender
Wie bereits im Abschnitt dargelegt, sind die Handbücher nur bedingt geeignet, eine korrekte
Bedienung durch den Anwender zu ermöglichen. Positiv muss hierbei allerdings vermerkt
werden, dass die meisten der hierbei gravierenden Probleme nicht beim Anwender sondern
nur beim Betreiber auftreten.
Von RET-AD, Client-Applet ermittelte Rundungsergebnisse sind mathematisch nicht in allen
Fällen nachvollziehbar. Volumenbedingt sind die dabei erzielten Ungenauigkeiten aber vernachlässigbar klein.
Nach Ergonomieverordnung ISO 9241 sollten direkt benachbarte Tasten oder Buttons keine
entgegen gesetzte Wirkung haben. Dies wird von RET-AD, Client-Applet missachtet, wenn
der Button zur Annahme eines Geschäftes (Accept Price) und der Button zur Ablehnung eines Geschäftes (Reject Price) direkt nebeneinander liegen.
6.4 Internes Kontrollsystem (IKS) der Sparkasse
Obwohl mit RET-AD, Client-Applet auch geschäftliche Transaktionen durchgeführt werden,
sind die Hilfestellungen, die einem einsetzenden Institut für die Realisierung der notwendigen
Kontrollmaßnahmen durch die Handbücher mitgegeben werden als so gut wie nicht vorhanden zu bewerten.
7 Detailbewertung aus Sicht des Betreibers / der Produktion
RET-AD, Client-Applet ist eine Software, die in der Laufzeitumgebung eines Web-Browsers,
konkreter dessen JVM, abläuft. Hieraus ergeben sich für ein einsetzendes Institut diverse
Vorteile:
Die technischen Systemvoraussetzungen bestehen in der Abrufbarkeit von WebSeiten und der Konfiguration, Java-Applets auf dem Arbeitsplatz zuzulassen.
Auch wenn keine Software als 100% sicher einzustufen ist, gelten Java-Applets
derzeit als verhältnismäßig sicher. Wenn zudem über Firewalls kontrolliert nur bestimmte Web-Seiten aufrufbar werden, bleibt kein ernstzunehmendes Risiko aus
diesen Aspekten.
Seite: 23
Stand: 10.07.08
INFORMATIKZENTRUM
Das Auslieferungsformat und die Installationsprozedur sind so einheitlich, dass
hier keine Benutzeraktionen mehr erforderlich sind. Eine echte „Installation“ ist auf
dem Rechner des Anwenders nicht erforderlich, selbstverständlich kopiert die
Laufzeitumgebung das auszuführende Programm in einen entsprechenden lokalen Speicherbereich des Anwenders.
Sicherheitstechnisch sollten Java-Applets systemtechnisch bereits ausreichend
abgesichert sein, da theoretisch keine über Rechner, Bildschirm und Tastatur hinausgehenden sicherheitskritischen Resourcen auf dem Arbeitsplatz verwendet
werden können. Nicht abgesichert ist hier nur der Weg von dem Arbeitsplatz über
eine Fremdanwendung in das Java-Applet hinein oder heraus. Sollten innerhalb
der Java-Anwendung also sicherheitskritische Informationen liegen, müsste auch
das Java-Applet selbst untersucht werden. Derzeit sind seitens SIZ keine hierzu
ausreichenden Kritikalitäten sichtbar.
7.1 Installation und Betriebsaufnahme
Die Dokumentation weist darauf hin, dass Popups im Browser zugelassen werden müssen,
obwohl die Browserkonfiguration selbst für vertrauenswürdige Sites (Zone2) sowohl in der
Standardeinstellung als auch in der vom SIZ den Sparkassen empfohlenen Einstellung ein
„Popupblocker verwenden“ enthält.
7.2 Sicherstellung eines sicheren IT-Betriebes
7.2.1 IT-Dokumentation (K015)
Dem SIZ wurden weder Datenmodell noch Schnittstellen beschreibende Dokumente vorgelegt.
Die fachlogische Beschreibung der mathematischen Abläufe beschreibt die Anbindung einzelner Algorithmen an den realen Geschäftsprozess nur sehr oberflächlich und nicht final auf
Dokumentationsbasis nachvollziehbar. Die dabei fehlenden Teile der Ablaufbeschreibungen
lassen sich aber an einem laufenden System nachvollziehen.
7.2.2 Archivierungsmedien, -fristen (K020)
Die zu RET-AD, Client-Applet gehörende Dokumentation enthält keine nachvollziehbaren
Aussagen, durch wen oder wie notwendige Archivierungspflichten eingehalten werden. Details siehe Abschnitt 7.2.3 SLV Betreuungsqualität (K305).
7.2.3 SLV Betreuungsqualität (K305)
Neben der Mustervorlage zur Vertragsgestaltung [129] müssen zwischen einsetzendem Institut und Betreiber diverse weitere Aspekte ggf. auch vertraglich abgesichert sein:
Die Sicherheit des Servers und deren Aufrechterhaltung
Archivierung von Logbüchern und Handelsbriefen.
Die Dokumentation von Konfigurationsänderungen oder Versionsänderungen der
eingesetzten Software einschließlich der hierbei notwendigen Testmaßnahmen.
Zugriffsrechtsverwaltung, aber auch Festlegung externer Zugriffsrechte wie z. B.
durch Steuerbehörden.
Seite: 24
Stand: 10.07.08
INFORMATIKZENTRUM
Korrektheitsbelege ausgestellter Leistungsabrechnungen. Nach mündlichen Aussagen der Reuters-Mitarbeiter ist das Entnehmen von abrechnungsrelevanten Daten aus dem RET-AD-System nicht zulässig.
Weitere zu vereinbarende Inhalte ergeben sich aus der Literatur oder den entsprechenden
Abschnitten des SITB.
8 GLOSSAR
BEGRIFF DEFINITION
Abnahmetest
Der Abnahmetest dient dem Ziel, zu zeigen, dass das Vertrauen in das System für den produktiven Einsatz gerechtfertigt ist
ADS
Architecture Design Specification
ADT
Bezeichnet in den Reuters Unterlagen die „Automated Dealing Technologies“
AE-Modell (siehe [16])
Vom IZ heraus gegebenes Anwendungsentwicklungsmodell zur Entwicklung insbesondere von bankfachlicher Software.
Audit
Ein Audit ist die Begutachtung eines Prozesses oder einer
"Institution", z. B. eines Unternehmens, eines Bereichs, eines
Projekts o. ä. Durch ein Audit soll überprüft werden, ob Organisation, Vorgehensweisen, Anweisungen, Standards u. ä.
1) angemessen sind,
2) eingehalten werden,
3) wirksam und
4) sinnvoll sind.
Audits sollen konkrete Problemsituationen (Soll- IstAbweichungen) identifizieren und gezielt Lösungs- und Verbesserungsvorschläge anregen. Untersuchungsgegenstand
ist also nicht ein bestimmtes Dokument oder Arbeitsergebnis
(siehe Review), sondern der Zustand einer Institution oder
eines Prozesses.
Ausfall
Ein Ausfall einer Einheit ist die Beendigung ihrer Fähigkeit,
die geforderte Funktion auszuführen. Englisch: failure
AWV
Abk. Arbeitsgemeinschaft für wirtschaftliche Verwaltung e.V.
Bereits im Jahr 1926 gegründete Arbeitsgemeinschaft mit
dem Status eines eingetragenen Vereins zur Förderung der
Kommunikation zwischen Wirtschaft, öffentlicher Verwaltung
und Wissenschaft. Die AWV organisiert den Erfahrungsaustausch zwischen Experten aus diesen Bereichen mit dem
Ziel, die Effizienz im Verwaltungsbereich zu steigern. Durch
die Zusammenarbeit zwischen Wirtschaft und öffentlicher
Verwaltung auf einer neutralen Plattform, wie sie die AWV
bietet, wird die Bereitstellung von Entscheidungshilfen und
Richtlinien von hohem Praxisbezug angestrebt. Die Ergebnisse der Arbeit werden in Form von Veröffentlichungen und
Veranstaltungen an eine breitere Öffentlichkeit weitergegeben. darüber hinaus berät die AWV den Gesetzgeber mit
Stellungnahmen und Gutachten.
Seite: 25
Stand: 10.07.08
BEGRIFF INFORMATIKZENTRUM
DEFINITION
Die Ziele der AWV im Einzelnen:
Gestaltung und Optimierung von Dienstleistungstätigkeiten in
Wirtschaft und öffentlicher Verwaltung.
Steigerung der Wettbewerbsfähigkeit durch Verbesserung
der Kommunikation zwischen Wirtschaft und öffentlicher
Verwaltung.
Effizienzsteigerung durch Verwaltungsvereinfachung und
Bürokratieentlastung.
Unterstützung von kleinen und mittleren Unternehmen.
Praxisgerechte Auslegung von Rechtsvorschriften.
Förderung und Weiterentwicklung des Einsatzes von Informations- und Kommunikationstechnologien.
Das Bundesministerium für Wirtschaft und Technologie unterstützt die Arbeit der AWV durch öffentliche Mittel. Die Mitgliedschaft strukturiert sich aus persönlichen Mitgliedern sowie aus Unternehmen und Verbänden.
Internet: http://www.awv-net.de
BLZ
Bankleitzahl
DDS
Detailed Design Specification
FAIT1
Der Fachausschuss für Informationstechnologie (FAIT) des
IDW hat mit der Stellungnahme zur Rechnungslegung (RS)
FAIT 1 „Grundsätze ordnungsmäßiger Buchführung bei Einsatz von Informationstechnologie“ einen für Wirtschaftsprüfer
anzuwendenden Prüfungsstandard veröffentlicht. Dieser beschreibt Anforderungen an die Ordnungsmäßigkeit und Sicherheit für IT-gestützte Systeme und steht in engem Zusammenhang mit den GoBS.
Der Einsatz von IT im Unternehmen erfolgt in Form eines ITSystems, das zur Verarbeitung von Daten folgende Elemente
beinhaltet:
IT-gestützte Geschäftsprozesse
IT-Anwendungen
IT-Infrastruktur.
Das Zusammenwirken dieser Elemente wird durch das ITKontrollsystem bestimmt, das von dem IT-Umfeld und der ITOrganisation abhängt. Das IT-Kontrollsystem ist Bestandteil
des internen Kontrollsystems (IKS). Es umfasst diejenigen
Grundsätze, Verfahren und Maßnahmen (Regelungen), die
zur Bewältigung der Risiken aus dem Einsatz von IT eingerichtet werden. Hierzu gehören Regelungen zur Steuerung
des Einsatzes von IT im Unternehmen (internes Steuerungssystem) und Regelungen zur Überwachung der Einhaltung
Seite: 26
Stand: 10.07.08
DEFINITION
dieser Regelungen (internes Überwachungssystem [AktG,
§91])12.
FS
Functional Specification
IDW PS 261
IDW Standard PS 261, Titel: Feststellung und Beurteilung
von Fehlerrisiken und Reaktionen des Abschlussprüfers auf
die beurteilten Fehlerrisiken
PFS
Project Functional Specification
PRS
Project Requirement Specification
PIN
Personal-Identification-Number
Abkürzung für "persönliche Identifikationsnummer". Diese
benötigt man beispielsweise beim Homebanking.
Qualität
DIN ISO 8402 (Entwurf März 1992): "Die Gesamtheit von
Merkmalen einer Einheit (entity in der engl. Fassung) bezüglich ihrer Eignung, festgelegte und vorausgesetzte Erfordernisse zu erfüllen." DIN 55350 (Teil 11) : "Qualität ist die Gesamtheit von Eigenschaften und Merkmalen eines Produkts
oder einer Tätigkeit, die sich auf deren Eignung zur Erfüllung
gegebener Erfordernisse bezieht."
Qualität ist kein absoluter Wert, sondern muss immer relativ
zu gegebenen Erfordernissen gesehen werden. Qualitätsbewertungen beinhalten also immer einen Vergleich zwischen
Qualitätsvorgaben, die aus den gegebenen Erfordernissen
abgeleitet werden (Soll-Werte) und den tatsächlich erreichten
Ausprägungen der Merkmale (Ist-Werte). Qualität ist ein Maß
für die Erfüllung von Anforderungen.
RC
Requirement Catalogue
Review
Ein Review ist eine Form der Qualitätssicherung durch Begutachtung. Ein Team von Experten begutachtet in einem
Zeitraum von meist wenigen Stunden ein Dokument bzw.
Arbeitsergebnis, typischerweise eine Spezifikation. Die
hauptsächlichen Ziele sind,
die Qualität eines Arbeitsergebnisses zu gewährleisten und
den Projektfortschritt transparent zu machen.
Reviews sind mehr oder weniger formal geplante und strukturierte Analyse- und Bewertungsprozesse und konzentrieren
sich auf Angaben, die die Weiterentwicklung in mehr oder
minder starkem Umfang gefährden:
Unvollständige oder fehlende Angaben
Widersprüchliche Angaben
Falsche Angaben
Missverständliche oder interpretierbare Angaben.
12
Vgl. IDW Prüfungsstandard: Das interne Kontrollsystem im Rahmen der Abschlussprüfung (IDW PS
260), Tz. 5, 6;in: WPg 2001, S. 821 ff.
Seite: 27
Stand: 10.07.08
INFORMATIKZENTRUM
BEGRIFF DEFINITION
RIC
Reuters Instrument Code
RSTL
Reuters Software (Thailand) Limited
Sarbanes-Oxley-Act
Der Sarbanes-Oxley-Act (SOX) wurde im Jahr 2002 in den
USA verabschiedet. Die Vorschriften des SOX gelten für alle
Unternehmen, die gemäß dem Securities Act von 1934 bei
der US-amerikanischen SEC registriert sind und an diese
berichten. Dazu gehören auch deutsche Unternehmen.
Ziel dieses Gesetzes ist es, das verlorene Vertrauen der Kapitalmärkte in publizierte Finanzdaten wiederherzustellen. Die
Forderung nach der Installation eines effektiven internen
Kontroll-Systems durch CEO und CFO sowie die Verpflichtung zu einer regelmäßigen Überprüfung der Wirksamkeit der
wichtigsten Kontrollen sind das Kernstück dieser Bestrebungen. Für die Beschreibung eines notwendigen internen Kontroll-Systems spielt vor allem der Abschnitt 404 („Section
404“) des Gesetzes eine Rolle. Dort wird die Installation sowie die jährliche Überprüfung und Bewertung eines internen
Kontroll-Systems für das Finanzberichtswesen durch CEO
und CFO gefordert. Des Weiteren erfordert „Section 404“ die
Bestätigung der Bewertung des CEO und CFO durch einen
unabhängigen Wirtschaftsprüfer.
Schadpotenzial
Schadpotenziale sind konkrete Gefährdungen, die aus der
Funktion oder der technischen Realisierung eines Systems
für seine Umgebung oder seine Komponenten erwachsen
können. Dabei sind alle Einwirkungsmöglichkeiten des Systems auf seine Umgebung oder auf seinen internen Zustand
zu beachten. Beispiele:
Das Datennetzüberwachungswerkzeug erlaubt dem Benutzer
die Analyse und Beeinflussung von Verkehrflüssen.
Der Paketmonitor erlaubt dem Benutzer das Auslesen von
Paketinhalten.
Das Partitionierungswerkzeug für Festplatten erlaubt die Zerstörung der dort gespeicherten Daten.
Der Editor erlaubt die Modifikation von Dateien.
Schadpotenziale beantworten Fragen wie "Welche Systemfunktion ermöglicht wem welche Einwirkungen?" oder salopp
formuliert "Welche konkreten Gefahren könnten von diesem
System ausgehen?"
Schutzbedarf
Eine spezifische Voraussetzung der IT-Sicherheit eines bestimmten Systems, also eine notwendige Bedingung zur Sicherung der Integrität und Verfügbarkeit des Systems sowie
der Informationsvertraulichkeit innerhalb des Systems.
Schutzbedürfnisse sind sehr konkret formulierte Erfordernisse der IT-Sicherheit eines Systems. Sie identifizieren seine
Verwundbarkeiten, indem sie das schutzbedürftige Objekt
(Subsystem), seinen konkreten Schutzbedarf und (vorzugsweise) die Konsequenzen mangelnden Schutzes nennen. Sie
antworten auf die Fragestellung "Welches konkrete Objekt
braucht welchen Schutz zur Vermeidung welcher Gefahr?"
Seite: 28
Stand: 10.07.08
DEFINITION
oder, salopper formuliert, "Was muss im einzelnen verhindert
werden?"
Schwachstelle
Eine Sicherheitsschwäche in einer Anwendung (z. B. durch
Fehler in der Analyse, Entwurf, Implementierung oder Betrieb)
SEU
mehrdeutig:
Smallest Executable Unit (Die kleinste selbstständig ausführbare Programmeinheit.)
Software-Entwicklungs-Umgebung
SFS
System Functional Specification
Sicherheit
Die Kombination aus Vertrauenswürdigkeit, Integrität und
Verfügbarkeit.
Sicherheitsanforderung
Sicherheitsanforderungen sind eine Abstraktionsstufe von
Schutzbedürfnissen. Sicherheitsanforderungen dürfen nie
hinter den Schutzbedürfnissen, aus denen sie abgeleitet
sind, zurückbleiben. Ein System kann an seine Umgebung
ohne weiteres Sicherheitsanforderungen stellen, die seine
konkret identifizierten Schutzbedürfnisse zusammenfassen
und auch übersteigen. Dies dient der Definition und Homogenisierung von Sicherheitsstandards und Sicherheitsniveau
ebenso wie der Vorhaltung einer Sicherheitsreserve, der Zukunftssicherheit von Sicherheitskonzepten und schließlich
der Verträglichkeit von Systemen untereinander im Falle der
Integration in einem Supersystem. Sicherheitsanforderungen
sind also ein Instrument, strategische Marschrichtungen für
Sicherheitsmaßnahmen vorzugeben. Sicherheitsanforderungen geben Antwort auf die Fragestellung "Welche Schutzprinzipien werden in welcher Stärke für welche Objektklassen
gefordert?" (Es ist zu beachten, dass nicht mehr gefragt wird,
was erforderlich ist, sondern was unter Berücksichtigung der
Erfordernisse gefordert wird!)
Sicherheitslücke
Eine Diskrepanz zwischen den Sicherheitsanforderungen
eines Systems und den Sicherheitsrisiken, denen es ausgesetzt ist. Damit können bestimmte Schadpotenziale des Systems und die damit korrespondierenden Sicherheitsrisiken
seines Anwendungszweckes eintreten. Die reguläre Sicherheitsaktivität zur präventiven Entdeckung von Sicherheitslücken ist der Sicherheitsprofilabgleich. Sicherheitslücken können aber auch a posteriori im Rahmen der Sicherheitsaktivität "Panik", identifiziert werden.
Sicherheitsmechanismus
Die Logik oder der Algorithmus, die eine bestimmte sicherheitsspezifische oder sicherheitsrelevante Funktion in Hardoder Software implementiert. Beispiele hierfür sind der DESAlgorithmus für eine Verschlüsselung bzw. das KerberosProtokoll für die Realisierung eines Single-Login Verfahrens.
SITB
[SITB] Der „Sichere IT-Betrieb des SIZ“ beschreibt Sicherheit
entsprechend aller für Finanzinstitute in Deutschland geltenden Regeln und bietet auch eine Zertifizierung nach SITB an.
Seite: 29
Stand: 10.07.08
DEFINITION
Viele Sparkassen haben ihr Sicherheitsmanagement entsprechend SITB zertifizieren lassen.
SOX
Sarbanes-Oxley-Act
Standardanleihen
Standardanleihen (auch Festzinsanleihen, Straight Bonds,
Plain-Vanilla-Bonds) haben eine feste Verzinsung (Kupon)
über die gesamte Laufzeit (z. B. 5 % des Nominalwerts p. a.).
Sie sind eine der häufigsten Anleiheformen.
TS
Test Specification
VRZ
Verbandsrechenzentrum innerhalb der -Finanzgruppe, z. B.
FinanzIT, IZB-SOFT und SI(Sparkassen-Informatik)
Zutrittskontrolle
Der Zutritt zu den Räumlichkeiten, in denen die Datenverarbeitungsanlagen untergebracht sind, ist nur Befugte zulässig.
Vorrangig ist dies organisatorisch zu regeln (z. B. durch dedizierte Schlüsselvergabe für die Schließanlagen).
Zugangskontrolle
Die Datenverarbeitungsanlagen dürfen nur von Befugten
benutzt werden. Unter Zugangskontrolle ist die gesamte Anmeldeprozedur samt Passwortverfahren etc. zu verstehen.
Zugriffsschutz
Benutzer dürfen nur die Daten nutzen und verarbeiten, für die
sie autorisiert sind. Die Grundlage hierfür bildet das Berechtigungskonzept.
ZV
Zahlungsverkehr
Seite: 30
Stand: 10.07.08
INFORMATIKZENTRUM
9 INDEX
Abnahmetest 25
AE-Modell 25
AktG
§91 26
AO
§145 23
§146 23
Archivierungsmedien, -fristen 24
DIN
55350 27
DIN ISO/IEC
12119 12
FAIT1 26
FAIT2
Tz34 23
GAIT
Audit 25
Prinzip1 9
Ausfall 25
Prinzip3 10
AWV 25
Backdoor
Risikoreduktion 7
Beurteilung
GoBS
Tz1.2 23
GS-KAT
G2.1 11
der Programmierung 19
G2.2 11
der Testverfahren 20
G2.4 11
der Verfahrensdokumentation 19
HGB
BLZ 26
§238 21, 23
Buchung
§257 22, 23
Grundsätze ordnungsgemäßer
Buchführung 13
COBIT4.0
Würfel 9
COBIT4.1
Würfel 9
Code
-review 7
Compliance 9
Datenintegrität
Begriffsklärung 28, 29
Datenverarbeitungsrisiken
Verfügbarkeit 10
Datenverfügbarkeit
Begriffsklärung 28, 29
§317 22
IDW EPS 460nF 8
IDW PS 260
Tz. 5,6 27
IDW PS 261 27
IDW PS 880
Tz19 7
Tz2 3
Tz20 7
Tz22 7
IIR2
Tz20 10
IKS 26
Integrität 9
ISO
Seite: 31
Stand: 10.07.08
INFORMATIKZENTRUM
12119 12
Sicherheit des Datenbestandes 28, 29
15408 7
Sicherheitsanforderung 29
8402 27
Sicherheitslücke 29
IT-Dokumentation 24
Sicherheitsmechanismus 29
Nachweis
SITB 29
Korrektheit
K015 24
Testprotokoll 7
K020 24
PIN 27
K305 22, 24
Qualität 27
SOX 28, 30
Review 27
Standardanleihen 30
Risiko
Verfügbarkeit 9
Backdoor 7
Maßzahl für Software 10
Sarbanes-Oxley-Act 28
VRZ 30
Schadpotenzial 28
Zugangskontrolle 30
Schutzbedarf 28
Zugriffsschutz 30
Schwachstelle 29
Zutrittskontrolle 30
SEU 29
ZV 30
Sicherheit 29
10 Unterschrift
Bonn,
Donnerstag, 10.
Juli 2008
Dipl. Inform. Bernhard König
(Prüfer)
Hans-Peter Dünnwald
(Qualitätssicherung des vorliegenden Testates,
siehe Änderungshistorie)
Seite: 32
Stand: 10.07.08

Testat nach OPDV-Stellungnahme Nr. 1/2006

Transcription

Similar documents

Wörterbuch IT und eBusiness

Zum vollständigen Presseartikel

IDW-RS-FAIT-1 - IDW Stellungnahme zur Rechnungslegung

C 00. 01 CANopen Inhaltsverzeichnis Kapitel C

- AHK Korea

urn:nbn:de:0008-20050117016 - Deutsche Nationalbibliothek

cerec 30 - dentalmagazin.de

1 Alexander Klähr: Frauenbilder in der graphischen Literatur

DIE STARKEN EXTRAS Top-Seller mit

Das schreibt die FAZ über den ROTABALL PRO.

GESCHÄFTSBERICHT 2014 ENGADIN ST. MORITZ

I-CON OPDV: Anwendungs-Transparenz und

cominvest Green Energy Protect 3/2013

Herunterladen